Fix regionck failure when converting Index to IndexMut
Fixes#74933
Consider an overloaded index expression `base[index]`. Without knowing whether it will be mutated, this will initially be desugared into `<U as Index<T>>::index(&base, index)` for some `U` and `T`. Let `V` be the `expr_ty_adjusted` of `index`.
If this expression ends up being used in any mutable context (or used in a function call with `&mut self` receiver before #72280), we will need to fix it up. The current code will rewrite it to `<U as IndexMut<V>>::index_mut(&mut base, index)`. In most cases this is fine as `V` will be equal to `T`, however this is not always true when `V/T` are references, as they may have different region.
This issue is quite subtle before #72280 as this code path is only used to fixup function receivers, but after #72280 we've made this a common path.
The solution is basically just rewrite it to `<U as IndexMut<T>>::index_mut(&mut base, index)`. `T` can retrieved in the fixup path using `node_substs`.
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
move Deaggregate pass to post_borrowck_cleanup
Reopen of #71946
Only the second commit is from this PR, the other commit is a bugfix that's in the process of getting merged. I'll rebase once that's done
In #70073 MIR pass handling got reorganized, but with the goal of not changing behavior (except for disabling some optimizations on opt-level = 0). But there we realized that the Deaggregator pass, while conceptually more of a "cleanup" pass (and one that should be run before optimizations), was run in the middle of the optimization chain. Likely this is an accident of history, so I suggest we try and clean that up by making it a proper cleanup pass.
This does change mir-opt output, because deaggregation now runs before const-prop instead of after.
r? @wesleywiser @rust-lang/wg-mir-opt
cc @RalfJung
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`
instance: only polymorphize upvar substs
This PR restricts the substitution polymorphization added in #75255 to only apply to the tupled upvar substitution, rather than all substitutions, fixing a bunch of regressions when polymorphization is
enabled.
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 #75255. #75336 has been filed to make sure that we don't forget to try make this change again in future, as it does enable some optimisations.
r? @lcnr
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.
This commit restricts the substitution polymorphization added in #75255
to only apply to the tupled upvar substitution, rather than all
substitutions, fixing a bunch of regressions when polymorphization is
enabled.
Signed-off-by: David Wood <david@davidtw.co>
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
Emit == null instead of <= null for niche check
When the niche maximum is zero, emit a "== zero" check instead of a "<= zero" check. In particular, this avoids the awkward case of "<= null". While LLVM does canonicalize this to "== null", this apparently doesn't happen for constant expressions, leading to the issue in #74425. While that can be addressed on the LLVM side, it still seems prudent to emit sensible IR here, because this will allow null checks to be optimized earlier in the pipeline.
Fixes#74425.
When the niche maximum is zero, emit a "== zero" check instead of
a "<= zero" check. In particular, this avoid the awkward case of
"<= null". While LLVM does canonicalize this to "!= null", this
appently doesn't happen for constant expressions, leading to the
issue in #74425. While that can be addressed on the LLVM side, it
still seems prudent to emit sensible IR here, because this will
allow null checks to be optimized earlier in the pipeline.
Fixes#74425.
