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.
Fix underflow when calculating the number of no-op jumps folded
When removing unwinds to no-op blocks and folding jumps to no-op blocks,
remove the unwind target first. Otherwise we cannot determine if target
has been already folded or not.
Previous implementation incorrectly assumed that all resume targets had
been folded already, occasionally resulting in an underflow:
```
remove_noop_landing_pads: removed 18446744073709551613 jumps and 3 landing pads
```
Rollup of 9 pull requests
Successful merges:
- #76898 (Record `tcx.def_span` instead of `item.span` in crate metadata)
- #76939 (emit errors during AbstractConst building)
- #76965 (Add cfg(target_has_atomic_equal_alignment) and use it for Atomic::from_mut.)
- #76993 (Changing the alloc() to accept &self instead of &mut self)
- #76994 (fix small typo in docs and comments)
- #77017 (Add missing examples on Vec iter types)
- #77042 (Improve documentation for ToSocketAddrs)
- #77047 (Miri: more informative deallocation error messages)
- #77055 (Add #[track_caller] to more panicking Cell functions)
Failed merges:
r? `@ghost`
MIR pass to remove unneeded drops on types not needing drop
This is heavily dependent on MIR inlining running to actually see the drop statement.
Do we want to special case replacing a call to std::mem::drop with a goto aswell?
SimplifyComparisonIntegral: fix miscompilation
Fixes#76432
Only insert StorageDeads if we actually removed one.
Fixes an issue where we added StorageDead to a place with no StorageLive
r? `@oli-obk`