fix: wrong trait import suggestion for T:
The suggestion to bound `T` had an extra `:`.
```rust
fn foo<T:>(t: T) {
t.clone();
}
```
```
error[E0599]: no method named `clone` found for type parameter `T` in the current scope
--> src/lib.rs:2:7
|
2 | t.clone();
| ^^^^^ method not found in `T`
|
= help: items from traits can only be used if the type parameter is bounded by the trait
help: the following trait defines an item `clone`, perhaps you need to restrict type parameter `T` with it:
|
1 | fn foo<T: Clone:>(t: T) {
| ~~~~~~~~
```
Fixes: #95898
Use mir constant in thir instead of ty::Const
This is blocked on https://github.com/rust-lang/rust/pull/94059 (does include its changes, the first two commits in this PR correspond to those changes) and https://github.com/rust-lang/rust/pull/93800 being reinstated (which had to be reverted). Mainly opening since `@lcnr` offered to give some feedback and maybe also for a perf-run (if necessary).
This currently contains a lot of duplication since some of the logic of `ty::Const` had to be copied to `mir::ConstantKind`, but with the introduction of valtrees a lot of that functionality will disappear from `ty::Const`.
Only the last commit contains changes that need to be reviewed here. Did leave some `FIXME` comments regarding future implementation decisions and some things that might be incorrectly implemented.
r? `@oli-obk`
prevent opaque types from appearing in impl headers
cc `@lqd`
opaque types are not distinguishable from their hidden type at the codegen stage. So we could either end up with cases where the hidden type doesn't implement the trait (which will thus ICE) or where the hidden type does implement the trait (so we'd be using its impl instead of the one written for the opaque type). This can even lead to unsound behaviour without unsafe code.
Fixes https://github.com/rust-lang/rust/issues/86411.
Fixes https://github.com/rust-lang/rust/issues/84660.
rebase of #87382 plus some diagnostic tweaks
Fix suggestions in case of `T:` bounds
This PR fixes a corner case in `suggest_constraining_type_params` that was causing incorrect suggestions.
For the following functions:
```rust
fn a<T:>(t: T) { [t, t]; }
fn b<T>(t: T) where T: { [t, t]; }
```
We previously suggested the following:
```text
...
help: consider restricting type parameter `T`
|
1 | fn a<T: Copy:>(t: T) { [t, t]; }
| ++++++
...
help: consider further restricting this bound
|
2 | fn b<T>(t: T) where T: + Copy { [t, t]; }
| ++++++
```
Note that neither `T: Copy:` not `where T: + Copy` is a correct bound.
With this commit the suggestions are correct:
```text
...
help: consider restricting type parameter `T`
|
1 | fn a<T: Copy>(t: T) { [t, t]; }
| ++++
...
help: consider further restricting this bound
|
2 | fn b<T>(t: T) where T: Copy { [t, t]; }
| ++++
```
r? `@compiler-errors`
I've tried fixing #95898 here too, but got too confused with how `suggest_traits_to_import` works and what it does 😅
Move name resolution logic to a dedicated file
The code resolution logic from an Ident is scattered between several files.
The first commits creates `rustc_resolve::probe` module to hold the different mutually recursive functions together. Just a move, no code change.
The following commits attempt to make the logic a bit more readable.
The two fields `last_import_segment` and `unusable_binding` are replaced by function parameters.
In order to manage the fallout, `maybe_` variants of the function are added, dedicated to speculative resolution.
r? `@petrochenkov`
Rollup of 4 pull requests
Successful merges:
- #95783 (rustdoc doctest: include signal number in exit status)
- #95794 (`parse_tt`: a few more tweaks)
- #95963 ([bootstrap] Grab the right FileCheck binary for dist when cross-compiling.)
- #95975 (Don't test -Cdefault-linker-libraries=yes when cross compiling.)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Skip `Lazy` for some metadata tables
Some metadata tables encode their entries indirectly, through the Lazy construct. This is useful when dealing with variable length encoding, but incurs the extra cost of one u32.
Meanwhile, some fields can be encoded in a single u8, or can use a short fixed-length encoding. This PR proposes to do so, and avoid the overhead.
`impl const Default for Box<[T]>` and `Box<str>`
The unstable `const_default_impls` (#87864) already include empty `Vec<T>` and `String`. Now we extend that concept to `Box<[T]>` and `Box<str>` as well.
This obviates a hack in `rustc_ast`'s `P::<[T]>::new`.
Instead of checking only the user provided sysroot or the default (when
no sysroot is provided), search user provided sysroot and then check
default sysroots for locale requested by the user.
Signed-off-by: David Wood <david.wood@huawei.com>
use `Span::find_ancestor_inside` to get right span in CastCheck
This is a quick fix. This bad suggestion likely lives in other places... but thought it would be useful to fix all of the CastCheck ones first.
Let me know if reviewer would prefer I add more tests for each of the diagnostics in CastCheck, or would like to do a more thorough review of other suggestions that use spans in typeck. I would also be open to further suggestions on how to better expose an API that gives us the "best" span for a diagnostic suggestion.
Fixed#95919
Fix crate_type attribute to not warn on duplicates
In #88681 I accidentally marked the `crate_type` attribute as only allowing a single attribute. However, multiple attributes are allowed (they are joined together [here](027a232755/compiler/rustc_interface/src/util.rs (L530-L542))). This fixes it to not report a warning if duplicates are found.
Closes#95902
Document the current MIR semantics that are clear from existing code
This PR adds documentation to places, operands, rvalues, statementkinds, and terminatorkinds that describes their existing semantics and requirements. In many places the semantics depend on the Rust memory model or other T-Lang decisions - when this is the case, it is just noted as such with links to UCG issues where possible. I'm hopeful that none of the documentation added here can be used to justify optimizations that depend on the memory model. The documentation for places and operands probably comes closest to running afoul of this - if people think that it cannot be merged as is, it can definitely also be taken out.
The goal here is to only document parts of MIR that seem to be decided already, or are at least depended on by existing code. That leaves quite a number of open questions - those are marked as "needs clarification." I'm not sure what to do with those in this PR - we obviously can't decide all these questions here. Should I just leave them in as is? Take them out? Keep them in but as `//` instead of `///` comments?
If this is too big to review at once, I can split this up.
r? rust-lang/mir-opt
Respect -Z verify-llvm-ir and other flags that add extra passes when combined with -C no-prepopulate-passes in the new LLVM Pass Manager.
As part of the switch to the new LLVM Pass Manager the behaviour of flags such as `-Z verify-llvm-ir` (e.g. sanitizer, instrumentation) was modified when combined with `-C no-prepopulate-passes`. With the old PM, rustc was the one manually constructing the pipeline and respected those flags but in the new pass manager, those flags are used to build a list of callbacks that get invoked at certain extension points in the pipeline. Unfortunately, `-C no-prepopulate-passes` would skip building the pipeline altogether meaning we'd never add the corresponding passes. The fix here is to just manually invoke those callbacks as needed.
Fixes#95874
Demonstrating the current vs fixed behaviour using the bug in #95864
```console
$ rustc +nightly asm-miscompile.rs --edition 2021 --emit=llvm-ir -C no-prepopulate-passes -Z verify-llvm-ir
$ echo $?
0
$ rustc +stage1 asm-miscompile.rs --edition 2021 --emit=llvm-ir -C no-prepopulate-passes -Z verify-llvm-ir
Basic Block in function '_ZN14asm_miscompile3foo28_$u7b$$u7b$closure$u7d$$u7d$17h360e2f7eee1275c5E' does not have terminator!
label %bb1
LLVM ERROR: Broken module found, compilation aborted!
```
