replace `#[allow_internal_unstable]` with `#[rustc_allow_const_fn_unstable]` for `const fn`s
`#[allow_internal_unstable]` is currently used to side-step feature gate and stability checks.
While it was originally only meant to be used only on macros, its use was expanded to `const fn`s.
This pr adds stricter checks for the usage of `#[allow_internal_unstable]` (only on macros) and introduces the `#[rustc_allow_const_fn_unstable]` attribute for usage on `const fn`s.
This pr does not change any of the functionality associated with the use of `#[allow_internal_unstable]` on macros or the usage of `#[rustc_allow_const_fn_unstable]` (instead of `#[allow_internal_unstable]`) on `const fn`s (see https://github.com/rust-lang/rust/issues/69399#issuecomment-712911540).
Note: The check for `#[rustc_allow_const_fn_unstable]` currently only validates that the attribute is used on a function, because I don't know how I would check if the function is a `const fn` at the place of the check. I therefore openend this as a 'draft pull request'.
Closesrust-lang/rust#69399
r? @oli-obk
stop promoting union field accesses in 'const'
Turns out that promotion of union field accesses is the only difference between "promotion in `const`/`static` bodies" and "explicit promotion". So if we can remove this, we have finally achieved what I thought to already be the case -- that the bodies of `const`/`static` initializers behave the same as explicit promotion contexts.
The reason we do not want to promote union field accesses is that they can introduce UB, i.e., they can go wrong. We want to [minimize the ways promoteds can fail to evaluate](https://github.com/rust-lang/const-eval/issues/53). Also this change makes things more consistent overall, removing a special case that was added without much consideration (as far as I can tell).
Cc `@rust-lang/wg-const-eval`
Introduce a temporary for discriminant value in MatchBranchSimplification
The optimization introduces additional uses of the discriminant operand, but
does not ensure that it is still valid to evaluate it or that it still
evaluates to the same value.
Evaluate it once at original position, and store the result in a new temporary.
Follow up on #78151. The optimization remains disabled by default.
Closes#78239.
Fix const core::panic!(non_literal_str).
Invocations of `core::panic!(x)` where `x` is not a string literal expand to `panic!("{}", x)`, which is not understood by the const panic logic right now. This adds `panic_str` as a lang item, and modifies the const eval implementation to hook into this item as well.
This fixes the issue mentioned here: https://github.com/rust-lang/rust/issues/51999#issuecomment-687604248
r? `@RalfJung`
`@rustbot` modify labels: +A-const-eval
Rollup of 10 pull requests
Successful merges:
- #77420 (Unify const-checking structured errors for `&mut` and `&raw mut`)
- #77554 (Support signed integers and `char` in v0 mangling)
- #77976 (Mark inout asm! operands as used in liveness pass)
- #78009 (Haiku: explicitly set CMAKE_SYSTEM_NAME when cross-compiling)
- #78084 (Greatly improve display for small mobile devices screens)
- #78155 (Fix two small issues in compiler/rustc_lint/src/types.rs)
- #78156 (Fixed build failure of `rustfmt`)
- #78172 (Add test case for #77062)
- #78188 (Add tracking issue number for pin_static_ref)
- #78200 (Add `ControlFlow::is_{break,continue}` methods)
Failed merges:
r? `@ghost`
The optimization introduces additional uses of the discriminant operand, but
does not ensure that it is still valid to evaluate it or that it still
evaluates to the same value.
Evaluate it once at original position, and store the result in a new temporary.
This optimization can result in unsoundness, because it introduces
additional uses of a place holding the discriminant value without
ensuring that it is valid to do so.
normalize substs while inlining
fixes#68347 or more precisely, this fixes the same ICE in rust analyser as veloren is pinned to a specific nightly
and had an error with the current one.
I didn't look into creating an MVCE here as that seems fairly annoying, will spend a few minutes doing so rn. (failed)
r? `@eddyb` cc `@bjorn3`
Permit uninhabited enums to cast into ints
This essentially reverts part of #6204; it is unclear why that [commit](c0f587de34) was introduced, and I suspect no one remembers.
The changed code was only called from casting checks and appears to not affect any callers of that code (other than permitting this one case).
Fixes#75647.
instrument-coverage: try our best to not ICE
instrument-coverage was ICEing for me on some code, in particular code
that had devirtualized paths from standard library. Instrument coverage
probably has no bussiness dictating which paths are valid and which
aren't so just feed it everything and whatever and let tooling deal with
other stuff.
For example, with this commit we can generate coverage hitpoints for
these interesting paths:
* `/rustc/.../library/core/lib.rs` – non-devirtualized path for libcore
* `/home/.../src/library/core/lib.rs` – devirtualized version of above
* `<inline asm>`, `<anon>` and many similar synthetic paths
Even if those paths somehow get to the instrumentation pass, I'd much
rather get hits for these weird paths and hope some of them work (as
would be the case for devirtualized path to libcore), rather than have
compilation fail entirely.
instrument-coverage was ICEing for me on some code, in particular code
that had devirtualized paths from standard library. Instrument coverage
probably has no bussiness dictating which paths are valid and which
aren't so just feed it everything and whatever and let tooling deal with
other stuff.
For example, with this commit we can generate coverage hitpoints for
these interesting paths:
* `/rustc/.../library/core/lib.rs` – non-devirtualized path for libcore
* `/home/.../src/library/core/lib.rs` – devirtualized version of above
* `<inline asm>`, `<anon>` and many similar synthetic paths
Even if those paths somehow get to the instrumentation pass, I'd much
rather get hits for these weird paths and hope some of them work (as
would be the case for devirtualized path to libcore), rather than have
compilation fail entirely.
Create a single source scope for promoteds
A promoted inherits all scopes from the parent body. At the same time,
almost all statements and terminators inside the promoted body so far
refer only to one of those scopes: the outermost one.
Instead of inheriting all scopes, inherit only a single scope
corresponding to the location of the promoted, making sure that there
are no references to other scopes.
Preparation for a subsequent change that replaces
rustc_target::config::Config with its wrapped Target.
On its own, this commit breaks the build. I don't like making
build-breaking commits, but in this instance I believe that it
makes review easier, as the "real" changes of this PR can be
seen much more easily.
Result of running:
find compiler/ -type f -exec sed -i -e 's/target\.target\([)\.,; ]\)/target\1/g' {} \;
find compiler/ -type f -exec sed -i -e 's/target\.target$/target/g' {} \;
find compiler/ -type f -exec sed -i -e 's/target.ptr_width/target.pointer_width/g' {} \;
./x.py fmt
A promoted inherits all scopes from the parent body. At the same time,
almost all statements and terminators inside the promoted body so far
refer only to one of those scopes: the outermost one.
Instead of inheriting all scopes, inherit only a single scope
corresponding to the location of the promoted, making sure that there
are no references to other scopes.
Replace absolute paths with relative ones
Modern compilers allow reaching external crates
like std or core via relative paths in modules
outside of lib.rs and main.rs.
Mono collector: replace pair of ints with Range
I found the initial PR (#33171) that introduced this piece of code but I didn't find any information about why a tuple was preferred over a `Range<usize>`.
I'm hoping there are no technical reasons to not do this.
Recognize discriminant reads as no-ops in RemoveNoopLandingPads
The cleanup blocks often contain read of discriminants. Teach
RemoveNoopLandingPads to recognize them as no-ops to remove
additional no-op landing pads.
The cleanup blocks often contain read of discriminants. Teach
RemoveNoopLandingPads to recognize them as no-ops to remove
additional no-op landing pads.
Use `pretty::create_dump_file` for dumping dataflow results
The old code wasn't incorporating promoteds into the path, meaning other `dot` files could get clobbered. Use the MIR dump infrastructure to generate paths so that this doesn't occur in the future.
perf: UninhabitedEnumBranching avoid n^2
Avoid n² complexity. This showed up in a profile for match-stress-enum that has 8192 variants
I have only profiled locally against `match-stress-enum`, so we should have it perf tested to make sure it does not regress other crates.
Give `impl Trait` in a `const fn` its own feature gate
...previously it was gated under `#![feature(const_fn)]`.
I think we actually want to do this in all const-contexts? If so, this should be `#![feature(const_impl_trait)]` instead. I don't think there's any way to make use of `impl Trait` within a `const` initializer.
cc #77463
r? `@oli-obk`
inliner: use caller param_env
We used the callee param env instead of the caller param env by accident in #77430, this PR fixes that and caches it in the `Inliner` struct.
fixes#77564
r? @ecstatic-morse
This is a combination of 18 commits.
Commit #2:
Additional examples and some small improvements.
Commit #3:
fixed mir-opt non-mir extensions and spanview title elements
Corrected a fairly recent assumption in runtest.rs that all MIR dump
files end in .mir. (It was appending .mir to the graphviz .dot and
spanview .html file names when generating blessed output files. That
also left outdated files in the baseline alongside the files with the
incorrect names, which I've now removed.)
Updated spanview HTML title elements to match their content, replacing a
hardcoded and incorrect name that was left in accidentally when
originally submitted.
Commit #4:
added more test examples
also improved Makefiles with support for non-zero exit status and to
force validation of tests unless a specific test overrides it with a
specific comment.
Commit #5:
Fixed rare issues after testing on real-world crate
Commit #6:
Addressed PR feedback, and removed temporary -Zexperimental-coverage
-Zinstrument-coverage once again supports the latest capabilities of
LLVM instrprof coverage instrumentation.
Also fixed a bug in spanview.
Commit #7:
Fix closure handling, add tests for closures and inner items
And cleaned up other tests for consistency, and to make it more clear
where spans start/end by breaking up lines.
Commit #8:
renamed "typical" test results "expected"
Now that the `llvm-cov show` tests are improved to normally expect
matching actuals, and to allow individual tests to override that
expectation.
Commit #9:
test coverage of inline generic struct function
Commit #10:
Addressed review feedback
* Removed unnecessary Unreachable filter.
* Replaced a match wildcard with remining variants.
* Added more comments to help clarify the role of successors() in the
CFG traversal
Commit #11:
refactoring based on feedback
* refactored `fn coverage_spans()`.
* changed the way I expand an empty coverage span to improve performance
* fixed a typo that I had accidently left in, in visit.rs
Commit #12:
Optimized use of SourceMap and SourceFile
Commit #13:
Fixed a regression, and synched with upstream
Some generated test file names changed due to some new change upstream.
Commit #14:
Stripping out crate disambiguators from demangled names
These can vary depending on the test platform.
Commit #15:
Ignore llvm-cov show diff on test with generics, expand IO error message
Tests with generics produce llvm-cov show results with demangled names
that can include an unstable "crate disambiguator" (hex value). The
value changes when run in the Rust CI Windows environment. I added a sed
filter to strip them out (in a prior commit), but sed also appears to
fail in the same environment. Until I can figure out a workaround, I'm
just going to ignore this specific test result. I added a FIXME to
follow up later, but it's not that critical.
I also saw an error with Windows GNU, but the IO error did not
specify a path for the directory or file that triggered the error. I
updated the error messages to provide more info for next, time but also
noticed some other tests with similar steps did not fail. Looks
spurious.
Commit #16:
Modify rust-demangler to strip disambiguators by default
Commit #17:
Remove std::process::exit from coverage tests
Due to Issue #77553, programs that call std::process::exit() do not
generate coverage results on Windows MSVC.
Commit #18:
fix: test file paths exceeding Windows max path len
Fix miscompile in SimplifyBranchSame
Cherry-picked from #77486, but with a different test case that used to be compiled incorrectly on both master & beta branches.
Replace `(Body, DefId)` with `Body` where possible
Follow-up to #77430.
I `grep`-ed for parameter lists in which a `Body` appeared within a few lines of a `DefId`, so it's possible that I missed some cases, but this should be pretty complete. Most of these changes were mechanical, but there's a few places where I started calling things "caller" and "callee" when multiple `DefId`s were in-scope at once. Also, we should probably have a helper function on `Body` that returns a `LocalDefId`. I can do that in this PR or in a follow-up.
Rollup of 11 pull requests
Successful merges:
- #75853 (Use more intra-doc-links in `core::fmt`)
- #75928 (Remove trait_selection error message in specific case)
- #76329 (Add check for doc alias attribute at crate level)
- #77219 (core::global_allocator docs link to std::alloc::GlobalAlloc)
- #77395 (BTreeMap: admit the existence of leaf edges in comments)
- #77407 (Improve build-manifest to work with the improved promote-release)
- #77426 (Include scope id in SocketAddrV6::Display)
- #77439 (Fix missing diagnostic span for `impl Trait` with const generics, and add various tests for `min_const_generics` and `const_generics`)
- #77471 (BTreeMap: refactoring around edges, missed spots)
- #77512 (Allow `Abort` terminators in all const-contexts)
- #77514 (Replace some once(x).chain(once(y)) with [x, y] IntoIter)
Failed merges:
r? `@ghost`
Allow `Abort` terminators in all const-contexts
We never unwind during const-eval, so we basically have these semantics already. Also I just figured out that these only appear along the cleanup path, which doesn't get const-checked. In other words, this doesn't actually change behavior: the `check-pass` test I added compiles just fine on nightly.
r? @RalfJung
cc @rust-lang/wg-const-eval
Use `tracing` spans to trace the entire MIR interp stack
r? @RalfJung
While being very verbose, this allows really good tracking of what's going on. While I considered schemes like the previous indenter that we had (which we could get by using the `tracing-tree` crate), this will break down horribly with things like multithreaded rustc. Instead, we can now use `RUSTC_LOG` to restrict the things being traced. You could specify a filter in a way that only shows the logging of a specific frame.
If we lower the span's level to `debug`, then in `info` level logging we'd not see the frames, but in `debug` level we would see them. The filtering rules in `tracing` are super powerful, but I'm not sure if we can specify a filter so we do see `debug` level events, but *not* the `frame` spans. The documentation at https://docs.rs/tracing-subscriber/0.2.10/tracing_subscriber/struct.EnvFilter.html makes me think that we can only turn on things, not turn off things at a more precise level.
cc @hawkw
The destination propagation as currently implemented does not supersede
the NRVO, e.g., the destination propagation never applies if either
local has an address taken, while NRVO might.
Additionally, the issue with failing assertions had been already
resolved.
Continue running both optimizations at mir-opt-level >= 2.
These appear along the cleanup path inside functions with
`#[unwind(aborts)]`. We don't const-check the cleanup path anyways,
since const-eval already has "abort-on-panic" semantics and there's
often drops that would otherwise be forbidden, so the check wasn't
really preventing anything anyways.
Bypass const_item_mutation if const's type has Drop impl
Follow-up to #75573. This PR disables the const_item_mutation lint in cases that the const has a Drop impl which observes the mutation.
```rust
struct Log { msg: &'static str }
const LOG: Log = Log { msg: "" };
impl Drop for Log {
fn drop(&mut self) { println!("{}", self.msg); }
}
LOG.msg = "wow"; // prints "wow"
```
r? @Aaron1011
Add `-Zprecise-enum-drop-elaboration`
Its purpose is to assist in debugging #77382 and #74551. Passing `-Zprecise-enum-drop-elaboration=no` will turn off the added precision that seems to be causing issues on some platforms. This assumes that we can reproduce #77382 on the latest master. I should have done this earlier. Oh well.
cc @cuviper
r? @pnkfelix
Overhaul const-checking diagnostics
The primary purpose of this PR was to remove `NonConstOp::STOPS_CONST_CHECKING`, which causes any additional errors found by the const-checker to be silenced. I used this flag to preserve diagnostic parity with `qualify_min_const_fn.rs`, which has since been removed.
However, simply removing the flag caused a deluge of errors in some cases, since an error would be emitted any time a local or temporary had a wrong type. To remedy this, I added an alternative system (`DiagnosticImportance`) to silence additional error messages that were likely to distract the user from the underlying issue. When an error of the highest importance occurs, all less important errors are silenced. When no error of the highest importance occurs, all less important errors are emitted after checking is complete. Following the suggestions from the important error is usually enough to fix the less important errors, so this should lead to better UX most of the time.
There's also some unrelated diagnostics improvements in this PR isolated in their own commits. Splitting them out would be possible, but a bit of a pain. This isn't as tidy as some of my other PRs, but it should *only* affect diagnostics, never whether or not something passes const-checking. Note that there are a few trivial exceptions to this, like banning `Yield` in all const-contexts, not just `const fn`.
As always, meant to be reviewed commit-by-commit.
r? `@oli-obk`
adt_destructor by default also validates the Drop impl using
dropck::check_drop_impl, which contains an expect_local(). This
leads to ICE in check_const_item_mutation if the const's type is
not a local type.
thread 'rustc' panicked at 'DefId::expect_local: `DefId(5:4805 ~ alloc[d7e9]::vec::{impl#50})` isn't local', compiler/rustc_span/src/def_id.rs:174:43
stack backtrace:
0: rust_begin_unwind
1: rustc_span::def_id::DefId::expect_local::{{closure}}
2: rustc_typeck::check::dropck::check_drop_impl
3: rustc_middle::ty::util::<impl rustc_middle::ty::context::TyCtxt>::calculate_dtor::{{closure}}
4: rustc_middle::ty::trait_def::<impl rustc_middle::ty::context::TyCtxt>::for_each_relevant_impl
5: rustc_middle::ty::util::<impl rustc_middle::ty::context::TyCtxt>::calculate_dtor
6: rustc_typeck::check::adt_destructor
7: rustc_middle::ty::query::<impl rustc_query_system::query::config::QueryAccessors<rustc_middle::ty::context::TyCtxt> for rustc_middle::ty::query::queries::adt_destructor>::compute
8: rustc_query_system::dep_graph::graph::DepGraph<K>::with_task_impl
9: rustc_query_system::query::plumbing::get_query_impl
10: rustc_mir::transform::check_const_item_mutation::ConstMutationChecker::is_const_item_without_destructor
This helper function was meant to reduce code duplication between
const-checking pre- and post-drop-elaboration. Most of the functionality
is only relevant for the pre-drop-elaboration pass.
Rollup of 7 pull requests
Successful merges:
- #76454 (UI to unit test for those using Cell/RefCell/UnsafeCell)
- #76474 (Add option to pass a custom codegen backend from a driver)
- #76711 (diag: improve closure/generic parameter mismatch)
- #77170 (Remove `#[rustc_allow_const_fn_ptr]` and add `#![feature(const_fn_fn_ptr_basics)]`)
- #77194 (Add doc alias for iterator fold)
- #77288 (fix building libstd for Miri on macOS)
- #77295 (Update unstable-book: Fix ABNF in inline assembly docs)
Failed merges:
r? `@ghost`
Remove `#[rustc_allow_const_fn_ptr]` and add `#![feature(const_fn_fn_ptr_basics)]`
`rustc_allow_const_fn_ptr` was a hack to work around the lack of an escape hatch for the "min `const fn`" checks in const-stable functions. Now that we have co-opted `allow_internal_unstable` for this purpose, we no longer need a bespoke attribute.
Now this functionality is gated under `const_fn_fn_ptr_basics` (how concise!), and `#[allow_internal_unstable(const_fn_fn_ptr_basics)]` replaces `#[rustc_allow_const_fn_ptr]`. `const_fn_fn_ptr_basics` allows function pointer types to appear in the arguments and locals of a `const fn` as well as function pointer casts to be performed inside a `const fn`. Both of these were allowed in constants and statics already. Notably, this does **not** allow users to invoke function pointers in a const context. Presumably, we will use a nicer name for that (`const_fn_ptr`?).
r? @oli-obk
[mir-opt] Introduce a new flag to enable experimental/unsound mir opts
This implements part of https://github.com/rust-lang/compiler-team/issues/319. The exact name of this flag was not decided as part of that MCP and some people expressed that it should include "unsound" in some way.
I've chosen to use `enable-experimental-unsound-mir-opts` as the name. While long, I don't think that matters too much as really it will only be used by some mir-opt tests. If you object or have a better name, please leave a comment!
r? `@oli-obk`
cc `@rust-lang/wg-mir-opt` `@RalfJung`
Replace `discriminant_switch_effect` with more general version
#68528 added a new edge-specific effect for `SwitchInt` terminators, `discriminant_switch_effect`, to the dataflow framework. While this accomplished the short-term goal of making drop elaboration more precise, it wasn't really useful in other contexts: It only supported `SwitchInt`s on the discriminant of an `enum` and did not allow effects to be applied along the "otherwise" branch. In const-propagation, for example, arbitrary edge-specific effects for the targets of a `SwitchInt` can be used to remember the value a `match` scrutinee must have in each arm.
This PR replaces `discriminant_switch_effect` with a more general `switch_int_edge_effects` method. The new method has a slightly different interface from the other edge-specific effect methods (e.g. `call_return_effect`). This divergence is explained in the new method's documentation, and reading the changes to the various dataflow impls as well as `direction.rs` should further clarify things. This PR should not change behavior.
This was a hack to work around the lack of an escape hatch for the "min
`const fn`" checks in const-stable functions. Now that we have co-opted
`allow_internal_unstable` for this purpose, we no longer need the
bespoke attribute.
Check for missing const-stability attributes in `rustc_passes`
Currently, this happens as a side effect of `is_min_const_fn`, which is non-obvious. Also adds a test for this case, since we didn't seem to have one before.
Move helper function for `missing_const_for_fn` out of rustc to clippy
cc @rust-lang/clippy @ecstatic-morse #76618
r? @Manishearth
I also removed all support for suggesting a function could be `const fn` when that would require feature gates to actually work.
This means we'll now have to maintain this ourselves in clippy, but that's how most lints work anyway, so...
Enable const propagation into operands at mir_opt_level=2
Feature was added in #74507 but gated with `mir_opt_level>=3` because of compile time regressions. Let's see whether the LLVM 11 update solves that.
As the [perf results](https://github.com/rust-lang/rust/pull/77107#issuecomment-697668154) show, enabling this optimization results in a lot less regression as before.
cc @oli-obk
r? @ghost
Add `#![feature(const_fn_floating_point_arithmetic)]`
cc #76618
This is a template for splitting up `const_fn` into granular feature gates. I think this will make it easier, both for us and for users, to track stabilization of each individual feature. We don't *have* to do this, however. We could also keep stabilizing things out from under `const_fn`.
cc @rust-lang/wg-const-eval
r? @oli-obk
Rollup of 15 pull requests
Successful merges:
- #76932 (Relax promises about condition variable.)
- #76973 (Unstably allow assume intrinsic in const contexts)
- #77005 (BtreeMap: refactoring around edges)
- #77066 (Fix dest prop miscompilation around references)
- #77073 (dead_code: look at trait impls even if they don't contain items)
- #77086 (Include libunwind in the rust-src component.)
- #77097 (Make [].as_[mut_]ptr_range() (unstably) const.)
- #77106 (clarify that `changelog-seen = 1` goes to the beginning of config.toml)
- #77120 (Add `--keep-stage-std` to `x.py` for keeping only standard library artifacts)
- #77126 (Invalidate local LLVM cache less often)
- #77146 (Install std for non-host targets)
- #77155 (remove enum name from ImplSource variants)
- #77176 (Removing erroneous semicolon in transmute documentation)
- #77183 (Allow multiple allow_internal_unstable attributes)
- #77189 (Remove extra space from vec drawing)
Failed merges:
r? `@ghost`
This refactors handling of `Rvalue::{Unary,Binary}Op` in the
const-checker. Now we `span_bug` if there's an unexpected type in a
primitive operation. This also allows unary negation on
`char` values through the const-checker because it makes the code a bit
cleaner. `char` does not actually support these operations, and if it
did, we could evaluate them at compile-time.
Fix#76803 miscompilation
Fixes#76803
Seems like it was an oversight that the discriminant value being set was not compared to the target value from the SwitchInt, as a comment says this is a requirement for the optimization to be sound.
r? `@wesleywiser` since you are probably familiar with the optimization and made #76837 to workaround the bug
Suggest `const_fn_transmute`, not `const_fn`
More fallout from #76850 in the vein of #77134. The fix is the same. I looked through the structured errors file and didn't see any more of this kind of diagnostics bug.
r? @oli-obk
Suggest `const_mut_refs`, not `const_fn` for mutable references in `const fn`
Resolves#77134.
Prior to #76850, most uses of `&mut` in `const fn` ~~required~~ involved two feature gates, `const_mut_refs` and `const_fn`. The first allowed all mutable borrows of locals. The second allowed only locals, arguments and return values whose types contained `&mut`. I switched the second check to the `const_mut_refs` gate. However, I forgot update the error message with the new suggestion.
Alternatively, we could revert to having two different feature gates for this. OP's code never borrows anything mutably, so it didn't need `const_mut_refs` in the past, only `const_fn`. I'd prefer to keep everything under a single gate, however.
r? @oli-obk
Allow a unique name to be assigned to dataflow graphviz output
Previously, if the same analysis were invoked multiple times in a single compilation session, the graphviz output for later runs would overwrite that of previous runs. Allow callers to add a unique identifier to each run so this can be avoided.
