CTFE inbounds-error-messages tweak
* use CheckInAllocMsg::PointerArithmeticTest for ptr_offset error
* nicer errors for some null pointer cases
r? `@oli-obk`
This commit implements both the native linking modifiers infrastructure
as well as an initial attempt at the individual modifiers from the RFC.
It also introduces a feature flag for the general syntax along with
individual feature flags for each modifier.
Remove `rustc_middle::mir::interpret::CheckInAllocMsg::NullPointerTest`
Removing it per https://github.com/rust-lang/rust/pull/84842#discussion_r625589674: it's a dead enum variant.
Note that `PointerArithmeticTest` also seems dead:
```
$ rg -F PointerArithmeticTest -C5
compiler/rustc_middle/src/mir/interpret/error.rs
169-
170-/// Details of why a pointer had to be in-bounds.
171-#[derive(Debug, Copy, Clone, TyEncodable, TyDecodable, HashStable)]
172-pub enum CheckInAllocMsg {
173- MemoryAccessTest,
174: PointerArithmeticTest,
175- InboundsTest,
176-}
177-
178-impl fmt::Display for CheckInAllocMsg {
179- /// When this is printed as an error the context looks like this
--
182- write!(
183- f,
184- "{}",
185- match *self {
186- CheckInAllocMsg::MemoryAccessTest => "memory access",
187: CheckInAllocMsg::PointerArithmeticTest => "pointer arithmetic",
188- CheckInAllocMsg::InboundsTest => "inbounds test",
189- }
190- )
191- }
192-}
```
Not sure if that is also desirable to be removed, however.
Update BARE_TRAIT_OBJECT and ELLIPSIS_INCLUSIVE_RANGE_PATTERNS to errors in Rust 2021
This addresses https://github.com/rust-lang/rust/pull/81244 by updating two lints to errors in the Rust 2021 edition.
r? `@estebank`
This ensures that `ParamEnv::and` preserves the original `caller_bounds`
when we have a value containing fresh tys/consts. This ensures that when
we cache a `SelectionCandidate`, the cache key (a `ParamEnvAnd`)
contains all of the information that influenced the computation of our
result (e.g. we may end up choosing a `ParamCandidate`)
Move HIR parenting information out of hir_owner
Split out of #82681.
The parent of a HIR node and its content are currently bundled together, but are rarely used together.
This PR separates both information in two distinct queries for HIR owners.
This reduces incremental invalidation for HIR items that appear within a function body when this body (and the local ids) changes.
Move iter_results to dyn FnMut rather than a generic
This means that we're no longer generating the iteration/locking code for each invocation site of iter_results, rather just once per query (roughly), which seems much better: this is a 15% win in instruction counts when compiling the rustc_query_impl crate. The code where this is used also is pretty cold, I suspect; the old solution didn't fully monomorphize either.
Implement RFC 1260 with feature_name `imported_main`.
This is the second extraction part of #84062 plus additional adjustments.
This (mostly) implements RFC 1260.
However there's still one test case failure in the extern crate case. Maybe `LocalDefId` doesn't work here? I'm not sure.
cc https://github.com/rust-lang/rust/issues/28937
r? `@petrochenkov`
This means that we're no longer generating the iteration/locking code for each
invocation site of iter_results, rather just once per query.
This is a 15% win in instruction counts when compiling the rustc_query_impl crate.
Add TRACKED_NO_CRATE_HASH and use it for `--remap-path-prefix`
I verified locally that this fixes https://github.com/rust-lang/rust/issues/66955.
r? `@Aaron1011` (feel free to reassign)
Adds feature-gated `#[no_coverage]` function attribute, to fix derived Eq `0` coverage issue #83601
Derived Eq no longer shows uncovered
The Eq trait has a special hidden function. MIR `InstrumentCoverage`
would add this function to the coverage map, but it is never called, so
the `Eq` trait would always appear uncovered.
Fixes: #83601
The fix required creating a new function attribute `no_coverage` to mark
functions that should be ignored by `InstrumentCoverage` and the
coverage `mapgen` (during codegen).
Adding a `no_coverage` feature gate with tracking issue #84605.
r? `@tmandry`
cc: `@wesleywiser`
The Eq trait has a special hidden function. MIR `InstrumentCoverage`
would add this function to the coverage map, but it is never called, so
the `Eq` trait would always appear uncovered.
Fixes: #83601
The fix required creating a new function attribute `no_coverage` to mark
functions that should be ignored by `InstrumentCoverage` and the
coverage `mapgen` (during codegen).
While testing, I also noticed two other issues:
* spanview debug file output ICEd on a function with no body. The
workaround for this is included in this PR.
* `assert_*!()` macro coverage can appear covered if followed by another
`assert_*!()` macro. Normally they appear uncovered. I submitted a new
Issue #84561, and added a coverage test to demonstrate this issue.
This is necessary for options that should invalidate the incremental
hash but *not* affect the crate hash (e.g. --remap-path-prefix).
This doesn't add `for_crate_hash` to the trait directly because it's not
relevant for *types*, only for *options*, which are fields on a larger
struct. Instead, it adds a new `SUBSTRUCT` directive for options, which
does take a `for_crate_hash` parameter.
- Use TRACKED_NO_CRATE_HASH for --remap-path-prefix
- Add test that `remap_path_prefix` is tracked
- Reduce duplication in the test suite to avoid future churn
Get rid of is_min_const_fn
This removes the last trace of the min_const_fn mechanism by making the unsafety checker agnostic about whether something is a min or "non-min" const fn. It seems this distinction was used to disallow some features inside `const fn`, but that is the responsibility of the const checker, not of the unsafety checker. No test seems to even notice this change in the unsafety checker so I guess we are good...
r? `@oli-obk`
Cc https://github.com/rust-lang/rust/issues/84510
various const parameter defaults improvements
Actually resolve names in const parameter defaults, fixing `struct Foo<const N: usize = { usize::MAX }>`.
---
Split generic parameter ban rib for types and consts, allowing
```rust
#![feature(const_generics_defaults)]
struct Q;
struct Foo<T = Q, const Q: usize = 3>(T);
```
---
Remove the type/const ordering restriction if `const_generics_defaults` is active, even if `const_generics` is not. allowing us to stabilize and test const param defaults separately.
---
Check well formedness of const parameter defaults, eagerly emitting an error for `struct Foo<const N: usize = { 0 - 1 }>`
---
Do not forbid const parameters in param defaults, allowing `struct Foo<const N: usize, T = [u8; N]>(T)` and `struct Foo<const N: usize, const M: usize = N>`. Note that this should not change anything which is stabilized, as on stable, type parameters must be in front of const parameters, which means that type parameter defaults are only allowed if no const parameters exist.
We still forbid generic parameters inside of const param types.
r? `@varkor` `@petrochenkov`
Cautiously add IntoIterator for arrays by value
Add the attribute described in #84133, `#[rustc_skip_array_during_method_dispatch]`, which effectively hides a trait from method dispatch when the receiver type is an array.
Then cherry-pick `IntoIterator for [T; N]` from #65819 and gate it with that attribute. Arrays can now be used as `IntoIterator` normally, but `array.into_iter()` has edition-dependent behavior, returning `slice::Iter` for 2015 and 2018 editions, or `array::IntoIter` for 2021 and later.
r? `@nikomatsakis`
cc `@LukasKalbertodt` `@rust-lang/libs`
further split up const_fn feature flag
This continues the work on splitting up `const_fn` into separate feature flags:
* `const_fn_trait_bound` for `const fn` with trait bounds
* `const_fn_unsize` for unsizing coercions in `const fn` (looks like only `dyn` unsizing is still guarded here)
I don't know if there are even any things left that `const_fn` guards... at least libcore and liballoc do not need it any more.
`@oli-obk` are you currently able to do reviews?
Implement a lint that highlights all moves larger than a configured limit
Tracking issue: #83518
[MCP 420](https://github.com/rust-lang/compiler-team/issues/420) still ~blazing~ in progress
r? ```@pnkfelix```
The main open issue I see with this minimal impl of the feature is that the lint is immediately "stable" (so it can be named on stable), even if it is never executed on stable. I don't think we have the concept of unstable lint names or hiding lint names without an active feature gate, so that would be a bigger change.
