Typical uses of ThinLTO don't have any use for this as a standalone
file, but distributed ThinLTO uses this to make the linker phase more
efficient. With clang you'd do something like `clang -flto=thin
-fthin-link-bitcode=foo.indexing.o -c foo.c` and then get both foo.o
(full of bitcode) and foo.indexing.o (just the summary or index part of
the bitcode). That's then usable by a two-stage linking process that's
more friendly to distributed build systems like bazel, which is why I'm
working on this area.
I talked some to @teresajohnson about naming in this area, as things
seem to be a little confused between various blog posts and build
systems. "bitcode index" and "bitcode summary" tend to be a little too
ambiguous, and she tends to use "thin link bitcode" and "minimized
bitcode" (which matches the descriptions in LLVM). Since the clang
option is thin-link-bitcode, I went with that to try and not add a new
spelling in the world.
Per @dtolnay, you can work around the lack of this by using `lld
--thinlto-index-only` to do the indexing on regular .o files of
bitcode, but that is a bit wasteful on actions when we already have all
the information in rustc and could just write out the matching minimized
bitcode. I didn't test that at all in our infrastructure, because by the
time I learned that I already had this patch largely written.
Add `IntoIterator` for `Box<[T]>` + edition 2024-specific lints
* Adds a similar method probe opt-out mechanism to the `[T;N]: IntoIterator` implementation for edition 2021.
* Adjusts the relevant lints (shadowed `.into_iter()` calls, new source of method ambiguity).
* Adds some tests.
* Took the liberty to rework the logic in the `ARRAY_INTO_ITER` lint, since it was kind of confusing.
Based mostly off of #116607.
ACP: rust-lang/libs-team#263
References #59878
Tracking for Rust 2024: https://github.com/rust-lang/rust/issues/123759
Crater run was done here: https://github.com/rust-lang/rust/pull/116607#issuecomment-1770293013
Consensus afaict was that there is too much breakage, so let's do this in an edition-dependent way much like `[T; N]: IntoIterator`.
Follow-up fixes to `report_return_mismatched_types`
Some renames, simplifications, fixes, etc. Follow-ups to #123804. I don't think it totally disentangles this code, but it does remove some of the worst offenders on the "I am so confused" scale (e.g. `get_node_fn_decl`).
Uplift `RegionVid`, `TermKind` to `rustc_type_ir`, and `EagerResolver` to `rustc_next_trait_solver`
- Uplift `RegionVid`. This was complicated due to the fact that we implement `polonius_engine::Atom` for `RegionVid` -- but I just separated that into `PoloniusRegionVid`, and added `From`/`Into` impls so it can be defined in `rustc_borrowck` separately. Coherence 😵
- Change `InferCtxtLike` to expose `opportunistically_resolve_{ty,ct,lt,int,float}_var` so that we can uplift `EagerResolver` for use in the canonicalization methods.
- Uplift `TermKind` much like `GenericArgKind`
All of this is miscellaneous dependencies for making more `EvalCtxt` methods generic.
track cycle participants per root
The search graph may have multiple roots, e.g. in
```
A :- B
B :- A, C
C :- D
D :- C
```
we first encounter the `A -> B -> A` cycle which causes `A` to be a root. We then later encounter the `C -> D -> C` cycle as a nested goal of `B`. This cycle is completely separate and `C` will get moved to the global cache. This previously caused us to use `[B, D]` as the `cycle_participants` for `C` and `[]` for `A`.
split off from #125167 as I would like to merge this change separately and will rebase that PR on top of this one. There is no test for this issue and I don't quite know how to write one. It is probably worth it to generalize the search graph to enable us to write unit tests for it.
r? `@compiler-errors`
Note for E0599 if shadowed bindings has the method.
implement #123558
Use a visitor to find earlier shadowed bingings which has the method.
r? ``@estebank``
Update `unexpected_cfgs` lint for Cargo new `check-cfg` config
This PR updates the diagnostics output of the `unexpected_cfgs` lint for Cargo new `check-cfg` config.
It's a simple and cost-less alternative to the build-script `cargo::rustc-check-cfg` instruction.
```toml
[lints.rust]
unexpected_cfgs = { level = "warn", check-cfg = ['cfg(foo, values("bar"))'] }
```
This PR also adds a Cargo specific section regarding check-cfg and Cargo inside rustc's book (motivation is described inside the file, but mainly check-cfg is a rustc feature not a Cargo one, Cargo only enabled the feature, it does not own it; T-cargo even considers the `check-cfg` lint config to be an implementation detail).
This PR also updates the links to refer to that sub-page when using Cargo from rustc.
As well as updating the lint doc to refer to the check-cfg docs.
~**Not to be merged before https://github.com/rust-lang/cargo/pull/13913 reaches master!**~ (EDIT: merged in https://github.com/rust-lang/rust/pull/125237)
`@rustbot` label +F-check-cfg
r? `@fmease` *(feel free to roll)*
Fixes https://github.com/rust-lang/rust/issues/124800
cc `@epage` `@weihanglo`
coverage: Memoize and simplify counter expressions
When creating coverage counter expressions as part of coverage instrumentation, we often end up creating obviously-redundant expressions like `c1 + (c0 - c1)`, which is equivalent to just `c0`.
To avoid doing so, this PR checks when we would create an expression matching one of 5 patterns, and uses the simplified form instead:
- `(a - b) + b` → `a`.
- `(a + b) - b` → `a`.
- `(a + b) - a` → `b`.
- `a + (b - a)` → `b`.
- `a - (a - b)` → `b`.
Of all the different ways to combine 3 operands and 2 operators, these are the patterns that allow simplification.
(Some of those patterns currently don't occur in practice, but are included anyway for completeness, to avoid having to add them later as branch coverage and MC/DC coverage support expands.)
---
This PR also adds memoization for newly-created (or newly-simplified) counter expressions, to avoid creating duplicates.
This currently makes no difference to the final mappings, but is expected to be useful for MC/DC coverage of match expressions, as proposed by https://github.com/rust-lang/rust/pull/124278#issuecomment-2106754753.
Suggest setting lifetime in borrowck error involving types with elided lifetimes
```
error: lifetime may not live long enough
--> $DIR/ex3-both-anon-regions-both-are-structs-2.rs:7:5
|
LL | fn foo(mut x: Ref, y: Ref) {
| ----- - has type `Ref<'_, '1>`
| |
| has type `Ref<'_, '2>`
LL | x.b = y.b;
| ^^^^^^^^^ assignment requires that `'1` must outlive `'2`
|
help: consider introducing a named lifetime parameter
|
LL | fn foo<'a>(mut x: Ref<'a, 'a>, y: Ref<'a, 'a>) {
| ++++ ++++++++ ++++++++
```
As can be seen above, it currently doesn't try to compare the `ty::Ty` lifetimes that diverged vs the `hir::Ty` to correctly suggest the following
```
help: consider introducing a named lifetime parameter
|
LL | fn foo<'a>(mut x: Ref<'_, 'a>, y: Ref<'_, 'a>) {
| ++++ ++++++++ ++++++++
```
but I believe this to still be an improvement over the status quo.
Fix#40990.
Make `EvalCtxt` generic over `InferCtxtLike`
...but don't change any of the impls, yet! These can get uplifted as we add more methods to `InferCtxtLike`/`Interner` :3
This is built on top of #125230.
r? lcnr
defrost `RUST_MIN_STACK=ice rustc hello.rs`
I didn't think too hard about testing my previous PR rust-lang/rust#122847 which makes our stack overflow handler assist people in discovering the `RUST_MIN_STACK` variable (which apparently is surprisingly useful for Really Big codebases). After it was merged, some useful comments left in a drive-by review led me to discover I had added an ICE. This reworks the code a bit to explain the rationale, remove the ICE that I introduced, and properly test one of the diagnostics.
fix suggestion in E0373 for !Unpin coroutines
Coroutines can be prefixed with the `static` keyword to make them
`!Unpin`.
However, given the following function:
```rust
fn check() -> impl Sized {
let x = 0;
#[coroutine]
static || {
yield;
x
}
}
```
We currently suggest prefixing `move` before `static`, which is
syntactically incorrect:
```
error[E0373]: coroutine may outlive the current function, but it borrows
...
--> src/main.rs:6:5
|
6 | static || {
| ^^^^^^^^^ may outlive borrowed value `x`
7 | yield;
8 | x
| - `x` is borrowed here
|
note: coroutine is returned here
--> src/main.rs:6:5
|
6 | / static || {
7 | | yield;
8 | | x
9 | | }
| |_____^
help: to force the coroutine to take ownership of `x` (and any other
referenced variables), use the `move` keyword
| // this is syntactically incorrect, it should be `static move ||`
6 | move static || {
| ++++
```
This PR suggests adding `move` after `static` for these coroutines.
I also added a UI test for this case.
Never type unsafe lint improvements
- Move linting code to a separate method
- Remove mentions of `core::convert::absurd` (#124311 was rejected)
- Make the lint into FCW
The last thing is a bit weird though. On one hand it should be `EditionSemanticsChange(2024)`, but on the other hand it shouldn't, because we also plan to break it on all editions some time later. _Also_, it's weird that we don't have `FutureReleaseSemanticsChangeReportInDeps`, IMO "this might cause UB in a future release" is important enough to be reported in deps...
IMO we ought to have three enums instead of [`FutureIncompatibilityReason`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_lint_defs/enum.FutureIncompatibilityReason.html#):
```rust
enum IncompatibilityWhen {
FutureRelease,
Edition(Edition),
}
enum IncompatibilyWhat {
Error,
SemanticChange,
}
enum IncompatibilityReportInDeps {
No,
Yes,
}
```
Tracking:
- https://github.com/rust-lang/rust/issues/123748
An earlier commit included the change for a suggestion here.
Unfortunately, it also used unwrap instead of dying properly.
Roll out the ~~rice paper~~ EarlyDiagCtxt before we do anything that
might leave a mess.
Coroutines can be prefixed with the `static` keyword to make them
`!Unpin`.
However, given the following function:
```rust
fn check() -> impl Sized {
let x = 0;
#[coroutine]
static || {
yield;
x
}
}
```
We currently suggest prefixing `move` before `static`, which is
syntactically incorrect:
```
error[E0373]: coroutine may outlive the current function, but it borrows
...
--> src/main.rs:6:5
|
6 | static || {
| ^^^^^^^^^ may outlive borrowed value `x`
7 | yield;
8 | x
| - `x` is borrowed here
|
note: coroutine is returned here
--> src/main.rs:6:5
|
6 | / static || {
7 | | yield;
8 | | x
9 | | }
| |_____^
help: to force the coroutine to take ownership of `x` (and any other
referenced variables), use the `move` keyword
| // this is syntactically incorrect, it should be `static move ||`
6 | move static || {
| ++++
```
This PR suggests adding `move` after `static` for these coroutines.
chore: Remove repeated words (extension of #124924)
When I saw #124924 I thought "Hey, I'm sure that there are far more than just two typos of this nature in the codebase". So here's some more typo-fixing.
Some found with regex, some found with a spellchecker. Every single one manually reviewed by me (along with hundreds of false negatives by the tools)
