- make Allocation API offset-based (no more Pointer)
- make Memory API higher-level (combine checking for access and getting access into one operation)
Rollup of 7 pull requests
Successful merges:
- #84587 (rustdoc: Make "rust code block is empty" and "could not parse code block" warnings a lint (`INVALID_RUST_CODEBLOCKS`))
- #85280 (Toggle-wrap items differently than top-doc.)
- #85338 (Implement more Iterator methods on core::iter::Repeat)
- #85339 (Report an error if a lang item has the wrong number of generic arguments)
- #85369 (Suggest borrowing if a trait implementation is found for &/&mut <type>)
- #85393 (Suppress spurious errors inside `async fn`)
- #85415 (Clean up remnants of BorrowOfPackedField)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Suggest borrowing if a trait implementation is found for &/&mut <type>
This pull request fixes#84973 by suggesting to borrow if a trait is not implemented for some type `T`, but it is for `&T` or `&mut T`. For instance:
```rust
trait Ti {}
impl<T> Ti for &T {}
fn foo<T: Ti>(_: T) {}
trait Tm {}
impl<T> Tm for &mut T {}
fn bar<T: Tm>(_: T) {}
fn main() {
let a: i32 = 5;
foo(a);
let b: Box<i32> = Box::new(42);
bar(b);
}
```
gives, on current nightly:
```
error[E0277]: the trait bound `i32: Ti` is not satisfied
--> t2.rs:11:9
|
3 | fn foo<T: Ti>(_: T) {}
| -- required by this bound in `foo`
...
11 | foo(a);
| ^ the trait `Ti` is not implemented for `i32`
error[E0277]: the trait bound `Box<i32>: Tm` is not satisfied
--> t2.rs:14:9
|
7 | fn bar<T: Tm>(_: T) {}
| -- required by this bound in `bar`
...
14 | bar(b);
| ^ the trait `Tm` is not implemented for `Box<i32>`
error: aborting due to 2 previous errors
```
whereas with my changes, I get:
```
error[E0277]: the trait bound `i32: Ti` is not satisfied
--> t2.rs:11:9
|
3 | fn foo<T: Ti>(_: T) {}
| -- required by this bound in `foo`
...
11 | foo(a);
| ^
| |
| expected an implementor of trait `Ti`
| help: consider borrowing here: `&a`
error[E0277]: the trait bound `Box<i32>: Tm` is not satisfied
--> t2.rs:14:9
|
7 | fn bar<T: Tm>(_: T) {}
| -- required by this bound in `bar`
...
14 | bar(b);
| ^
| |
| expected an implementor of trait `Tm`
| help: consider borrowing mutably here: `&mut b`
error: aborting due to 2 previous errors
```
In my implementation, I have added a "blacklist" to make these suggestions flexible. In particular, suggesting to borrow can interfere with other suggestions, such as to add another trait bound to a generic argument. I have tried to configure this blacklist to cause the least amount of test case failures, i.e. to model the current behavior as closely as possible (I only had to change one existing test case, and this change was quite clearly an improvement).
Report an error if a lang item has the wrong number of generic arguments
This pull request fixes#83893. The issue is that the lang item code currently checks whether the lang item has the correct item kind (e.g. a `#[lang="add"]` has to be a trait), but not whether the item has the correct number of generic arguments.
This can lead to an "index out of bounds" ICE when the compiler tries to create more substitutions than there are suitable types available (if the lang item was declared with too many generic arguments).
For instance, here is a reduced ("reduced" in the sense that it does not trigger additional errors) version of the example given in #83893:
```rust
#![feature(lang_items,no_core)]
#![no_core]
#![crate_type="lib"]
#[lang = "sized"]
trait MySized {}
#[lang = "add"]
trait MyAdd<'a, T> {}
fn ice() {
let r = 5;
let a = 6;
r + a
}
```
On current nightly, this immediately causes an ICE without any warnings or errors emitted. With the changes in this PR, however, I get no ICE and two errors:
```
error[E0718]: `add` language item must be applied to a trait with 1 generic argument
--> pr-ex.rs:8:1
|
8 | #[lang = "add"]
| ^^^^^^^^^^^^^^^
9 | trait MyAdd<'a, T> {}
| ------- this trait has 2 generic arguments, not 1
error[E0369]: cannot add `{integer}` to `{integer}`
--> pr-ex.rs:14:7
|
14 | r + a
| - ^ - {integer}
| |
| {integer}
error: aborting due to 2 previous errors
Some errors have detailed explanations: E0369, E0718.
For more information about an error, try `rustc --explain E0369`.
```
Unify Regions with RegionVids in UnificationTable
A few test output changes; might be able to revert those but figured I would open this for perf and comments.
r? `@nikomatsakis`
# Stabilization report
## Summary
This stabilizes using macro expansion in key-value attributes, like so:
```rust
#[doc = include_str!("my_doc.md")]
struct S;
#[path = concat!(env!("OUT_DIR"), "/generated.rs")]
mod m;
```
See the changes to the reference for details on what macros are allowed;
see Petrochenkov's excellent blog post [on internals](https://internals.rust-lang.org/t/macro-expansion-points-in-attributes/11455)
for alternatives that were considered and rejected ("why accept no more
and no less?")
This has been available on nightly since 1.50 with no major issues.
## Notes
### Accepted syntax
The parser accepts arbitrary Rust expressions in this position, but any expression other than a macro invocation will ultimately lead to an error because it is not expected by the built-in expression forms (e.g., `#[doc]`). Note that decorators and the like may be able to observe other expression forms.
### Expansion ordering
Expansion of macro expressions in "inert" attributes occurs after decorators have executed, analogously to macro expressions appearing in the function body or other parts of decorator input.
There is currently no way for decorators to accept macros in key-value position if macro expansion must be performed before the decorator executes (if the macro can simply be copied into the output for later expansion, that can work).
## Test cases
- https://github.com/rust-lang/rust/blob/master/src/test/ui/attributes/key-value-expansion-on-mac.rs
- https://github.com/rust-lang/rust/blob/master/src/test/rustdoc/external-doc.rs
The feature has also been dogfooded extensively in the compiler and
standard library:
- https://github.com/rust-lang/rust/pull/83329
- https://github.com/rust-lang/rust/pull/83230
- https://github.com/rust-lang/rust/pull/82641
- https://github.com/rust-lang/rust/pull/80534
## Implementation history
- Initial proposal: https://github.com/rust-lang/rust/issues/55414#issuecomment-554005412
- Experiment to see how much code it would break: https://github.com/rust-lang/rust/pull/67121
- Preliminary work to restrict expansion that would conflict with this
feature: https://github.com/rust-lang/rust/pull/77271
- Initial implementation: https://github.com/rust-lang/rust/pull/78837
- Fix for an ICE: https://github.com/rust-lang/rust/pull/80563
## Unresolved Questions
~~https://github.com/rust-lang/rust/pull/83366#issuecomment-805180738 listed some concerns, but they have been resolved as of this final report.~~
## Additional Information
There are two workarounds that have a similar effect for `#[doc]`
attributes on nightly. One is to emulate this behavior by using a limited version of this feature that was stabilized for historical reasons:
```rust
macro_rules! forward_inner_docs {
($e:expr => $i:item) => {
#[doc = $e]
$i
};
}
forward_inner_docs!(include_str!("lib.rs") => struct S {});
```
This also works for other attributes (like `#[path = concat!(...)]`).
The other is to use `doc(include)`:
```rust
#![feature(external_doc)]
#[doc(include = "lib.rs")]
struct S {}
```
The first works, but is non-trivial for people to discover, and
difficult to read and maintain. The second is a strange special-case for
a particular use of the macro. This generalizes it to work for any use
case, not just including files.
I plan to remove `doc(include)` when this is stabilized. The
`forward_inner_docs` workaround will still compile without warnings, but
I expect it to be used less once it's no longer necessary.
This adds a new lint to `rustc` that is used in rustdoc when a code
block is empty or cannot be parsed as valid Rust code.
Previously this was unconditionally a warning. As such some
documentation comments were (unknowingly) abusing this to pass despite
the `-Dwarnings` used when compiling `rustc`, this should not be the
case anymore.
In https://reviews.llvm.org/D102093 lots of things stopped taking the
DebugLogging boolean parameter. Mercifully we appear to always set
DebugPassManager to false, so I don't think we're losing anything by not
passing this parameter.
Parse unnamed fields of struct and union type
Added the `unnamed_fields` feature gate.
This is a prototype of [RFC 2102](https://github.com/rust-lang/rust/issues/49804), so any suggestions are greatly appreciated.
r? `@petrochenkov`
Remove CrateNum parameter for queries that only work on local crate
The pervasive `CrateNum` parameter is a remnant of the multi-crate rustc idea.
Using `()` as query key in those cases avoids having to worry about the validity of the query key.
rustc_codegen_ssa: only create backend `BasicBlock`s as-needed.
Instead of creating one backend (e.g. LLVM) block per MIR block ahead of time, and then deleting the ones that weren't visited, this PR moves to creating the blocks as they're needed (either reached via the RPO visit, or used as the target of a branch from a different block).
As deleting a block was the only `unsafe` builder method (generally we only *create* backend objects, not *remove* them), that's gone now and codegen is overall a bit safer.
The only change in output is the order of LLVM blocks (which AFAIK has no semantic meaning, other than the first block being the entry block). This happens because the blocks are now created due to control-flow edges, rather than MIR block order.
I'm making this a standalone PR because I keep getting wild perf results when I change *anything* in codegen, but if you want to read more about my plans in this area, see https://github.com/rust-lang/rust/pull/84771#issuecomment-830636256 (and https://github.com/rust-lang/rust/pull/84771#issue-628295651 - but that may be a bit outdated).
(You may notice some of the APIs in this PR, like `append_block`, don't help with the future plans - but I didn't want to include the necessary refactors that pass a build around everywhere, in this PR, so it's a small compromise)
r? `@nagisa` `@bjorn3`
Fix unused attributes on macro_rules.
The `unused_attributes` lint wasn't firing on attributes of `macro_rules` definitions. The consequence is that many attributes are silently ignored on `macro_rules`. The reason is that `unused_attributes` is a late-lint pass, and only has access to the HIR, which does not have macro_rules definitions.
My solution here is to change `non_exported_macro_attrs` to be `macro_attrs` (a list of all attributes used for `macro_rules`, instead of just those for `macro_export`), and then to check this list in the `unused_attributes` lint. There are a number of alternate approaches, but this seemed the most reliable and least invasive. I am open to completely different approaches, though.
One concern is that I don't fully understand the implications of extending `non_exported_macro_attrs` to include non-exported macros. That list was originally added in #62042 to handle stability attributes, so I suspect it was just an optimization since that was all that was needed. It was later extended to be included in SVH in #83901. #80641 also added a use to check for `invalid` attributes, which seems a little odd to me (it didn't validate non-exported macros, and seems highly specific).
Overall, there doesn't seem to be a clear story of when `unused_attributes` should be used versus an error like E0518. I considered alternatively using an "allow list" of built-in attributes that can be used on macro_rules (allow, warn, deny, forbid, cfg, cfg_attr, macro_export, deprecated, doc), but I feel like that could be a pain to maintain.
Some built-in attributes already present hard-errors when used with macro_rules. These are each hard-coded in various places:
- `derive`
- `test` and `bench`
- `proc_macro` and `proc_macro_derive`
- `inline`
- `global_allocator`
The primary motivation is that I sometimes see people use `#[macro_use]` in front of `macro_rules`, which indicates there is some confusion out there (evident that there was even a case of it in rustc).
Remove support for floating-point constants in asm!
Floating-point constants aren't very useful anyways and this simplifies
the code since the type check can now be done in typeck.
cc `@rust-lang/wg-inline-asm`
r? `@nagisa`
Reachable statics have reachable initializers
Static initializer can read other statics. Initializers are evaluated at
compile time, and so their content could become inlined into another
crate. Ensure that initializers of reachable statics are also reachable.
Previously, when an item incorrectly considered to be unreachable was
reached from another crate an attempt would be made to codegen it. The
attempt could fail with an ICE (in the case MIR wasn't available to do
so) in some circumstances the attempt could also succeed resulting in
a local codegen of non-local items, including static ones.
Fixes#84455.
rustc_codegen_ssa: generate MSVC cleanup pads on demand, like GNU landing pads.
This unblocks #84993 in terms of codegen tests, as it brings the MSVC-style (`cleanup_pad`) EH (LLVM) block order in line with the GNU-style (`landing_pad`) EH (LLVM) block order, by having both of them be on-demand (instead of MSVC-style being eager and GNU-style lazy/on-demand).
It also unifies the two implementations a bit, similar to #84699, but in the opposite direction (as that attempt made both kinds of EH pads eagerly built).
~~Opening as draft because I haven't done enough Windows testing just yet, of both this PR, and of #84993 rebased on it.~~ (**EDIT**: seems to be working as expected)
r? `@nagisa`
CTFE validation: handle pointers in str
I also finally learned how I can match *some* NOTEs in a ui test without matching all of them, and applied that to some const tests in the 2nd commit where I added NOTE because I did not know what I was doing. I can separate this into its own PR if you prefer.
Fixes https://github.com/rust-lang/rust/issues/83182
r? `@oli-obk`
Check for inline assembly in THIR unsafeck
#83129 was merged recently and added a THIR unsafe checker. This adds a check for inline assembly. (and this is 2x simpler than the MIR version, which has to check for `asm` and `llvm_asm` in two separate spots!)
see also rust-lang/project-thir-unsafeck#7
Remove some unncessary spaces from pretty-printed tokenstream output
In addition to making the output look nicer for all crates, this also
aligns the pretty-printing output with what the `rental` crate expects.
This will allow us to eventually disable a backwards-compat hack in a
follow-up PR.
See https://github.com/rust-lang/rust/issues/84428 for some background information about why we want to make this change. Note that this change would be desirable (but not particularly necessary) even if `rental` didn't exist, so we're not adding any crate-specific hacks into the compiler.
In addition to making the output look nicer for all crates, this also
aligns the pretty-printing output with what the `rental` crate expects.
This will allow us to eventually disable a backwards-compat hack in a
follow-up PR.
Warn about unused `pub` fields in non-`pub` structs
This pull request fixes#85255. The current implementation of dead code analysis is too prudent because it marks all `pub` fields of structs as live, even though they cannot be accessed from outside of the current crate if the struct itself only has restricted or private visibility.
I have changed this behavior to take the containing struct's visibility into account when looking at field visibility and liveness. This also makes dead code warnings more consistent; consider the example given in #85255:
```rust
struct Foo {
a: i32,
pub b: i32,
}
struct Bar;
impl Bar {
fn a(&self) -> i32 { 5 }
pub fn b(&self) -> i32 { 6 }
}
fn main() {
let _ = Foo { a: 1, b: 2 };
let _ = Bar;
}
```
Current nightly already warns about `Bar::b()`, even though it is `pub` (but `Bar` is not). It should therefore also warn about `Foo::b`, which it does with the changes in this PR.
swap function order for better read flow
I was reading this error message for the first time.
I was a little bit confused when reading that part:
```
foo.bar(); // we can now use this method since i32 implements the Foo trait
```
At the time I was reading `// we can now use this method` I wasn't sure why. It only made sense when reading on. So swapping these parts results in a better read flow.
coverage bug fixes and some refactoring
This replaces the relevant commits (2 and 3) from PR #85082, and also corrects an error querying for coverageinfo.
1. `coverageinfo` query needs to use the same MIR as codegen
I ran into an error trying to fix dead block coverage and realized the
`coverageinfo` query is getting a different MIR compared to the
codegenned MIR, which can sometimes be a problem during mapgen.
I changed that query to use the `InstandeDef` (which includes the
generic parameter substitutions, prosibly specific to const params)
instead of the `DefId` (without unknown/default const substitutions).
2. Simplified body_span and filtered span code
Some code cleanup extracted from future (but unfinished) commit to fix
coverage in attr macro functions.
3. Spanview needs the relevant body_span used for coverage
The coverage body_span doesn't always match the function body_span.
r? ```@tmandry```
Preserve `SyntaxContext` for invalid/dummy spans in crate metadata
Fixes#85197
We already preserved the `SyntaxContext` for invalid/dummy spans in the
incremental cache, but we weren't doing the same for crate metadata.
If an invalid (lo/hi from different files) span is written to the
incremental cache, we will decode it with a 'dummy' location, but keep
the original `SyntaxContext`. Since the crate metadata encoder was only
checking for `DUMMY_SP` (dummy location + root `SyntaxContext`),
the metadata encoder would treat it as a normal span, encoding the
`SyntaxContext`. As a result, the final span encoded to the metadata
would change across sessions, even if the crate itself was unchanged.
This could lead to an 'unstable fingerprint' ICE under the following conditions:
1. We compile a crate with an invalid span using incremental compilation. The metadata encoder discards the `SyntaxContext` since the span is invalid, while the incremental cache encoder preserves the `SyntaxContext`
2. From another crate, we execute a foreign query, decoding the invalid span from the metadata as `DUMMY_SP` (e.g. with `SyntaxContext::root()`). This span gets hashed into the query fingerprint. So far, this has always happened through the `optimized_mir` query.
3. We recompile the first crate using our populated incremental cache, without changing anything. We load the (previously) invalid span from our incremental cache - it gets converted to a span with a dummy (but valid) location, along with the original `SyntaxContext`. This span gets written out to the crate metadata - since it now has a valid location, we preserve its `SyntaxContext`.
4. We recompile the second crate, again using a populated incremental cache. We now re-run the foreign query `optimized_mir` - the foreign crate hash is unchanged, but we end up decoding a different span (it now ha a non-root `SyntaxContext`). This results in the fingerprint changing, resulting in an ICE.
This PR updates our encoding of spans in the crate metadata to mirror
the encoding of spans into the incremental cache. We now always encode a
`SyntaxContext`, and encode location information for spans with a
non-dummy location.
Use the object crate for metadata reading
This allows sharing the metadata reader between cg_llvm, cg_clif and other codegen backends.
This is not currently useful for rlib reading with cg_spirv ([rust-gpu](https://github.com/EmbarkStudios/rust-gpu/)) as it uses tar rather than ar as .rlib format, but it is useful for dylib reading required for loading proc macros. (cc `@eddyb)`
The object crate is already trusted as dependency of libstd through backtrace. As far as I know it supports reading all object file formats used by targets for which we support rust dylibs with crate metadata, but I am not certain. If this happens to not be the case, I could keep using LLVM for reading dylib metadata.
Marked as WIP for a perf run and as it is based on #83637.
Improve error message for non-exhaustive matches on non-exhaustive enums
This pull request fixes#85227. For an enum marked with `#[non_exhaustive]` and not defined in the current crate, the error message for non-exhaustive matches now mentions the fact that the enum is marked as non-exhaustive:
```
error[E0004]: non-exhaustive patterns: `_` not covered
--> main.rs:12:11
|
12 | match e {
| ^ pattern `_` not covered
|
= help: ensure that all possible cases are being handled, possibly by adding wildcards or more match arms
= note: the matched value is of type `E`, which is marked as non-exhaustive
```
Store VariantIdx to distinguish enum variants
This saves ~24% of the instructions on the match-stress-enum benchmark, but I'm not 100% sure that this is OK - if we ever compare two constructors across enums (e.g., a Result and an Option), then this is obviously insufficient; I can experiment with continuing to store the DefId for comparison purposes in that case.
LinkerFlavor::Gcc does not always mean GNU ld specifically. And in the
case of at least the solaris ld in illumos, that flag is unrecognized
and will cause the linking step to fail.
Add support for const operands and options to global_asm!
On x86, the default syntax is also switched to Intel to match asm!.
Currently `global_asm!` only supports `const` operands and the `att_syntax` option. In the future, `sym` operands will also be supported. However there is no plan to support any of the other operand types or options since they don't make sense in the context of `global_asm!`.
r? `@nagisa`
have on_completion record subcycles
have on_completion record subcycles
Rework `on_completion` method so that it removes all
provisional cache entries that are "below" a completed
node (while leaving those entries that are not below
the node).
This corrects an imprecise result that could in turn lead
to an incremental compilation failure. Under the old
scheme, if you had:
* A depends on...
* B depends on A
* C depends on...
* D depends on C
* T: 'static
then the provisional results for A, B, C, and D would all
be entangled. Thus, if A was `EvaluatedToOkModuloRegions`
(because of that final condition), then the result for C and
D would also be demoted to "ok modulo regions".
In reality, though, the result for C depends only on C and itself,
and is not dependent on regions. If we happen to evaluate the
cycle starting from C, we would never reach A, and hence the
result would be "ok".
Under the new scheme, the provisional results for C and D
are moved to the permanent cache immediately and are not affected
by the result of A.
Fixes#83538
r? `@Aaron1011`
Fix diagnostic for cross crate private tuple struct constructors
Fixes#78708.
There was already some limited support for certain cross-crate scenarios but that didn't handle a tuple struct rexported from an inner module for example (e.g. the NonZero* types as seen in #85049).
```Rust
➜ cat bug.rs
fn main() {
let _x = std::num::NonZeroU32(12);
let n = std::num::NonZeroU32::new(1).unwrap();
match n {
std::num::NonZeroU32(i) => {},
}
}
```
**Before:**
<details>
```Rust
➜ rustc +nightly bug.rs
error[E0423]: expected function, tuple struct or tuple variant, found struct `std::num::NonZeroU32`
--> bug.rs:2:14
|
2 | let _x = std::num::NonZeroU32(12);
| ^^^^^^^^^^^^^^^^^^^^^^^^ help: use struct literal syntax instead: `std::num::NonZeroU32 { 0: val }`
|
::: /home/luqman/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/num/nonzero.rs:148:1
[snip]
error[E0532]: expected tuple struct or tuple variant, found struct `std::num::NonZeroU32`
--> bug.rs:5:9
|
5 | std::num::NonZeroU32(i) => {},
| ^^^^^^^^^^^^^^^^^^^^^^^ help: use struct pattern syntax instead: `std::num::NonZeroU32 { 0 }`
|
::: /home/luqman/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/num/nonzero.rs:148:1
[snip]
error: aborting due to 2 previous errors
Some errors have detailed explanations: E0423, E0532.
For more information about an error, try `rustc --explain E0423`.
```
</details>
**After:**
<details>
```Rust
➜ /rust/build/x86_64-unknown-linux-gnu/stage1/bin/rustc bug.rs
error[E0423]: cannot initialize a tuple struct which contains private fields
--> bug.rs:2:14
|
2 | let _x = std::num::NonZeroU32(12);
| ^^^^^^^^^^^^^^^^^^^^
|
note: constructor is not visible here due to private fields
--> /rust/library/core/src/num/nonzero.rs:148:1
[snip]
error[E0532]: cannot match against a tuple struct which contains private fields
--> bug.rs:5:9
|
5 | std::num::NonZeroU32(i) => {},
| ^^^^^^^^^^^^^^^^^^^^
|
note: constructor is not visible here due to private fields
--> bug.rs:5:30
|
5 | std::num::NonZeroU32(i) => {},
| ^ private field
error: aborting due to 2 previous errors
Some errors have detailed explanations: E0423, E0532.
For more information about an error, try `rustc --explain E0423`.
```
</details>
One question is if we should only collect the needed info for the cross-crate case after encountering an error instead of always doing it. Perf run perhaps to gauge the impact.
Remove rustc_args_required_const attribute
Now that stdarch no longer needs it (thanks `@Amanieu!),` we can kill the `rustc_args_required_const` attribute. This means that lifetime extension of references to temporaries is the only remaining job that promotion is performing. :-)
r? `@oli-obk`
Fixes https://github.com/rust-lang/rust/issues/69493
When having the order
```
foo.bar(); // we can now use this method since i32 implements the Foo trait
[...]
impl Foo for i32
```
the `// we can now use this method` comment is less clear to me.
Introduce the beginning of a THIR unsafety checker
This poses the foundations for the THIR unsafety checker, so that it can be implemented incrementally:
- implements a rudimentary `Visitor` for the THIR (which will definitely need some tweaking in the future)
- introduces a new `-Zthir-unsafeck` flag which tells the compiler to use THIR unsafeck instead of MIR unsafeck
- implements detection of unsafe functions
- adds revisions to the UI tests to test THIR unsafeck alongside MIR unsafeck
This uses a very simple query design, where bodies are unsafety-checked on a body per body basis. This however has some big flaws:
- the unsafety-checker builds the THIR itself, which means a lot of work is duplicated with MIR building constructing its own copy of the THIR
- unsafety-checking closures is currently completely wrong: closures should take into account the "safety context" in which they are created, here we are considering that closures are always a safe context
I had intended to fix these problems in follow-up PRs since they are always gated under the `-Zthir-unsafeck` flag (which is explicitely noted to be unsound).
r? `@nikomatsakis`
cc https://github.com/rust-lang/project-thir-unsafeck/issues/3https://github.com/rust-lang/project-thir-unsafeck/issues/7
Rework `on_completion` method so that it removes all
provisional cache entries that are "below" a completed
node (while leaving those entries that are not below
the node).
This corrects an imprecise result that could in turn lead
to an incremental compilation failure. Under the old
scheme, if you had:
* A depends on...
* B depends on A
* C depends on...
* D depends on C
* T: 'static
then the provisional results for A, B, C, and D would all
be entangled. Thus, if A was `EvaluatedToOkModuloRegions`
(because of that final condition), then the result for C and
D would also be demoted to "ok modulo regions".
In reality, though, the result for C depends only on C and itself,
and is not dependent on regions. If we happen to evaluate the
cycle starting from C, we would never reach A, and hence the
result would be "ok".
Under the new scheme, the provisional results for C and D
are moved to the permanent cache immediately and are not affected
by the result of A.
This attribute will cause us to invoke evaluate on every where clause of an
invoked function and to generate an error with the result.
Without this, it is very difficult to observe the effects of invoking the trait
evaluator.
Suggest adding a type parameter for impls
Add a new suggestion upon encountering an unknown type in a `impl` that suggests adding a new type parameter. This diagnostic suggests to add a new type parameter even though it may be a const parameter, however after adding the parameter and running rustc again a follow up error steers the user to change the type parameter to a const parameter.
```rust
struct X<const C: ()>();
impl X<C> {}
```
suggests
```
error[E0412]: cannot find type `C` in this scope
--> bar.rs:2:8
|
1 | struct X<const C: ()>();
| ------------------------ similarly named struct `X` defined here
2 | impl X<C> {}
| ^
|
help: a struct with a similar name exists
|
2 | impl X<X> {}
| ^
help: you might be missing a type parameter
|
2 | impl<C> X<C> {}
| ^^^
```
After adding a type parameter the code now becomes
```rust
struct X<const C: ()>();
impl<C> X<C> {}
```
and the error now fully steers the user towards the correct code
```
error[E0747]: type provided when a constant was expected
--> bar.rs:2:11
|
2 | impl<C> X<C> {}
| ^
|
help: consider changing this type parameter to be a `const` generic
|
2 | impl<const C: ()> X<C> {}
| ^^^^^^^^^^^
```
r? `@estebank`
Somewhat related #84946
Add asm!() support for PowerPC
This includes GPRs and FPRs only.
Note that this does not include PowerPC64.
For my reference, this was mostly duplicated from PR #73214.
I ran into an error trying to fix dead block coverage and realized the
`coverageinfo` query is getting a different MIR compared to the
codegenned MIR, which can sometimes be a problem during mapgen.
I changed that query to use the `InstandeDef` (which includes the
generic parameter substitutions, prosibly specific to const params)
instead of the `DefId` (without unknown/default const substitutions).
Handle more span edge cases in generics diagnostics
This should fix invalid suggestions that didn't account for empty bracket pairs (`<>`) or type bindings.
Fixes#85197
We already preserved the `SyntaxContext` for invalid/dummy spans in the
incremental cache, but we weren't doing the same for crate metadata.
If an invalid (lo/hi from different files) span is written to the
incremental cache, we will decode it with a 'dummy' location, but keep
the original `SyntaxContext`. Since the crate metadata encoder was only
checking for `DUMMY_SP` (dummy location + root `SyntaxContext`),
the metadata encoder would treat it as a normal span, encoding the
`SyntaxContext`. As a result, the final span encoded to the metadata
would change across sessions, even if the crate itself was unchanged.
This PR updates our encoding of spans in the crate metadata to mirror
the encoding of spans into the incremental cache. We now always encode a
`SyntaxContext`, and encode location information for spans with a
non-dummy location.
Recover from invalid `struct` item syntax
Parse unsupported "default field const values":
```rust
struct S {
field: Type = const_val,
}
```
Recover from small `:` typo and provide suggestion:
```rust
struct S {
field; Type,
field2= Type,
}
```
Add auto traits and clone trait migrations for RFC2229
This PR
- renames the existent RFC2229 migration `disjoint_capture_drop_reorder` to `disjoint_capture_migration`
- add additional migrations for auto traits and clone trait
Closesrust-lang/project-rfc-2229#29Closesrust-lang/project-rfc-2229#28
r? `@nikomatsakis`
Fix `--remap-path-prefix` not correctly remapping `rust-src` component paths and unify handling of path mapping with virtualized paths
This PR fixes#73167 ("Binaries end up containing path to the rust-src component despite `--remap-path-prefix`") by preventing real local filesystem paths from reaching compilation output if the path is supposed to be remapped.
`RealFileName::Named` introduced in #72767 is now renamed as `LocalPath`, because this variant wraps a (most likely) valid local filesystem path.
`RealFileName::Devirtualized` is renamed as `Remapped` to be used for remapped path from a real path via `--remap-path-prefix` argument, as well as real path inferred from a virtualized (during compiler bootstrapping) `/rustc/...` path. The `local_path` field is now an `Option<PathBuf>`, as it will be set to `None` before serialisation, so it never reaches any build output. Attempting to serialise a non-`None` `local_path` will cause an assertion faliure.
When a path is remapped, a `RealFileName::Remapped` variant is created. The original path is preserved in `local_path` field and the remapped path is saved in `virtual_name` field. Previously, the `local_path` is directly modified which goes against its purpose of "suitable for reading from the file system on the local host".
`rustc_span::SourceFile`'s fields `unmapped_path` (introduced by #44940) and `name_was_remapped` (introduced by #41508 when `--remap-path-prefix` feature originally added) are removed, as these two pieces of information can be inferred from the `name` field: if it's anything other than a `FileName::Real(_)`, or if it is a `FileName::Real(RealFileName::LocalPath(_))`, then clearly `name_was_remapped` would've been false and `unmapped_path` would've been `None`. If it is a `FileName::Real(RealFileName::Remapped{local_path, virtual_name})`, then `name_was_remapped` would've been true and `unmapped_path` would've been `Some(local_path)`.
cc `@eddyb` who implemented `/rustc/...` path devirtualisation
This PR implements span quoting, allowing proc-macros to produce spans
pointing *into their own crate*. This is used by the unstable
`proc_macro::quote!` macro, allowing us to get error messages like this:
```
error[E0412]: cannot find type `MissingType` in this scope
--> $DIR/auxiliary/span-from-proc-macro.rs:37:20
|
LL | pub fn error_from_attribute(_args: TokenStream, _input: TokenStream) -> TokenStream {
| ----------------------------------------------------------------------------------- in this expansion of procedural macro `#[error_from_attribute]`
...
LL | field: MissingType
| ^^^^^^^^^^^ not found in this scope
|
::: $DIR/span-from-proc-macro.rs:8:1
|
LL | #[error_from_attribute]
| ----------------------- in this macro invocation
```
Here, `MissingType` occurs inside the implementation of the proc-macro
`#[error_from_attribute]`. Previosuly, this would always result in a
span pointing at `#[error_from_attribute]`
This will make many proc-macro-related error message much more useful -
when a proc-macro generates code containing an error, users will get an
error message pointing directly at that code (within the macro
definition), instead of always getting a span pointing at the macro
invocation site.
This is implemented as follows:
* When a proc-macro crate is being *compiled*, it causes the `quote!`
macro to get run. This saves all of the sapns in the input to `quote!`
into the metadata of *the proc-macro-crate* (which we are currently
compiling). The `quote!` macro then expands to a call to
`proc_macro::Span::recover_proc_macro_span(id)`, where `id` is an
opaque identifier for the span in the crate metadata.
* When the same proc-macro crate is *run* (e.g. it is loaded from disk
and invoked by some consumer crate), the call to
`proc_macro::Span::recover_proc_macro_span` causes us to load the span
from the proc-macro crate's metadata. The proc-macro then produces a
`TokenStream` containing a `Span` pointing into the proc-macro crate
itself.
The recursive nature of 'quote!' can be difficult to understand at
first. The file `src/test/ui/proc-macro/quote-debug.stdout` shows
the output of the `quote!` macro, which should make this eaier to
understand.
This PR also supports custom quoting spans in custom quote macros (e.g.
the `quote` crate). All span quoting goes through the
`proc_macro::quote_span` method, which can be called by a custom quote
macro to perform span quoting. An example of this usage is provided in
`src/test/ui/proc-macro/auxiliary/custom-quote.rs`
Custom quoting currently has a few limitations:
In order to quote a span, we need to generate a call to
`proc_macro::Span::recover_proc_macro_span`. However, proc-macros
support renaming the `proc_macro` crate, so we can't simply hardcode
this path. Previously, the `quote_span` method used the path
`crate::Span` - however, this only works when it is called by the
builtin `quote!` macro in the same crate. To support being called from
arbitrary crates, we need access to the name of the `proc_macro` crate
to generate a path. This PR adds an additional argument to `quote_span`
to specify the name of the `proc_macro` crate. Howver, this feels kind
of hacky, and we may want to change this before stabilizing anything
quote-related.
Additionally, using `quote_span` currently requires enabling the
`proc_macro_internals` feature. The builtin `quote!` macro
has an `#[allow_internal_unstable]` attribute, but this won't work for
custom quote implementations. This will likely require some additional
tricks to apply `allow_internal_unstable` to the span of
`proc_macro::Span::recover_proc_macro_span`.
Parse unsupported "default field const values":
```rust
struct S {
field: Type = const_val,
}
```
Recover from small `:` typo and provide suggestion:
```rust
struct S {
field; Type,
field2= Type,
}
```
Use .name_str() to format primitive types in error messages
This pull request fixes#84976. The problem described there is caused by this code
506e75cbf8/compiler/rustc_middle/src/ty/error.rs (L161-L166)
using `Debug` formatting (`{:?}`), while the proper solution is to call `name_str()` of `ty::IntTy`, `ty::UintTy` and `ty::FloatTy`, respectively.
Emit errors/warns on some wrong uses of rustdoc attributes
This PR adds a few diagnostics:
- error if conflicting `#[doc(inline)]`/`#[doc(no_inline)]` are found
- introduce the `invalid_doc_attributes` lint (warn-by-default) which triggers:
- if a crate-level attribute is used on a non-`crate` item
- if `#[doc(inline)]`/`#[doc(no_inline)]` is used on a non-`use` item
The code could probably be improved but I wanted to get feedback first. Also, some of those changes could be considered breaking changes, so I don't know what the procedure would be? ~~And finally, for the warnings, they are currently hard warnings, maybe it would be better to introduce a lint?~~ (EDIT: introduced the `invalid_doc_attributes` lint)
Closes#80275.
r? `@jyn514`
Show nicer error when an 'unstable fingerprints' error occurs
An example of the error produced by this PR:
```
error: internal compiler error: encountered incremental compilation error with evaluate_obligation(9f2ad55260c30262-c36667639674ad83)
|
= help: This is a known issue with the compiler. Run `cargo clean -p syn` or `cargo clean` to allow your project to compile
= note: Please follow the instructions below to create a bug report with the provided information
thread 'rustc' panicked at 'Found unstable fingerprints for evaluate_obligation(9f2ad55260c30262-c36667639674ad83): Ok(EvaluatedToOk)', /home/aaron/repos/rust/compiler/rustc_query_system/src/query/plumbing.rs:595:9
stack backtrace:
0: rust_begin_unwind
at /home/aaron/repos/rust/library/std/src/panicking.rs:493:5
1: std::panicking::begin_panic_fmt
at /home/aaron/repos/rust/library/std/src/panicking.rs:435:5
2: rustc_query_system::query::plumbing::incremental_verify_ich
at /home/aaron/repos/rust/compiler/rustc_query_system/src/query/plumbing.rs:595:9
3: rustc_query_system::query::plumbing::load_from_disk_and_cache_in_memory
at /home/aaron/repos/rust/compiler/rustc_query_system/src/query/plumbing.rs:557:9
4: rustc_query_system::query::plumbing::try_execute_query::{{closure}}::{{closure}}
at /home/aaron/repos/rust/compiler/rustc_query_system/src/query/plumbing.rs:473:21
5: core::option::Option<T>::map
at /home/aaron/repos/rust/library/core/src/option.rs:487:29
6: rustc_query_system::query::plumbing::try_execute_query::{{closure}}
at /home/aaron/repos/rust/compiler/rustc_query_system/src/query/plumbing.rs:471:13
7: stacker::maybe_grow
at /home/aaron/.cargo/registry/src/github.com-1ecc6299db9ec823/stacker-0.1.12/src/lib.rs:55:9
8: rustc_data_structures::stack::ensure_sufficient_stack
at /home/aaron/repos/rust/compiler/rustc_data_structures/src/stack.rs:16:5
9: <rustc_query_impl::plumbing::QueryCtxt as rustc_query_system::query::QueryContext>::start_query::{{closure}}::{{closure}}
at /home/aaron/repos/rust/compiler/rustc_query_impl/src/plumbing.rs:169:17
10: rustc_middle::ty::context::tls::enter_context::{{closure}}
at /home/aaron/repos/rust/compiler/rustc_middle/src/ty/context.rs:1736:50
11: rustc_middle::ty::context::tls::set_tlv
at /home/aaron/repos/rust/compiler/rustc_middle/src/ty/context.rs:1720:9
12: rustc_middle::ty::context::tls::enter_context
at /home/aaron/repos/rust/compiler/rustc_middle/src/ty/context.rs:1736:9
13: <rustc_query_impl::plumbing::QueryCtxt as rustc_query_system::query::QueryContext>::start_query::{{closure}}
at /home/aaron/repos/rust/compiler/rustc_query_impl/src/plumbing.rs:168:13
14: rustc_middle::ty::context::tls::with_related_context::{{closure}}
at /home/aaron/repos/rust/compiler/rustc_middle/src/ty/context.rs:1780:13
15: rustc_middle::ty::context::tls::with_context::{{closure}}
at /home/aaron/repos/rust/compiler/rustc_middle/src/ty/context.rs:1764:40
16: rustc_middle::ty::context::tls::with_context_opt
at /home/aaron/repos/rust/compiler/rustc_middle/src/ty/context.rs:1753:22
17: rustc_middle::ty::context::tls::with_context
at /home/aaron/repos/rust/compiler/rustc_middle/src/ty/context.rs:1764:9
18: rustc_middle::ty::context::tls::with_related_context
at /home/aaron/repos/rust/compiler/rustc_middle/src/ty/context.rs:1777:9
19: <rustc_query_impl::plumbing::QueryCtxt as rustc_query_system::query::QueryContext>::start_query
at /home/aaron/repos/rust/compiler/rustc_query_impl/src/plumbing.rs:157:9
20: rustc_query_system::query::plumbing::try_execute_query
at /home/aaron/repos/rust/compiler/rustc_query_system/src/query/plumbing.rs:469:22
21: rustc_query_system::query::plumbing::get_query_impl
at /home/aaron/repos/rust/compiler/rustc_query_system/src/query/plumbing.rs:674:5
22: rustc_query_system::query::plumbing::get_query
at /home/aaron/repos/rust/compiler/rustc_query_system/src/query/plumbing.rs:785:9
23: <rustc_query_impl::Queries as rustc_middle::ty::query::QueryEngine>::evaluate_obligation
at /home/aaron/repos/rust/compiler/rustc_query_impl/src/plumbing.rs:603:17
24: rustc_middle::ty::query::TyCtxtAt::evaluate_obligation
at /home/aaron/repos/rust/compiler/rustc_middle/src/ty/query/mod.rs:204:17
25: rustc_middle::ty::query::<impl rustc_middle::ty::context::TyCtxt>::evaluate_obligation
at /home/aaron/repos/rust/compiler/rustc_middle/src/ty/query/mod.rs:185:17
26: <rustc_infer::infer::InferCtxt as rustc_trait_selection::traits::query::evaluate_obligation::InferCtxtExt>::evaluate_obligation
at /home/aaron/repos/rust/compiler/rustc_trait_selection/src/traits/query/evaluate_obligation.rs:72:9
27: <rustc_infer::infer::InferCtxt as rustc_trait_selection::traits::query::evaluate_obligation::InferCtxtExt>::evaluate_obligation_no_overflow
at /home/aaron/repos/rust/compiler/rustc_trait_selection/src/traits/query/evaluate_obligation.rs:82:15
28: <rustc_infer::infer::InferCtxt as rustc_trait_selection::traits::query::evaluate_obligation::InferCtxtExt>::predicate_must_hold_modulo_regions
at /home/aaron/repos/rust/compiler/rustc_trait_selection/src/traits/query/evaluate_obligation.rs:58:9
29: rustc_trait_selection::traits::type_known_to_meet_bound_modulo_regions
at /home/aaron/repos/rust/compiler/rustc_trait_selection/src/traits/mod.rs:146:18
30: rustc_ty_utils::common_traits::is_item_raw::{{closure}}
at /home/aaron/repos/rust/compiler/rustc_ty_utils/src/common_traits.rs:33:9
31: rustc_infer::infer::InferCtxtBuilder::enter
at /home/aaron/repos/rust/compiler/rustc_infer/src/infer/mod.rs:582:9
32: rustc_ty_utils::common_traits::is_item_raw
at /home/aaron/repos/rust/compiler/rustc_ty_utils/src/common_traits.rs:32:5
33: rustc_query_system::query::config::QueryVtable<CTX,K,V>::compute
at /home/aaron/repos/rust/compiler/rustc_query_system/src/query/config.rs:44:9
34: rustc_query_system::query::plumbing::load_from_disk_and_cache_in_memory::{{closure}}
at /home/aaron/repos/rust/compiler/rustc_query_system/src/query/plumbing.rs:544:67
35: rustc_middle::dep_graph::<impl rustc_query_system::dep_graph::DepKind for rustc_middle::dep_graph::dep_node::DepKind>::with_deps::{{closure}}::{{closure}}
at /home/aaron/repos/rust/compiler/rustc_middle/src/dep_graph/mod.rs:77:46
36: rustc_middle::ty::context::tls::enter_context::{{closure}}
at /home/aaron/repos/rust/compiler/rustc_middle/src/ty/context.rs:1736:50
37: rustc_middle::ty::context::tls::set_tlv
at /home/aaron/repos/rust/compiler/rustc_middle/src/ty/context.rs:1720:9
38: rustc_middle::ty::context::tls::enter_context
at /home/aaron/repos/rust/compiler/rustc_middle/src/ty/context.rs:1736:9
39: rustc_middle::dep_graph::<impl rustc_query_system::dep_graph::DepKind for rustc_middle::dep_graph::dep_node::DepKind>::with_deps::{{closure}}
at /home/aaron/repos/rust/compiler/rustc_middle/src/dep_graph/mod.rs:77:13
40: rustc_middle::ty::context::tls::with_context::{{closure}}
at /home/aaron/repos/rust/compiler/rustc_middle/src/ty/context.rs:1764:40
41: rustc_middle::ty::context::tls::with_context_opt
at /home/aaron/repos/rust/compiler/rustc_middle/src/ty/context.rs:1753:22
42: rustc_middle::ty::context::tls::with_context
at /home/aaron/repos/rust/compiler/rustc_middle/src/ty/context.rs:1764:9
43: rustc_middle::dep_graph::<impl rustc_query_system::dep_graph::DepKind for rustc_middle::dep_graph::dep_node::DepKind>::with_deps
at /home/aaron/repos/rust/compiler/rustc_middle/src/dep_graph/mod.rs:74:9
44: rustc_query_system::dep_graph::graph::DepGraph<K>::with_ignore
at /home/aaron/repos/rust/compiler/rustc_query_system/src/dep_graph/graph.rs:167:9
45: rustc_query_system::query::plumbing::load_from_disk_and_cache_in_memory
at /home/aaron/repos/rust/compiler/rustc_query_system/src/query/plumbing.rs:544:22
46: rustc_query_system::query::plumbing::try_execute_query::{{closure}}::{{closure}}
at /home/aaron/repos/rust/compiler/rustc_query_system/src/query/plumbing.rs:473:21
47: core::option::Option<T>::map
at /home/aaron/repos/rust/library/core/src/option.rs:487:29
48: rustc_query_system::query::plumbing::try_execute_query::{{closure}}
at /home/aaron/repos/rust/compiler/rustc_query_system/src/query/plumbing.rs:471:13
49: stacker::maybe_grow
at /home/aaron/.cargo/registry/src/github.com-1ecc6299db9ec823/stacker-0.1.12/src/lib.rs:55:9
50: rustc_data_structures::stack::ensure_sufficient_stack
at /home/aaron/repos/rust/compiler/rustc_data_structures/src/stack.rs:16:5
51: <rustc_query_impl::plumbing::QueryCtxt as rustc_query_system::query::QueryContext>::start_query::{{closure}}::{{closure}}
at /home/aaron/repos/rust/compiler/rustc_query_impl/src/plumbing.rs:169:17
52: rustc_middle::ty::context::tls::enter_context::{{closure}}
at /home/aaron/repos/rust/compiler/rustc_middle/src/ty/context.rs:1736:50
53: rustc_middle::ty::context::tls::set_tlv
at /home/aaron/repos/rust/compiler/rustc_middle/src/ty/context.rs:1720:9
54: rustc_middle::ty::context::tls::enter_context
at /home/aaron/repos/rust/compiler/rustc_middle/src/ty/context.rs:1736:9
55: <rustc_query_impl::plumbing::QueryCtxt as rustc_query_system::query::QueryContext>::start_query::{{closure}}
at /home/aaron/repos/rust/compiler/rustc_query_impl/src/plumbing.rs:168:13
56: rustc_middle::ty::context::tls::with_related_context::{{closure}}
at /home/aaron/repos/rust/compiler/rustc_middle/src/ty/context.rs:1780:13
57: rustc_middle::ty::context::tls::with_context::{{closure}}
at /home/aaron/repos/rust/compiler/rustc_middle/src/ty/context.rs:1764:40
58: rustc_middle::ty::context::tls::with_context_opt
at /home/aaron/repos/rust/compiler/rustc_middle/src/ty/context.rs:1753:22
59: rustc_middle::ty::context::tls::with_context
at /home/aaron/repos/rust/compiler/rustc_middle/src/ty/context.rs:1764:9
60: rustc_middle::ty::context::tls::with_related_context
at /home/aaron/repos/rust/compiler/rustc_middle/src/ty/context.rs:1777:9
61: <rustc_query_impl::plumbing::QueryCtxt as rustc_query_system::query::QueryContext>::start_query
at /home/aaron/repos/rust/compiler/rustc_query_impl/src/plumbing.rs:157:9
62: rustc_query_system::query::plumbing::try_execute_query
at /home/aaron/repos/rust/compiler/rustc_query_system/src/query/plumbing.rs:469:22
63: rustc_query_system::query::plumbing::get_query_impl
at /home/aaron/repos/rust/compiler/rustc_query_system/src/query/plumbing.rs:674:5
64: rustc_query_system::query::plumbing::get_query
at /home/aaron/repos/rust/compiler/rustc_query_system/src/query/plumbing.rs:785:9
65: rustc_middle::ty::query::TyCtxtAt::is_unpin_raw
at /home/aaron/repos/rust/compiler/rustc_middle/src/ty/query/mod.rs:204:17
66: rustc_middle::ty::util::<impl rustc_middle::ty::TyS>::is_unpin
at /home/aaron/repos/rust/compiler/rustc_middle/src/ty/util.rs:727:38
67: rustc_middle::ty::layout::<impl rustc_target::abi::TyAndLayoutMethods<C> for &rustc_middle::ty::TyS>::pointee_info_at
at /home/aaron/repos/rust/compiler/rustc_middle/src/ty/layout.rs:2341:32
68: rustc_target::abi::TyAndLayout<Ty>::pointee_info_at
at /home/aaron/repos/rust/compiler/rustc_target/src/abi/mod.rs:1164:9
69: <rustc_target::abi::call::FnAbi<&rustc_middle::ty::TyS> as rustc_middle::ty::layout::FnAbiExt<C>>::new_internal::{{closure}}
at /home/aaron/repos/rust/compiler/rustc_middle/src/ty/layout.rs:2781:36
70: <rustc_target::abi::call::FnAbi<&rustc_middle::ty::TyS> as rustc_middle::ty::layout::FnAbiExt<C>>::new_internal::{{closure}}::{{closure}}
at /home/aaron/repos/rust/compiler/rustc_middle/src/ty/layout.rs:2840:17
71: rustc_target::abi::call::ArgAbi<Ty>::new
at /home/aaron/repos/rust/compiler/rustc_target/src/abi/call/mod.rs:457:53
72: <rustc_target::abi::call::FnAbi<&rustc_middle::ty::TyS> as rustc_middle::ty::layout::FnAbiExt<C>>::new_internal::{{closure}}
at /home/aaron/repos/rust/compiler/rustc_middle/src/ty/layout.rs:2838:27
73: <rustc_target::abi::call::FnAbi<&rustc_middle::ty::TyS> as rustc_middle::ty::layout::FnAbiExt<C>>::new_internal::{{closure}}
at /home/aaron/repos/rust/compiler/rustc_middle/src/ty/layout.rs:2870:32
74: core::iter::adapters::map::map_fold::{{closure}}
at /home/aaron/repos/rust/library/core/src/iter/adapters/map.rs:82:28
75: <core::iter::adapters::enumerate::Enumerate<I> as core::iter::traits::iterator::Iterator>::fold::enumerate::{{closure}}
at /home/aaron/repos/rust/library/core/src/iter/adapters/enumerate.rs:104:27
76: core::ops::function::impls::<impl core::ops::function::FnMut<A> for &mut F>::call_mut
at /home/aaron/repos/rust/library/core/src/ops/function.rs:269:13
77: core::ops::function::impls::<impl core::ops::function::FnMut<A> for &mut F>::call_mut
at /home/aaron/repos/rust/library/core/src/ops/function.rs:269:13
78: core::iter::adapters::map::map_fold::{{closure}}
at /home/aaron/repos/rust/library/core/src/iter/adapters/map.rs:82:21
79: core::iter::traits::iterator::Iterator::fold
at /home/aaron/repos/rust/library/core/src/iter/traits/iterator.rs:2146:21
80: <core::iter::adapters::map::Map<I,F> as core::iter::traits::iterator::Iterator>::fold
at /home/aaron/repos/rust/library/core/src/iter/adapters/map.rs:122:9
81: <core::iter::adapters::cloned::Cloned<I> as core::iter::traits::iterator::Iterator>::fold
at /home/aaron/repos/rust/library/core/src/iter/adapters/cloned.rs:58:9
82: <core::iter::adapters::chain::Chain<A,B> as core::iter::traits::iterator::Iterator>::fold
at /home/aaron/repos/rust/library/core/src/iter/adapters/chain.rs:119:19
83: <core::iter::adapters::chain::Chain<A,B> as core::iter::traits::iterator::Iterator>::fold
at /home/aaron/repos/rust/library/core/src/iter/adapters/chain.rs:119:19
84: <core::iter::adapters::enumerate::Enumerate<I> as core::iter::traits::iterator::Iterator>::fold
at /home/aaron/repos/rust/library/core/src/iter/adapters/enumerate.rs:110:9
85: <core::iter::adapters::map::Map<I,F> as core::iter::traits::iterator::Iterator>::fold
at /home/aaron/repos/rust/library/core/src/iter/adapters/map.rs:122:9
86: core::iter::traits::iterator::Iterator::for_each
at /home/aaron/repos/rust/library/core/src/iter/traits/iterator.rs:776:9
87: <alloc::vec::Vec<T,A> as alloc::vec::spec_extend::SpecExtend<T,I>>::spec_extend
at /home/aaron/repos/rust/library/alloc/src/vec/spec_extend.rs:40:17
88: <alloc::vec::Vec<T> as alloc::vec::spec_from_iter_nested::SpecFromIterNested<T,I>>::from_iter
at /home/aaron/repos/rust/library/alloc/src/vec/spec_from_iter_nested.rs:56:9
89: <alloc::vec::Vec<T> as alloc::vec::spec_from_iter::SpecFromIter<T,I>>::from_iter
at /home/aaron/repos/rust/library/alloc/src/vec/spec_from_iter.rs:36:9
90: <alloc::vec::Vec<T> as core::iter::traits::collect::FromIterator<T>>::from_iter
at /home/aaron/repos/rust/library/alloc/src/vec/mod.rs:2448:9
91: core::iter::traits::iterator::Iterator::collect
at /home/aaron/repos/rust/library/core/src/iter/traits/iterator.rs:1788:9
92: <rustc_target::abi::call::FnAbi<&rustc_middle::ty::TyS> as rustc_middle::ty::layout::FnAbiExt<C>>::new_internal
at /home/aaron/repos/rust/compiler/rustc_middle/src/ty/layout.rs:2864:19
93: <rustc_target::abi::call::FnAbi<&rustc_middle::ty::TyS> as rustc_middle::ty::layout::FnAbiExt<C>>::of_instance
at /home/aaron/repos/rust/compiler/rustc_middle/src/ty/layout.rs:2670:9
94: rustc_codegen_llvm::mono_item::<impl rustc_codegen_ssa::traits::declare::PreDefineMethods for rustc_codegen_llvm::context::CodegenCx>::predefine_fn
at /home/aaron/repos/rust/compiler/rustc_codegen_llvm/src/mono_item.rs:57:22
95: <rustc_middle::mir::mono::MonoItem as rustc_codegen_ssa::mono_item::MonoItemExt>::predefine
at /home/aaron/repos/rust/compiler/rustc_codegen_ssa/src/mono_item.rs:76:17
96: rustc_codegen_llvm::base::compile_codegen_unit::module_codegen
at /home/aaron/repos/rust/compiler/rustc_codegen_llvm/src/base.rs:122:17
97: rustc_query_system::dep_graph::graph::DepGraph<K>::with_task_impl::{{closure}}
at /home/aaron/repos/rust/compiler/rustc_query_system/src/dep_graph/graph.rs:235:62
98: rustc_middle::dep_graph::<impl rustc_query_system::dep_graph::DepKind for rustc_middle::dep_graph::dep_node::DepKind>::with_deps::{{closure}}::{{closure}}
at /home/aaron/repos/rust/compiler/rustc_middle/src/dep_graph/mod.rs:77:46
99: rustc_middle::ty::context::tls::enter_context::{{closure}}
at /home/aaron/repos/rust/compiler/rustc_middle/src/ty/context.rs:1736:50
100: rustc_middle::ty::context::tls::set_tlv
at /home/aaron/repos/rust/compiler/rustc_middle/src/ty/context.rs:1720:9
101: rustc_middle::ty::context::tls::enter_context
at /home/aaron/repos/rust/compiler/rustc_middle/src/ty/context.rs:1736:9
102: rustc_middle::dep_graph::<impl rustc_query_system::dep_graph::DepKind for rustc_middle::dep_graph::dep_node::DepKind>::with_deps::{{closure}}
at /home/aaron/repos/rust/compiler/rustc_middle/src/dep_graph/mod.rs:77:13
103: rustc_middle::ty::context::tls::with_context::{{closure}}
at /home/aaron/repos/rust/compiler/rustc_middle/src/ty/context.rs:1764:40
104: rustc_middle::ty::context::tls::with_context_opt
at /home/aaron/repos/rust/compiler/rustc_middle/src/ty/context.rs:1753:22
105: rustc_middle::ty::context::tls::with_context
at /home/aaron/repos/rust/compiler/rustc_middle/src/ty/context.rs:1764:9
106: rustc_middle::dep_graph::<impl rustc_query_system::dep_graph::DepKind for rustc_middle::dep_graph::dep_node::DepKind>::with_deps
at /home/aaron/repos/rust/compiler/rustc_middle/src/dep_graph/mod.rs:74:9
107: rustc_query_system::dep_graph::graph::DepGraph<K>::with_task_impl
at /home/aaron/repos/rust/compiler/rustc_query_system/src/dep_graph/graph.rs:235:26
108: rustc_query_system::dep_graph::graph::DepGraph<K>::with_task
at /home/aaron/repos/rust/compiler/rustc_query_system/src/dep_graph/graph.rs:205:9
109: rustc_codegen_llvm::base::compile_codegen_unit
at /home/aaron/repos/rust/compiler/rustc_codegen_llvm/src/base.rs:103:9
110: <rustc_codegen_llvm::LlvmCodegenBackend as rustc_codegen_ssa::traits::backend::ExtraBackendMethods>::compile_codegen_unit
at /home/aaron/repos/rust/compiler/rustc_codegen_llvm/src/lib.rs:109:9
111: rustc_codegen_ssa::base::codegen_crate
at /home/aaron/repos/rust/compiler/rustc_codegen_ssa/src/base.rs:655:38
112: <rustc_codegen_llvm::LlvmCodegenBackend as rustc_codegen_ssa::traits::backend::CodegenBackend>::codegen_crate
at /home/aaron/repos/rust/compiler/rustc_codegen_llvm/src/lib.rs:270:18
113: rustc_interface::passes::start_codegen::{{closure}}
at /home/aaron/repos/rust/compiler/rustc_interface/src/passes.rs:1021:9
114: rustc_data_structures::profiling::VerboseTimingGuard::run
at /home/aaron/repos/rust/compiler/rustc_data_structures/src/profiling.rs:573:9
115: rustc_session::utils::<impl rustc_session::session::Session>::time
at /home/aaron/repos/rust/compiler/rustc_session/src/utils.rs:16:9
116: rustc_interface::passes::start_codegen
at /home/aaron/repos/rust/compiler/rustc_interface/src/passes.rs:1020:19
117: rustc_interface::queries::Queries::ongoing_codegen::{{closure}}::{{closure}}
at /home/aaron/repos/rust/compiler/rustc_interface/src/queries.rs:296:20
118: rustc_interface::passes::QueryContext::enter::{{closure}}
at /home/aaron/repos/rust/compiler/rustc_interface/src/passes.rs:755:42
119: rustc_middle::ty::context::tls::enter_context::{{closure}}
at /home/aaron/repos/rust/compiler/rustc_middle/src/ty/context.rs:1736:50
120: rustc_middle::ty::context::tls::set_tlv
at /home/aaron/repos/rust/compiler/rustc_middle/src/ty/context.rs:1720:9
121: rustc_middle::ty::context::tls::enter_context
at /home/aaron/repos/rust/compiler/rustc_middle/src/ty/context.rs:1736:9
122: rustc_interface::passes::QueryContext::enter
at /home/aaron/repos/rust/compiler/rustc_interface/src/passes.rs:755:9
123: rustc_interface::queries::Queries::ongoing_codegen::{{closure}}
at /home/aaron/repos/rust/compiler/rustc_interface/src/queries.rs:287:13
124: rustc_interface::queries::Query<T>::compute
at /home/aaron/repos/rust/compiler/rustc_interface/src/queries.rs:40:28
125: rustc_interface::queries::Queries::ongoing_codegen
at /home/aaron/repos/rust/compiler/rustc_interface/src/queries.rs:285:9
126: rustc_driver::run_compiler::{{closure}}::{{closure}}
at /home/aaron/repos/rust/compiler/rustc_driver/src/lib.rs:442:13
127: rustc_interface::queries::<impl rustc_interface::interface::Compiler>::enter
at /home/aaron/repos/rust/compiler/rustc_interface/src/queries.rs:428:19
128: rustc_driver::run_compiler::{{closure}}
at /home/aaron/repos/rust/compiler/rustc_driver/src/lib.rs:337:22
129: rustc_interface::interface::create_compiler_and_run::{{closure}}
at /home/aaron/repos/rust/compiler/rustc_interface/src/interface.rs:208:13
130: rustc_span::with_source_map
at /home/aaron/repos/rust/compiler/rustc_span/src/lib.rs:788:5
131: rustc_interface::interface::create_compiler_and_run
at /home/aaron/repos/rust/compiler/rustc_interface/src/interface.rs:202:5
132: rustc_interface::interface::run_compiler::{{closure}}
at /home/aaron/repos/rust/compiler/rustc_interface/src/interface.rs:224:12
133: rustc_interface::util::setup_callbacks_and_run_in_thread_pool_with_globals::{{closure}}::{{closure}}
at /home/aaron/repos/rust/compiler/rustc_interface/src/util.rs:155:13
134: scoped_tls::ScopedKey<T>::set
at /home/aaron/.cargo/registry/src/github.com-1ecc6299db9ec823/scoped-tls-1.0.0/src/lib.rs:137:9
135: rustc_span::with_session_globals
at /home/aaron/repos/rust/compiler/rustc_span/src/lib.rs:105:5
136: rustc_interface::util::setup_callbacks_and_run_in_thread_pool_with_globals::{{closure}}
at /home/aaron/repos/rust/compiler/rustc_interface/src/util.rs:153:9
137: rustc_interface::util::scoped_thread::{{closure}}
at /home/aaron/repos/rust/compiler/rustc_interface/src/util.rs:128:24
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
error: internal compiler error: unexpected panic
note: the compiler unexpectedly panicked. this is a bug.
note: we would appreciate a bug report: https://github.com/rust-lang/rust/issues/new?labels=C-bug%2C+I-ICE%2C+T-compiler&template=ice.md
note: rustc 1.54.0-dev running on x86_64-unknown-linux-gnu
note: compiler flags: -C opt-level=3 -C embed-bitcode=no -C incremental --crate-type lib
note: some of the compiler flags provided by cargo are hidden
query stack during panic:
#0 [evaluate_obligation] evaluating trait selection obligation `quote::Tokens: std::marker::Unpin`
#1 [is_unpin_raw] computing whether `quote::Tokens` is `Unpin`
end of query stack
error: aborting due to previous error
error: could not compile `syn`
To learn more, run the command again with --verbose.
```
I've left in the panic and ICE following the pretty error, so that we still have all of the debug information available in a bug report.
This message can be reproduced by cloning the repository `https://github.com/Aaron1011/syn-crash`, and running the following shell script (with a `rustup override` set in the directory):
```
set -xe
cargo clean -p syn
cargo clean --release -p syn
git checkout minimize
cargo build --release -j 1
git checkout minimize-change
cargo build --release -j 1
```
r? ``@Mark-Simulacrum``
Fix stack overflow when checking for structural recursion
This pull request aims to fix#74224 and fix#84611. The current logic for detecting ADTs with structural recursion is flawed because it only looks at the root type, and then for exact matches. What I mean by this is that for examples such as:
```rust
struct A<T> {
x: T,
y: A<A<T>>,
}
struct B {
z: A<usize>
}
fn main() {}
```
When checking `A`, the compiler correctly determines that it has an infinite size (because the "root" type is `A`, and `A` occurs, albeit with different type arguments, as a nested type in `A`).
However, when checking `B`, it also recurses into `A`, but now `B` is the root type, and it only checks for _exact_ matches of `A`, but since `A` never precisely contains itself (only `A<A<T>>`, `A<A<A<T>>>`, etc.), an endless recursion ensues until the stack overflows.
In this PR, I have attempted to fix this behavior by implementing a two-phase checking: When checking `B`, my code first checks `A` _separately_ and stops if `A` already turns out to be infinite. If not (such as for `Option<T>`), the second phase checks whether the root type (`B`) is ever nested inside itself, e.g.:
```rust
struct Foo { x: Option<Option<Foo>> }
```
Special care needs to be taken for mutually recursive types, e.g.:
```rust
struct A<T> {
z: T,
x: B<T>,
}
struct B<T> {
y: A<T>
}
```
Here, both `A` and `B` both _are_ `SelfRecursive` and _contain_ a recursive type. The current behavior, which I have maintained, is to treat both `A` and `B` as `SelfRecursive`, and accordingly report errors for both.
Fix suggestions for missing return type lifetime specifiers
This pull request aims to fix#84592. The issue is that the current code seems to assume that there is only a single relevant span pointing to the missing lifetime, and only looks at the first one:
e5f83d24ae/compiler/rustc_resolve/src/late/lifetimes.rs (L2959)
This is incorrect, though, and leads to incorrect error messages and invalid suggestions. For instance, the example from #84592:
```rust
struct TwoLifetimes<'x, 'y> {
x: &'x (),
y: &'y (),
}
fn two_lifetimes_needed(a: &(), b: &()) -> TwoLifetimes<'_, '_> {
TwoLifetimes { x: &(), y: &() }
}
```
currently leads to:
```
error[E0106]: missing lifetime specifiers
--> src/main.rs:6:57
|
6 | fn two_lifetimes_needed(a: &(), b: &()) -> TwoLifetimes<'_, '_> {
| --- --- ^^ expected 2 lifetime parameters
|
= help: this function's return type contains a borrowed value, but the signature does not say whether it is borrowed from `a` or `b`
help: consider introducing a named lifetime parameter
|
6 | fn two_lifetimes_needed<'a>(a: &'a (), b: &'a ()) -> TwoLifetimes<'_<'a, 'a>, '_> {
| ^^^^ ^^^^^^ ^^^^^^ ^^^^^^^^^^
```
There are two problems:
- The error message is wrong. There is only _one_ lifetime parameter expected at the location pointed to by the error message (and another one at a separate location).
- The suggestion is incorrect and will not lead to correct code.
With the changes in this PR, I get the following output:
```
error[E0106]: missing lifetime specifiers
--> p.rs:6:57
|
6 | fn two_lifetimes_needed(a: &(), b: &()) -> TwoLifetimes<'_, '_> {
| --- --- ^^ ^^ expected named lifetime parameter
| |
| expected named lifetime parameter
|
= help: this function's return type contains a borrowed value, but the signature does not say whether it is borrowed from `a` or `b`
help: consider introducing a named lifetime parameter
|
6 | fn two_lifetimes_needed<'a>(a: &'a (), b: &'a ()) -> TwoLifetimes<'a, 'a> {
| ^^^^ ^^^^^^ ^^^^^^ ^^ ^^
error: aborting due to previous error
For more information about this error, try `rustc --explain E0106`.
```
Mainly, I changed `add_missing_lifetime_specifiers_label()` to receive a _vector_ of spans (and counts) instead of just one, and adjusted its body accordingly.
rustc_session: Move more option building code from the `options!` macro
The moved code doesn't need to be generated by a macro, it can use a regular (generic) function and type aliases instead.
(The refactoring is salvaged from a branch with different now abandoned work.)
Add primary marker on codegen unit and generate main wrapper on primary codegen.
This is the codegen part of changes extracted from #84062.
This add a marker called `primary` on each codegen units, where exactly one codegen unit will be `primary = true` at a time. This specific codegen unit will take charge of generating `main` wrapper when `main` is imported from a foreign crate after the implementation of RFC 1260.
cc #28937
I'm not sure who should i ask for review for codegen changes, so feel free to reassign.
r? `@nagisa`
Add default search path to `Target::search()`
The function `Target::search()` accepts a target triple and returns a `Target` struct defining the requested target.
There is a `// FIXME 16351: add a sane default search path?` comment that indicates it is desirable to include some sort of default. This was raised in https://github.com/rust-lang/rust/issues/16351 which was closed without any resolution.
https://github.com/rust-lang/rust/pull/31117 was proposed, however that has platform-specific logic that is unsuitable for systems without `/etc/`.
This patch implements the suggestion raised in https://github.com/rust-lang/rust/issues/16351#issuecomment-180878193 where a `target.json` file may be placed in `$(rustc --print sysroot)/lib/rustlib/<target-triple>/target.json`. This allows shipping a toolchain distribution as a single file that gets extracted to the sysroot.
Improve support for NewPM
This adds various missing bits of support for NewPM and allows us to successfully run stage 2 tests with NewPM enabled.
This does not yet enable NewPM by default, as there are still known issue on LLVM 12 (such as a weak fat LTO pipeline). The plan is to make the switch after we update to LLVM 13.
