Tracking issue for RFC 2342, "Allow if and match in constants"

This is a tracking issue for the RFC "Allow if and match in constants" (rust-lang/rfcs#2342).

Please redirect constification of specific functions or issues you want to report to fresh issues and label them appropriately with F-const_if_match so that this issues doesn't get flooded with ephemeral comments obscuring important developments.

Steps:

Implement the RFC
Adjust documentation (see instructions on forge)
Stabilization PR (see instructions on forge): Stabilize #![feature(const_if_match)] and #![feature(const_loop)] #72437
let bindings in constants that use && and || short circuiting operations. These are treated as & and | inside const and static items right now.

Unresolved questions:

None

add a feature gate for it
switch and switchInt terminators in https://github.com/rust-lang/rust/blob/master/src/librustc_mir/transform/qualify_consts.rs#L347 need to have custom code in case the feature gate is active
instead of having a single current basic block (https://github.com/rust-lang/rust/blob/master/src/librustc_mir/transform/qualify_consts.rs#L328) this needs to be some container that has a list of basic blocks it still has to process.

@oli-obk

@oli-obk It's a bit trickier because the complex control-flow means dataflow analysis needs to be employed. I need to get back to @alexreg and figure out how to integrate their changes.

@eddyb

@eddyb A good starting point would probably be to take my const-qualif branch (minus the top commit), rebase it over master (not going to be fun), and then add data annotation stuff, right?

@mark-i-m

@mark-i-m Alas no. I think @eddyb has been very busy indeed, because I've not even been able to ping him on IRC for the last few weeks hah. Sadly my const-qualif branch doesn't even compile since I last rebased it over master. (I don't believe I've pushed yet though.)

thread 'main' panicked at 'assertion failed: position <= slice.len()', libserialize/leb128.rs:97:1
note: Run with `RUST_BACKTRACE=1` for a backtrace.
error: Could not compile `rustc_llvm`.

Caused by:
  process didn't exit successfully: `/Users/alex/Software/rust/build/bootstrap/debug/rustc --crate-name build_script_build librustc_llvm/build.rs --error-format json --crate-type bin --emit=dep-info,link -C opt-level=2 -C metadata=74f2a810ad96be1d -C extra-filename=-74f2a810ad96be1d --out-dir /Users/alex/Software/rust/build/x86_64-apple-darwin/stage1-rustc/release/build/rustc_llvm-74f2a810ad96be1d -L dependency=/Users/alex/Software/rust/build/x86_64-apple-darwin/stage1-rustc/release/deps --extern build_helper=/Users/alex/Software/rust/build/x86_64-apple-darwin/stage1-rustc/release/deps/libbuild_helper-89aaac40d3077cd7.rlib --extern cc=/Users/alex/Software/rust/build/x86_64-apple-darwin/stage1-rustc/release/deps/libcc-ead7d4af4a69e776.rlib` (exit code: 101)
warning: build failed, waiting for other jobs to finish...
error: build failed
command did not execute successfully: "/Users/alex/Software/rust/build/x86_64-apple-darwin/stage0/bin/cargo" "build" "--target" "x86_64-apple-darwin" "-j" "8" "--release" "--manifest-path" "/Users/alex/Software/rust/src/librustc_trans/Cargo.toml" "--features" " jemalloc" "--message-format" "json"
expected success, got: exit code: 101
thread 'main' panicked at 'cargo must succeed', bootstrap/compile.rs:1085:9
note: Run with `RUST_BACKTRACE=1` for a backtrace.
failed to run: /Users/alex/Software/rust/build/bootstrap/debug/bootstrap -i build

@eddyb

Okay, funnily enough, I rebased again just today and it seems to be building all fine now! Looks like there was a regression, and it just got fixed. All over to @eddyb now.

@alexreg

@alexreg Sorry, I've switched to a local sleep schedule and I see you've pinged me when I wake up but then you're offline all day when I'm awake (ugh timezones).
Should I just make a PR out of your branch? I forgot what we were supposed to do with it?

@eddyb

@eddyb That's alright heh. You must be off to bed early, since I'm usually on from 8:00PM GMT, but it's all good! :-)

Rollup merge of rust-lang#50233 - mark-i-m:const_vec, r=kennytm

I'm really sorry, took me a while to realize that the series of patches in question requires removing Qualif::STATIC{,_REF}, i.e. the errors about accessing statics at compile-time. OTOH, this is already broken in terms of const fns and access to statics:

#![feature(const_fn)]
const fn read<T: Copy>(x: &T) -> T { *x }
static FOO: u32 = read(&BAR);
static BAR: u32 = 5;
fn main() {
    println!("{}", FOO);
}

This is not detected statically, instead miri complains that "dangling pointer was dereferenced" (which should really say something about statics instead of "dangling pointer").

So I think reading statics at compile-time should be fine, but some people want const fn to be "pure" (i.e. "referentially transparent" or thereabouts) at runtime, which would mean that a const fn reading from behind a reference it got as an argument is fine, but a const fn should never be able to obtain a reference to a static out of thin air (including from consts).

I think then we can keep statically denying mentioning statics (even if only to take their reference) in consts, const fn, and other constant contexts (including promoteds).
But we still have to remove the STATIC_REF hack which allows statics to take the reference of other statics but (poorly tries and fails to) deny reading from behind those references.

Do we need an RFC for this?

Sounds fair w.r.t. reading from statics. Doubt it needs an RFC, maybe just a crater run, but then I’m probably not the best one to say.

Note that we wouldn't be restricting anything, we'd be relaxing a restriction that's already broken.

Stabilize some Option methods as const

Rollup merge of rust-lang#76135 - CDirkx:const-option, r=dtolnay,oli-obk

Auto merge of rust-lang#76136 - CDirkx:const-result, r=dtolnay

The E0744 documentation is now out of date.

Trying to use ? in a const context gives an error (playground):

error[E0744]: `?` is not allowed in a `const fn`
 --> src/lib.rs:6:21
  |
6 |         let value = foo?;
  |                     ^^^^

error: aborting due to previous error

For more information about this error, try `rustc --explain E0744`.

E0744 links to this tracking issue, and also says

At the moment, if and match, as well as the looping constructs for, while, and loop, are forbidden inside a const, static, or const fn.

However, the ? can be replaced with a match.

This came up on the user forum. Let me know if a new issue should be opened.

@QuineDot

@QuineDot this was recently fixed, but it will take a bit until the fix hits stable: #79087.

Bump MSRV to Rust 1.45+

Bump MSRV to Rust 1.46+

ci: bump MSRV to 1.46

Updating crate `socket2#0.4.0`

Bump MSRV to 1.46

Makefile: do not compile rust/download_web with old toolchain

Use nightly build

I was able to fix this error by running rustup update

release: 0.8.0 (#162)

Navigation Menu

Repository navigation

Tracking issue for RFC 2342, "Allow `if` and `match` in constants" #49146

130 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Tracking issue for RFC 2342, "Allow if and match in constants" #49146

Description

Activity

oli-obk commented on Mar 19, 2018

eddyb commented on Mar 19, 2018

alexreg commented on Mar 19, 2018

mark-i-m commented on Apr 25, 2018

alexreg commented on Apr 26, 2018

alexreg commented on Apr 26, 2018

eddyb commented on Apr 26, 2018

alexreg commented on Apr 26, 2018

eddyb commented on May 4, 2018

alexreg commented on May 4, 2018

eddyb commented on May 4, 2018

130 remaining items

QuineDot commented on Nov 26, 2020

RalfJung commented on Nov 26, 2020

nickfarrow commented on Jul 17, 2021

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

Tracking issue for RFC 2342, "Allow `if` and `match` in constants" #49146