Point out the type of associated types in every method call of iterator chains
Partially address #105184 by pointing out the type of associated types in every method call of iterator chains:
```
note: the expression is of type `Map<std::slice::Iter<'_, {integer}>, [closure@src/test/ui/iterators/invalid-iterator-chain.rs:12:18: 12:21]>`
--> src/test/ui/iterators/invalid-iterator-chain.rs:12:14
|
10 | vec![0, 1]
| ---------- this expression has type `Vec<{integer}>`
11 | .iter()
| ------ associated type `std::iter::Iterator::Item` is `&{integer}` here
12 | .map(|x| { x; })
| ^^^^^^^^^^^^^^^ associated type `std::iter::Iterator::Item` is `()` here
```
We also reduce the number of impls we mention when any of the candidates is an "exact match". This benefits the output of cases with numerics greatly.
Outstanding work would be to provide a structured suggestion for appropriate changes, like in this case detecting the spurious `;` in the closure.
Use struct types during codegen in less places
This makes it easier to use cg_ssa from a backend like Cranelift that doesn't have any struct types at all. After this PR struct types are still used for function arguments and return values. Removing those usages is harder but should still be doable.
Remove `token::Lit` from `ast::MetaItemLit`.
Currently `ast::MetaItemLit` represents the literal kind twice. This PR removes that redundancy. Best reviewed one commit at a time.
r? `@petrochenkov`
Fix lint perf regressions
#104863 caused small but widespread regressions in lint performance. I tried to improve things in #105291 and #105416 with minimal success, before fully understanding what caused the regression. This PR effectively reverts all of #105291 and part of #104863 to fix the perf regression.
r? `@cjgillot`
Make encode_info_for_trait_item use queries instead of accessing the HIR
This change avoids accessing the HIR on `encode_info_for_trait_item` and uses queries. We will need to execute this function for elements that have no HIR and by using queries we will be able to feed for definitions that have no HIR.
r? ``@oli-obk``
This commit partly undoes #104863, which combined the builtin lints pass
with other lints. This caused a slowdown, because often there are no
other lints, and it's faster to do a pass with a single lint directly
than it is to do a combined pass with a `passes` vector containing a
single lint.
I removed these in #105291, and subsequently learned they are necessary
for performance.
This commit reinstates them with the new and more descriptive names
`RuntimeCombined{Early,Late}LintPass`, similar to the existing passes
like `BuiltinCombinedEarlyLintPass`. It also adds some comments,
particularly emphasising how we have ways to combine passes at both
compile-time and runtime. And it moves some comments around.
When encountering an unmet obligation that affects a method chain, like
in iterator chains where one of the links has the wrong associated
type, we point at every method call and mention their evaluated
associated type at that point to give context to the user of where
expectations diverged from the code as written.
```
note: the expression is of type `Map<std::slice::Iter<'_, {integer}>, [closure@$DIR/invalid-iterator-chain.rs:12:18: 12:21]>`
--> $DIR/invalid-iterator-chain.rs:12:14
|
LL | vec![0, 1]
| ---------- this expression has type `Vec<{integer}>`
LL | .iter()
| ------ associated type `std::iter::Iterator::Item` is `&{integer}` here
LL | .map(|x| { x; })
| ^^^^^^^^^^^^^^^ associated type `std::iter::Iterator::Item` is `()` here
```
Don't internalize __llvm_profile_counter_bias
Currently, LLVM profiling runtime counter relocation cannot be used by rust during LTO because symbols are being internalized before all symbol information is known.
This mode makes LLVM emit a __llvm_profile_counter_bias symbol which is referenced by the profiling initialization, which itself is pulled in by the rust driver here [1].
It is enabled with -Cllvm-args=-runtime-counter-relocation for platforms which are opt-in to this mode like Linux. On these platforms there will be no link error, rather just surprising behavior for a user which request runtime counter relocation. The profiling runtime will not see that symbol go on as if it were never there. On Fuchsia, the profiling runtime must have this symbol which will cause a hard link error.
As an aside, I don't have enough context as to why rust's LTO model is how it is. AFAICT, the internalize pass is only safe to run at link time when all symbol information is actually known, this being an example as to why. I think special casing this symbol as a known one that LLVM can emit which should not have it's visbility de-escalated should be fine given how seldom this pattern of defining an undefined symbol to get initilization code pulled in is. From a quick grep, __llvm_profile_runtime is the only symbol that rustc does this for.
[1] 0265a3e93b/compiler/rustc_codegen_ssa/src/back/linker.rs (L598)
compiler: remove unnecessary imports and qualified paths
Some of these imports were necessary before Edition 2021, others were already in the prelude.
I hope it's fine that this PR is so spread-out across files :/
Some method confirmation code nits
1. Make some pick methods take `&self` instead of `&mut` to avoid some cloning
2. Pass some values by reference to avoid some cloning
3. Rename a few variables here and there
Fix invalid codegen during debuginfo lowering
In order for LLVM to correctly generate debuginfo for msvc, we sometimes need to spill arguments to the stack and perform some direct & indirect offsets into the value. Previously, this code always performed those actions, even when not required as LLVM would clean it up during optimization.
However, when MIR inlining is enabled, this can cause problems as the operations occur prior to the spilled value being initialized. To solve this, we first calculate the necessary offsets using just the type which is side-effect free and does not alter the LLVM IR. Then, if we are in a situation which requires us to generate the LLVM IR (and this situation only occurs for arguments, not local variables) then we perform the same calculation again, this time generating the appropriate LLVM IR as we go.
r? `@tmiasko` but feel free to reassign if you want 🙂Fixes#105386
Migrate parts of `rustc_expand` to session diagnostics
This migrates everything but the `mbe` and `proc_macro` modules. It also contains a few cleanups and drive-by/accidental diagnostic improvements which can be seen in the diff for the UI tests.
Rollup of 10 pull requests
Successful merges:
- #98391 (Reimplement std's thread parker on top of events on SGX)
- #104019 (Compute generator sizes with `-Zprint_type_sizes`)
- #104512 (Set `download-ci-llvm = "if-available"` by default when `channel = dev`)
- #104901 (Implement masking in FileType comparison on Unix)
- #105082 (Fix Async Generator ABI)
- #105109 (Add LLVM KCFI support to the Rust compiler)
- #105505 (Don't warn about unused parens when they are used by yeet expr)
- #105514 (Introduce `Span::is_visible`)
- #105516 (Update cargo)
- #105522 (Remove wrong note for short circuiting operators)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
This migrates everything but the `mbe` and `proc_macro` modules. It also
contains a few cleanups and drive-by/accidental diagnostic improvements
which can be seen in the diff for the UI tests.
Add LLVM KCFI support to the Rust compiler
This PR adds LLVM Kernel Control Flow Integrity (KCFI) support to the Rust compiler. It initially provides forward-edge control flow protection for operating systems kernels for Rust-compiled code only by aggregating function pointers in groups identified by their return and parameter types. (See llvm/llvm-project@cff5bef.)
Forward-edge control flow protection for C or C++ and Rust -compiled code "mixed binaries" (i.e., for when C or C++ and Rust -compiled code share the same virtual address space) will be provided in later work as part of this project by identifying C char and integer type uses at the time types are encoded (see Type metadata in the design document in the tracking issue #89653).
LLVM KCFI can be enabled with -Zsanitizer=kcfi.
Thank you again, `@bjorn3,` `@eddyb,` `@nagisa,` and `@ojeda,` for all the help!
Fix Async Generator ABI
This change was missed when making async generators implement `Future` directly.
It did not cause any problems in codegen so far, as `GeneratorState<(), Output>`
happens to have the same ABI as `Poll<Output>`.
Rollup of 9 pull requests
Successful merges:
- #102406 (Make `missing_copy_implementations` more cautious)
- #105265 (Add `rustc_on_unimplemented` to `Sum` and `Product` trait.)
- #105385 (Skip test on s390x as LLD does not support the platform)
- #105453 (Make `VecDeque::from_iter` O(1) from `vec(_deque)::IntoIter`)
- #105468 (Mangle "main" as "__main_void" on wasm32-wasi)
- #105480 (rustdoc: remove no-op mobile CSS `#sidebar-toggle { text-align }`)
- #105489 (Fix typo in apple_base.rs)
- #105504 (rustdoc: make stability badge CSS more consistent)
- #105506 (Tweak `rustc_must_implement_one_of` diagnostic output)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Mangle "main" as "__main_void" on wasm32-wasi
On wasm, the age-old C trick of having a main function which can either have no arguments or argc+argv doesn't work, because wasm requires caller and callee signatures to match. WASI's current strategy is to have compilers mangle main's name to indicate which signature they're using. Rust uses the no-argument form, which should be mangled as `__main_void`.
This is needed on wasm32-wasi as of #105395.
Make `missing_copy_implementations` more cautious
- Fixes https://github.com/rust-lang/rust/issues/98348
- Also makes the lint not fire on large types and types containing raw pointers. Thoughts?
Shrink `rustc_parse_format::Piece`
This makes both variants closer together in size (previously they were different by 208 bytes -- 16 vs 224). This may make things worse, but it's worth a try.
r? `@nnethercote`
use the correct `Reveal` during validation
supersedes #105454. Deals with https://github.com/rust-lang/rust/issues/105009#issuecomment-1342395333, not closing #105009 as the ICE may leak into beta
The issue was the following:
- we optimize the mir, using `Reveal::All`
- some optimization relies on the hidden type of an opaque type
- we then validate using `Reveal::UserFacing` again which is not able to observe the hidden type
r? `@jackh726`
Move some queries and methods
Each commit's title should be self-explanatory. Motivated to break up some large, general files and move queries into leaf crates.
In order for LLVM to correctly generate debuginfo for msvc, we sometimes
need to spill arguments to the stack and perform some direct & indirect
offsets into the value. Previously, this code always performed those
actions, even when not required as LLVM would clean it up during
optimization.
However, when MIR inlining is enabled, this can cause problems as the
operations occur prior to the spilled value being initialized. To solve
this, we first calculate the necessary offsets using just the type which
is side-effect free and does not alter the LLVM IR. Then, if we are in a
situation which requires us to generate the LLVM IR (and this situation
only occurs for arguments, not local variables) then we perform the same
calculation again, this time generating the appropriate LLVM IR as we
go.
This commit adds LLVM Kernel Control Flow Integrity (KCFI) support to
the Rust compiler. It initially provides forward-edge control flow
protection for operating systems kernels for Rust-compiled code only by
aggregating function pointers in groups identified by their return and
parameter types. (See llvm/llvm-project@cff5bef.)
Forward-edge control flow protection for C or C++ and Rust -compiled
code "mixed binaries" (i.e., for when C or C++ and Rust -compiled code
share the same virtual address space) will be provided in later work as
part of this project by identifying C char and integer type uses at the
time types are encoded (see Type metadata in the design document in the
tracking issue #89653).
LLVM KCFI can be enabled with -Zsanitizer=kcfi.
Co-authored-by: bjorn3 <17426603+bjorn3@users.noreply.github.com>
This change was missed when making async generators implement `Future` directly.
It did not cause any problems in codegen so far, as `GeneratorState<(), Output>`
happens to have the same ABI as `Poll<Output>`.
On wasm, the age-old C trick of having a main function which can either have
no arguments or argc+argv doesn't work, because wasm requires caller and
callee signatures to match. WASI's current strategy is to have compilers
mangle main's name to indicate which signature they're using. Rust uses the
no-argument form, which should be mangled as `__main_void`.
This is needed on wasm32-wasi as of #105395.
