Reland #74069
Investigation in #74716 has concluded that this PR is indeed not a regression (and in fact the rollup itself is not either).
This reverts the revert in #74611.
r? @nnethercote cc @eddyb
Tweak conditions for E0026 and E0769
When we have a tuple struct used with struct we don't want to suggest using the (valid) struct syntax with numeric field names. Instead we want to suggest the expected syntax.
Given
```rust
fn main() {
match MyOption::MySome(42) {
MyOption::MySome { x: 42 } => (),
_ => (),
}
}
```
We now emit E0769 "tuple variant `MyOption::MySome` written as struct variant" instead of E0026 "variant `MyOption::MySome` does not have a field named `x`".
polymorphize: constrain unevaluated const handling
This PR constrains the support added for handling unevaluated consts in polymorphization (introduced in #75260) by:
- Skipping associated constants as this causes cycle errors.
- Skipping promoted constants when they contain `Self` as this ensures `T` is used in constants of the form `<Self as Foo<T>>`.
Due to an oversight on my part, when landing #75260 and #75255, some tests started failing when polymorphization was enabled that I didn't notice until after landing - this PR fixes the regressions from #75260.
r? @lcnr
Use existing `infcx` when emitting trait impl diagnostic
Fixes#75361Fixes#74918
Previously, we were creating a new `InferCtxt`, which caused an ICE when
used with type variables from the existing `InferCtxt`
Clean up errors in typeck and resolve
* Tweak ordering of suggestions
* Do not suggest similarly named enclosing item
* Point at item definition in foreign crates
* Add missing primary label
CC #34255.
Remove restriction on type parameters preceding consts w/ feature const-generics
Removed the restriction on type parameters preceding const parameters when the feature const-generics is enabled.
Builds on #74676, which deals with unsorted generic parameters. This just lifts the check in lowering the AST to HIR that permits consts and types to be reordered with respect to each other. Lifetimes still must precede both
This change is not intended for min-const-generics, and is gated behind the `#![feature(const_generics)]`.
One thing is that it also permits type parameters without a default to come after consts, which I expected to not work, and was hoping to get more guidance on whether that should be permitted or how to prevent it otherwise.
I did not go through the RFC process for this pull request because there was prior work to get this feature added. In the previous PR that was cited, work was done to enable this change.
r? @lcnr
This commit constrains the support added for handling unevaluated consts
in polymorphization (introduced in #75260) by:
- Skipping associated constants as this causes cycle errors.
- Skipping promoted constants when they contain `Self` as this ensures
`T` is used in constants of the form `<Self as Foo<T>>`.
Signed-off-by: David Wood <david@davidtw.co>
When we have a tuple struct used with struct we don't want to suggest using
the (valid) struct syntax with numeric field names. Instead we want to
suggest the expected syntax.
Given
```rust
fn main() {
match MyOption::MySome(42) {
MyOption::MySome { x: 42 } => (),
_ => (),
}
}
```
We now emit E0769 "tuple variant `MyOption::MySome` written as struct variant"
instead of E0026 "variant `MyOption::MySome` does not have a field named `x`".
Rollup of 8 pull requests
Successful merges:
- #74200 (Std panicking unsafe block in unsafe fn)
- #75286 (Add additional case for Path starts with)
- #75318 (Resolve `char` as a primitive even if there is a module in scope)
- #75320 (Detect likely `for foo of bar` JS syntax)
- #75328 (Cleanup E0749)
- #75344 (Rename "Important traits" to "Notable traits")
- #75348 (Move to intra-doc links in library/core/src/time.rs)
- #75350 (Do not ICE when lowering invalid extern fn with bodies)
Failed merges:
r? @ghost
Confusable idents detection uses a type `BTreeMap<Symbol, Span>`. This is
highly dubious given that `Symbol` doesn't guarantee a meaningful order. (In
practice, it currently gives an order that mostly matches source code order.)
As a result, changes in `Symbol` representation make the
`lint-confusable-idents.rs` test fail, because this error message:
> identifier pair considered confusable between `ｓ` and `s`
is changed to this:
> identifier pair considered confusable between `s` and `ｓ`
and the corresponding span pointers get swapped erroneously, leading to
an incorrect "previous identifier" label.
This commit sorts the relevant symbols by span before doing the checking,
which ensures that the ident that appears first in the code will be mentioned
first in the message. The commit also extends the test slightly to be more
thorough.
Fixes#74800
The definition of `is_x86_feature_detected!` (and similar macros)
depends on the platform - it is produced by a `cfg_if!` invocation on
x86, and a plain `#[cfg]` on other platforms. Since it is part of the
prelude, we will end up importing different hygiene information
depending on the platform. This previously required us to avoid printing raw
`SyntaxContext` ids in any tests that uses the standard library, since
the captured output will be platform-dependent.
Previously, we replaced all `SyntaxContext` ids with "#CTXT", and the
raw `Span` lo/hi bytes with "LO..HI".
This commit adds `#![no_std]` and `extern crate std` to all proc-macro
tests that print spans. This suppresses the prelude import, while
still using lang items from `std` (which gives us a buildable binary).
With this apporach, we will only load hygiene information for things
which we explicitly import. This lets us re-add
`-Z unpretty=expanded,hygiene`, since its output can now be made stable
across all platforms.
Additionally, we use `-Z span-debug` in more places, which lets us avoid
the "LO..HI" normalization hack.
Updated tests and error msgs
Update stderr from test
Update w/ lcnr comments
Change some tests around, and also updated Ord implementation for ParamKindOrd
Update w/ nits from lcnr
Added this test to ensure that reordering the parameters only works with the feature const
generics enabled.
Fixed nits
Also added another test to verify that intermixed lifetimes are forbidden
polymorphize: unevaluated constants
This PR makes polymorphization visit the promoted MIR of unevaluated constants with available promoted MIR instead of visiting the substitutions of that constant - which will mark all of the generic parameters as used; in addition polymorphization will now visit non-promoted unevaluated constants rather than visit their substs.
r? @lcnr
Implement the `min_const_generics` feature gate
Implements both https://github.com/rust-lang/lang-team/issues/37 and https://github.com/rust-lang/compiler-team/issues/332.
Adds the new feature gate `#![feature(min_const_generics)]`.
This feature gate adds the following limitations to using const generics:
- generic parameters must only be used in types if they are trivial. (either `N` or `{ N }`)
- generic parameters must be either integers, `bool` or `char`.
We do allow arbitrary expressions in associated consts though, meaning that the following is allowed,
even if `<[u8; 0] as Foo>::ASSOC` is not const evaluatable.
```rust
trait Foo {
const ASSOC: usize;
}
impl<const N: usize> Foo for [u8; N] {
const ASSOC: usize = 64 / N;
}
```
r? @varkor cc @eddyb @withoutboats
Prevent `__rust_begin_short_backtrace` frames from being tail-call optimised away
I've stumbled across some situations where there (unexpectedly) was no `__rust_begin_short_backtrace` frame on the stack during unwinding.
On closer examination, it appeared that the calls to that function had been tail-call optimised away.
This PR follows [@bjorn3's suggestion on Zulip](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/Disabling.20tail.20call.20optimisation.3F/near/205699133), by adding calls to `black_box` that hint to rustc not to perform TCO.
Fixes#47429
instance: polymorphize upvar closures/generators
This PR modifies how instances are polymorphized so that closures and generators have any closures or generators captured within their upvars also polymorphized.
With the new symbol mangling, a fully polymorphised closure will produce the same symbol regardless of what it was instantiated with. However, when that polymorphised closure captures another closure as an upvar, then the type of that other closure in the upvar substitution wouldn't have been polymorphised. The other closure will still refer to the initial substitutions. Therefore, the polymorphised closure will end up hashing differently but producing the same symbol - triggering `assert_symbols_are_distinct` in MIR partitioning. The old mangling scheme had a hash at the end that meant this didn't happen (this would still have been an issue, we just didn't have a way to notice).
See [this Zulip discussion for further elaboration](https://rust-lang.zulipchat.com/#narrow/stream/216091-t-compiler.2Fwg-polymorphization/topic/symbol.20mangling.20v0.20.E2.9C.95.20polymorphisation/near/206152008).
r? @eddyb
cc @lcnr
