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.
This doesn't seem to be necessary anymore, although I don't know
at which point or why that changed.
Forcing -O1 makes some tests fail under NewPM, because NewPM also
performs inlining at -O1, so it ends up performing much more
optimization in practice than before.
Remove SpanInterner::get
- It's used exactly once, so it's trivial to replace
- It doesn't match the normal convention for containers: normally
`get()` returns an option and indexing panics. Instead `SpanInterner::get()` panics
and there's no indexing operation available.
Improve diagnostics for functions in `struct` definitions
Tries to implement #76421.
This is probably going to need unit tests, but I wanted to hear from review all the cases tests should cover.
I'd like to follow up with the "mechanically applicable suggestion here that adds an impl block" step, but I'd need guidance. My idea for now would be to try to parse a function, and if that succeeds, create a dummy `ast::Item` impl block to then format it using `pprust`. Would that be a viable approach? Is there a better alternative?
r? `@matklad` cc `@estebank`
rustc: Support Rust-specific features in -Ctarget-feature
Since the beginning of time the `-Ctarget-feature` flag on the command
line has largely been passed unmodified to LLVM. Afterwards, though, the
`#[target_feature]` attribute was stabilized and some of the names in
this attribute do not match the corresponding LLVM name. This is because
Rust doesn't always want to stabilize the exact feature name in LLVM for
the equivalent functionality in Rust. This creates a situation, however,
where in Rust you'd write:
#[target_feature(enable = "pclmulqdq")]
unsafe fn foo() {
// ...
}
but on the command line you would write:
RUSTFLAGS="-Ctarget-feature=+pclmul" cargo build --release
This difference is somewhat odd to deal with if you're a newcomer and
the situation may be made worse with upcoming features like [WebAssembly
SIMD](https://github.com/rust-lang/rust/issues/74372) which may be more
prevalent.
This commit implements a mapping to translate requests via
`-Ctarget-feature` through the same name-mapping functionality that's
present for attributes in Rust going to LLVM. This means that
`+pclmulqdq` will work on x86 targets where as previously it did not.
I've attempted to keep this backwards-compatible where the compiler will
just opportunistically attempt to remap features found in
`-Ctarget-feature`, but if there's something it doesn't understand it
gets passed unmodified to LLVM just as it was before.
rename LLVM target for RustyHermit
- RustyHermit is a library operating system, where the user-
and the kernel-space use the same target
- by a mistake a previous patch changes the target to an incorect value
- this merge request revert the previous changes
Unify rustc and rustdoc parsing of `cfg()`
This extracts a new `parse_cfg` function that's used between both.
- Treat `#[doc(cfg(x), cfg(y))]` the same as `#[doc(cfg(x)]
#[doc(cfg(y))]`. Previously it would be completely ignored.
- Treat `#[doc(inline, cfg(x))]` the same as `#[doc(inline)]
#[doc(cfg(x))]`. Previously, the cfg would be ignored.
- Pass the cfg predicate through to rustc_expand to be validated
Technically this is a breaking change, but doc_cfg is still nightly so I don't think it matters.
Fixes https://github.com/rust-lang/rust/issues/84437.
r? `````````@petrochenkov`````````
illumos should put libc last in library search order
Under some conditions, the toolchain will produce a sequence of linker
arguments that result in a NEEDED list that puts libc before libgcc_s;
e.g.,
[0] NEEDED 0x2046ba libc.so.1
[1] NEEDED 0x204723 libm.so.2
[2] NEEDED 0x204736 libsocket.so.1
[3] NEEDED 0x20478b libumem.so.1
[4] NEEDED 0x204763 libgcc_s.so.1
Both libc and libgcc_s provide an unwinder implementation, but libgcc_s
provides some extra symbols upon which Rust directly depends. If libc
is first in the NEEDED list we will find some of those symbols in libc
but others in libgcc_s, resulting in undefined behaviour as the two
implementations do not use compatible interior data structures.
This solution is not perfect, but is the simplest way to produce correct
binaries on illumos for now.
Report coverage `0` of dead blocks
Fixes: #84018
With `-Z instrument-coverage`, coverage reporting of dead blocks
(for example, blocks dropped because a conditional branch is dropped,
based on const evaluation) is now supported.
If `instrument-coverage` is enabled, `simplify::remove_dead_blocks()`
finds all dropped coverage `Statement`s and adds their `code_region`s as
`Unreachable` coverage `Statement`s to the `START_BLOCK`, so they are
still included in the coverage map.
Check out the resulting changes in the test coverage reports in this PR (in [commit 1](0b0d293c7c)).
r? `@tmandry`
cc: `@wesleywiser`
RustyHermit ist is a library operating system. In this case, we link a static library as kernel to the application. The final result is a bootable application. The library and the application have to use the same target. Currently, the targets are different (see also https://github.com/rust-lang/rust/blob/master/compiler/rustc_target/src/spec/x86_64_unknown_hermit.rs). Consequently, this commit change the LLVM target to 'hermit'.
This kernel spec is needed to disable the usage of FPU registers, which are not allowed in kernel space. In contrast to Linux, everything is running in ring 0 and also in the same address space.
Signed-off-by: Stefan Lankes <slankes@eonerc.rwth-aachen.de>
CTFE inbounds-error-messages tweak
* use CheckInAllocMsg::PointerArithmeticTest for ptr_offset error
* nicer errors for some null pointer cases
r? `@oli-obk`
Coverage instruments closure bodies in macros (not the macro body)
Fixes: #84884
This solution might be considered a compromise, but I think it is the
better choice.
The results in the `closure.rs` test correctly resolve all test cases
broken as described in #84884.
One test pattern (in both `closure_macro.rs` and
`closure_macro_async.rs`) was also affected, and removes coverage
statistics for the lines inside the closure, because the closure
includes a macro. (The coverage remains at the callsite of the macro, so
we lose some detail, but there isn't a perfect choice with macros.
Often macro implementations are split across the macro and the callsite,
and there doesn't appear to be a single "right choice" for which body
should be covered. For the current implementation, we can't do both.
The callsite is most likely to be the preferred site for coverage.
r? `@tmandry`
cc: `@wesleywiser`
Removes unneeded check of `#[no_coverage]` in mapgen
There is an anticipated feature request to support a compiler flag that
only adds coverage for specific files (or perhaps mods). As I thought
about where that change would need to be supported, I realized that
checking the attribute in mapgen (for unused functions) was unnecessary.
The unused functions are only synthesized if they have MIR coverage, and
functions with the `no_coverage` attribute will not have been
instrumented with MIR coverage statements in the first place.
New tests confirm this.
Also, while adding tests, I updated resolved comments and FIXMEs in
other tests, and expanded comments and tests on one remaining issue that
is still not resolved.
r? `@tmandry`
cc: `@wesleywiser`
Rollup of 11 pull requests
Successful merges:
- #84409 (Ensure TLS destructors run before thread joins in SGX)
- #84500 (Add --run flag to compiletest)
- #84728 (Add test for suggestion to borrow unsized function parameters)
- #84734 (Add `needs-unwind` and beginning of support for testing `panic=abort` std to compiletest)
- #84755 (Allow using `core::` in intra-doc links within core itself)
- #84871 (Disallows `#![feature(no_coverage)]` on stable and beta (using standard crate-level gating))
- #84872 (Wire up tidy dependency checks for cg_clif)
- #84896 (Handle incorrect placement of parentheses in trait bounds more gracefully)
- #84905 (CTFE engine: rename copy → copy_intrinsic, move to intrinsics.rs)
- #84953 (Remove unneeded call to with_default_session_globals in rustdoc highlight)
- #84987 (small nits)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Under some conditions, the toolchain will produce a sequence of linker
arguments that result in a NEEDED list that puts libc before libgcc_s;
e.g.,
[0] NEEDED 0x2046ba libc.so.1
[1] NEEDED 0x204723 libm.so.2
[2] NEEDED 0x204736 libsocket.so.1
[3] NEEDED 0x20478b libumem.so.1
[4] NEEDED 0x204763 libgcc_s.so.1
Both libc and libgcc_s provide an unwinder implementation, but libgcc_s
provides some extra symbols upon which Rust directly depends. If libc
is first in the NEEDED list we will find some of those symbols in libc
but others in libgcc_s, resulting in undefined behaviour as the two
implementations do not use compatible interior data structures.
This solution is not perfect, but is the simplest way to produce correct
binaries on illumos for now.
CTFE engine: rename copy → copy_intrinsic, move to intrinsics.rs
The `copy` name is confusing for this function because we also have `copy_op` which is pretty different. I hope `copy_intrinsic` is clearer. Also `step.rs` should really just contain the main loop and opcode dispatch, so move this helper function to a more appropriate place.
r? ``````@oli-obk``````
Disallows `#![feature(no_coverage)]` on stable and beta (using standard crate-level gating)
Fixes: #84836
Removes the function-level feature gating solution originally implemented, and solves the same problem using `allow_internal_unstable`, so normal crate-level feature gating mechanism can still be used (which disallows the feature on stable and beta).
I tested this, building the compiler with and without `CFG_DISABLE_UNSTABLE_FEATURES=1`
With unstable features disabled, I get the expected result as shown here:
```shell
$ ./build/x86_64-unknown-linux-gnu/stage1/bin/rustc src/test/run-make-fulldeps/coverage/no_cov_crate.rs
error[E0554]: `#![feature]` may not be used on the dev release channel
--> src/test/run-make-fulldeps/coverage/no_cov_crate.rs:2:1
|
2 | #![feature(no_coverage)]
| ^^^^^^^^^^^^^^^^^^^^^^^^
error: aborting due to previous error
For more information about this error, try `rustc --explain E0554`.
```
r? ````@Mark-Simulacrum````
cc: ````@tmandry```` ````@wesleywiser````
And adds tests to validate it still works.
There is an anticipated feature request to support a compiler flag that
only adds coverage for specific files (or perhaps mods). As I thought
about where that change would need to be supported, I realized that
checking the attribute in mapgen (for unused functions) was unnecessary.
The unused functions are only synthesized if they have MIR coverage, and
functions with the `no_coverage` attribute will not have been
instrumented with MIR coverage statements in the first place.
New tests confirm this.
Also, while adding tests, I updated resolved comments and FIXMEs in
other tests.
Fixes: #84884
This solution might be considered a compromise, but I think it is the
better choice.
The results in the `closure.rs` test correctly resolve all test cases
broken as described in #84884.
One test pattern (in both `closure_macro.rs` and
`closure_macro_async.rs`) was also affected, and removes coverage
statistics for the lines inside the closure, because the closure
includes a macro. (The coverage remains at the callsite of the macro, so
we lose some detail, but there isn't a perfect choice with macros.
Often macro implementations are split across the macro and the callsite,
and there doesn't appear to be a single "right choice" for which body
should be covered. For the current implementation, we can't do both.
The callsite is most likely to be the preferred site for coverage.
I applied this fix to all `MacroKinds`, not just `Bang`.
I'm trying to resolve an issue of lost coverage in a
`MacroKind::Attr`-based, function-scoped macro. Instead of only
searching for a body_span that is "not a function-like macro" (that is,
MacroKind::Bang), I'm expanding this to all `MacroKind`s. Maybe I should
expand this to `ExpnKind::Desugaring` and `ExpnKind::AstPass` (or
subsets, depending on their sub-kinds) as well, but I'm not sure that's
a good idea.
I'd like to add a test of the `Attr` macro on functions, but I need time
to figure out how to constract a good, simple example without external
crate dependencies. For the moment, all tests still work as expected (no
change), this new commit shouldn't have a negative affect, and more
importantly, I believe it will have a positive effect. I will try to
confirm this.
Deduplicate ParamCandidates with the same value except for bound vars
Fixes#84398
This is kind of a hack. I wonder if we can get other types of candidates that are the same except for bound vars. This won't be a problem with Chalk, since we don't really need to know that there are two different "candidates" if they both give the same final substitution.
r? `@nikomatsakis`
Since the beginning of time the `-Ctarget-feature` flag on the command
line has largely been passed unmodified to LLVM. Afterwards, though, the
`#[target_feature]` attribute was stabilized and some of the names in
this attribute do not match the corresponding LLVM name. This is because
Rust doesn't always want to stabilize the exact feature name in LLVM for
the equivalent functionality in Rust. This creates a situation, however,
where in Rust you'd write:
#[target_feature(enable = "pclmulqdq")]
unsafe fn foo() {
// ...
}
but on the command line you would write:
RUSTFLAGS="-Ctarget-feature=+pclmul" cargo build --release
This difference is somewhat odd to deal with if you're a newcomer and
the situation may be made worse with upcoming features like [WebAssembly
SIMD](https://github.com/rust-lang/rust/issues/74372) which may be more
prevalent.
This commit implements a mapping to translate requests via
`-Ctarget-feature` through the same name-mapping functionality that's
present for attributes in Rust going to LLVM. This means that
`+pclmulqdq` will work on x86 targets where as previously it did not.
I've attempted to keep this backwards-compatible where the compiler will
just opportunistically attempt to remap features found in
`-Ctarget-feature`, but if there's something it doesn't understand it
gets passed unmodified to LLVM just as it was before.
lazify backtrace formatting for delayed diagnostics
Formatting backtraces causes debug info to be parsed, which is superfluous work if the delayed bugs get cleared later.
Lazifying them results in these speedups for the UI testsuite:
| | debuginfo = 0 | debuginfo = 1 | debuginfo = 2 |
|-------|---------------|---------------|---------------|
| eager | 31.59s | 37.55s | 42.64s |
| lazy | 30.44s | 30.86s | 34.07s |
Fix#84467 linker_args with --target=sparcv9-sun-solaris
Trying to cross-compile for sparcv9-sun-solaris
getting a error message for -zignore
Introduced when -z -ignore was seperated here
22d0ab0
No formatting done
Reproduce
``` bash
rustup target add sparcv9-sun-solaris
cargo new --bin hello && cd hello && cargo run --target=sparcv9-sun-solaris
```
config.toml
[target.sparcv9-sun-solaris]
linker = "gcc"
This commit implements both the native linking modifiers infrastructure
as well as an initial attempt at the individual modifiers from the RFC.
It also introduces a feature flag for the general syntax along with
individual feature flags for each modifier.
This defers backtrace formatting to the point where we
actually want to flush delayed diagnostics. If they are discarded
before that point then we can avoid invoking the backtrace formatting
machinery which will parse debug info and symbol tables.
for debuginfo=2 this leads to a 20% walltime reduction of the UI testsuite
Do not ICE on invalid const param
When encountering a path that can't have generics, do not call
`generics_of`. This would happen when writing something like
`path::this_is_a_mod<const_val>`.
Fix#84831.
Remove `rustc_middle::mir::interpret::CheckInAllocMsg::NullPointerTest`
Removing it per https://github.com/rust-lang/rust/pull/84842#discussion_r625589674: it's a dead enum variant.
Note that `PointerArithmeticTest` also seems dead:
```
$ rg -F PointerArithmeticTest -C5
compiler/rustc_middle/src/mir/interpret/error.rs
169-
170-/// Details of why a pointer had to be in-bounds.
171-#[derive(Debug, Copy, Clone, TyEncodable, TyDecodable, HashStable)]
172-pub enum CheckInAllocMsg {
173- MemoryAccessTest,
174: PointerArithmeticTest,
175- InboundsTest,
176-}
177-
178-impl fmt::Display for CheckInAllocMsg {
179- /// When this is printed as an error the context looks like this
--
182- write!(
183- f,
184- "{}",
185- match *self {
186- CheckInAllocMsg::MemoryAccessTest => "memory access",
187: CheckInAllocMsg::PointerArithmeticTest => "pointer arithmetic",
188- CheckInAllocMsg::InboundsTest => "inbounds test",
189- }
190- )
191- }
192-}
```
Not sure if that is also desirable to be removed, however.
using allow_internal_unstable (as recommended)
Fixes: #84836
```shell
$ ./build/x86_64-unknown-linux-gnu/stage1/bin/rustc src/test/run-make-fulldeps/coverage/no_cov_crate.rs
error[E0554]: `#![feature]` may not be used on the dev release channel
--> src/test/run-make-fulldeps/coverage/no_cov_crate.rs:2:1
|
2 | #![feature(no_coverage)]
| ^^^^^^^^^^^^^^^^^^^^^^^^
error: aborting due to previous error
For more information about this error, try `rustc --explain E0554`.
```
