forbid `impl Trait` in generic param defaults
Fixes#83929
Forbid using `impl Trait` in the default types of generic parameters, e.g. `struct Foo<T = impl Trait>`. I assume this was never supposed to be allowed - it seems no UI test used it.
Note that using `impl Trait` in this position did not hit a feature gate error; however, this *shouldn't* be a breaking change as any attempt to use it should have hit the ICE in #83929 and/or failed to provide a defining use of the `impl Trait`.
Use AnonConst for asm! constants
This replaces the old system which used explicit promotion. See #83169 for more background.
The syntax for `const` operands is still the same as before: `const <expr>`.
Fixes#83169
Because the implementation is heavily based on inline consts, we suffer from the same issues:
- We lose the ability to use expressions derived from generics. See the deleted tests in `src/test/ui/asm/const.rs`.
- We are hitting the same ICEs as inline consts, for example #78174. It is unlikely that we will be able to stabilize this before inline consts are stabilized.
Allow specifying alignment for functions
Fixes#75072
This allows the user to specify alignment for functions, which can be useful for low level work where functions need to necessarily be aligned to a specific value.
I believe the error cases not covered in the match are caught earlier based on my testing so I had them just return `None`.
expand: Do not ICE when a legacy AST-based macro attribute produces and empty expression
Fixes https://github.com/rust-lang/rust/issues/80251
The reported error is the same as for `let _ = #[cfg(FALSE)] EXPR;`
Prevent very long compilation runtimes in LateBoundRegionNameCollector
Fixes https://github.com/rust-lang/rust/issues/83150
On recursive types such as in the example given in https://github.com/rust-lang/rust/issues/83150, the current implementation of `LateBoundRegionNameCollector` has very long compilation runtimes. To prevent those we store the types visited in the `middle::ty::Visitor` implementation of `LateBoundRegionNameCollector` in a `SsoHashSet`.
Let `#[allow(unstable_name_collisions)]` work for things other than function
Fixes#81522
In addition to the report in #81522, currently `#[allow(unstable_name_collisions)]` doesn't suppress the corresponding diagnostics even if this attribute is appended to an expression statement or a let statement. It seems like this is because the wrong `HirId` is passed to `struct_span_lint_hir`.
It's fixed in this PR, and a regression test for it is also added.
This is step 2 towards fixing #77548.
In the codegen and codegen-units test suites, the `//` comment markers
were kept in order not to affect any source locations. This is because
these tests cannot be automatically `--bless`ed.
Maintain supported sanitizers as a target property
In an effort to remove a hard-coded allow-list for target-sanitizer support correspondence, this PR moves the configuration to the target options.
Perhaps the one notable change made in this PR is this doc-comment:
```rust
/// The sanitizers supported by this target
///
/// Note that the support here is at a codegen level. If the machine code with sanitizer
/// enabled can generated on this target, but the necessary supporting libraries are not
/// distributed with the target, the sanitizer should still appear in this list for the target.
```
Previously the target would typically be added to the allow-list at the same time as the supporting runtime libraries are shipped for the target. However whether we ship the runtime libraries or not needn't be baked into the compiler; and if we don't users will receive a significantly more directed error about library not being found.
Fixes#81802
This commit adds an additional target property – `supported_sanitizers`,
and replaces the hardcoded allowlists in argument parsing to use this
new property.
Fixes#81802
2229: Support migration via rustfix
- Adds support of machine applicable suggestions for `disjoint_capture_drop_reorder`.
- Doesn't migrate in the case of pre-existing bugs in user code
r? ``@nikomatsakis``
Rollup of 5 pull requests
Successful merges:
- #83535 (Break when there is a mismatch in the type count)
- #83721 (Add a button to copy the "use statement")
- #83740 (Fix comment typo in once.rs)
- #83745 (Add my new email address to .mailmap)
- #83754 (Add test to ensure search tabs behaviour)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Break when there is a mismatch in the type count
When other errors are generated, there can be a mismatch between the
amount of input types in MIR, and the amount in the function itself.
Break from the comparative loop if this is the case to prevent
out-of-bounds.
Fixes#83499
normalize mir::Constant differently from ty::Const in preparation for valtrees
Valtrees are unable to represent many kind of constant values (this is on purpose). For constants that are used at runtime, we do not need a valtree representation and can thus use a different form of evaluation. In order to make this explicit and less fragile, I added a `fold_constant` method to `TypeFolder` and implemented it for normalization. Normalization can now, when it wants to eagerly evaluate a constant, normalize `mir::Constant` directly into a `mir::ConstantKind::Val` instead of relying on the `ty::Const` evaluation.
In the future we can get rid of the `ty::Const` in there entirely and add our own `Unevaluated` variant to `mir::ConstantKind`. This would allow us to remove the `promoted` field from `ty::ConstKind::Unevaluated`, as promoteds can never occur in the type system.
cc `@rust-lang/wg-const-eval`
r? `@lcnr`
Rename `#[doc(spotlight)]` to `#[doc(notable_trait)]`
Fixes#80936.
"spotlight" is not a very specific or self-explaining name.
Additionally, the dialog that it triggers is called "Notable traits".
So, "notable trait" is a better name.
* Rename `#[doc(spotlight)]` to `#[doc(notable_trait)]`
* Rename `#![feature(doc_spotlight)]` to `#![feature(doc_notable_trait)]`
* Update documentation
* Improve documentation
r? `@Manishearth`
Fix expected/found order on impl trait projection mismatch error
fixes#68561
This PR adds a new `ObligationCauseCode` used when checking the concrete type of an impl trait satisfies its bounds, and checks for that cause code in the existing test to see if a projection's normalized type should be the "expected" or "found" type.
The second commit adds a `peel_derives` to that test, which appears to be necessary in some cases (see projection-mismatch-in-impl-where-clause.rs, which would still give expected/found in the wrong order otherwise). This caused some other changes in diagnostics not involving impl trait, but they look correct to me.
Stream the dep-graph to a file instead of storing it in-memory.
This is a reimplementation of #60035.
Instead of storing the dep-graph in-memory, the nodes are encoded as they come
into the a temporary file as they come. At the end of a successful the compilation,
this file is renamed to be the persistent dep-graph, to be decoded during the next
compilation session.
This two-files scheme avoids overwriting the dep-graph on unsuccessful or crashing compilations.
The structure of the file is modified to be the sequence of `(DepNode, Fingerprint, EdgesVec)`.
The deserialization is responsible for going to the more compressed representation.
The `node_count` and `edge_count` are stored in the last 16 bytes of the file,
in order to accurately reserve capacity for the vectors.
At the end of the compilation, the encoder is flushed and dropped.
The graph is not usable after this point: any creation of a node will ICE.
I had to retrofit the debugging options, which is not really pretty.
