Add `#[define_opaques]` attribute and require it for all type-alias-impl-trait sites that register a hidden type
Instead of relying on the signature of items to decide whether they are constraining an opaque type, the opaque types that the item constrains must be explicitly listed.
A previous version of this PR used an actual attribute, but had to keep the resolved `DefId`s in a side table.
Now we just lower to fields in the AST that have no surface syntax, instead a builtin attribute macro fills in those fields where applicable.
Note that for convenience referencing opaque types in associated types from associated methods on the same impl will not require an attribute. If that causes problems `#[defines()]` can be used to overwrite the default of searching for opaques in the signature.
One wart of this design is that closures and static items do not have generics. So since I stored the opaques in the generics of functions, consts and methods, I would need to add a custom field to closures and statics to track this information. During a T-types discussion we decided to just not do this for now.
fixes#131298
Reduce formatting `width` and `precision` to 16 bits
This is part of https://github.com/rust-lang/rust/issues/99012
This is reduces the `width` and `precision` fields in format strings to 16 bits. They are currently full `usize`s, but it's a bit nonsensical that we need to support the case where someone wants to pad their value to eighteen quintillion spaces and/or have eighteen quintillion digits of precision.
By reducing these fields to 16 bit, we can reduce `FormattingOptions` to 64 bits (see https://github.com/rust-lang/rust/pull/136974) and improve the in memory representation of `format_args!()`. (See additional context below.)
This also fixes a bug where the width or precision is silently truncated when cross-compiling to a target with a smaller `usize`. By reducing the width and precision fields to the minimum guaranteed size of `usize`, 16 bits, this bug is eliminated.
This is a breaking change, but affects almost no existing code.
---
Details of this change:
There are three ways to set a width or precision today:
1. Directly a formatting string, e.g. `println!("{a:1234}")`
2. Indirectly in a formatting string, e.g. `println!("{a:width$}", width=1234)`
3. Through the unstable `FormattingOptions::width` method.
This PR:
- Adds a compiler error for 1. (`println!("{a:9999999}")` no longer compiles and gives a clear error.)
- Adds a runtime check for 2. (`println!("{a:width$}, width=9999999)` will panic.)
- Changes the signatures of the (unstable) `FormattingOptions::[get_]width` methods to use a `u16` instead.
---
Additional context for improving `FormattingOptions` and `fmt::Arguments`:
All the formatting flags and options are currently:
- The `+` flag (1 bit)
- The `-` flag (1 bit)
- The `#` flag (1 bit)
- The `0` flag (1 bit)
- The `x?` flag (1 bit)
- The `X?` flag (1 bit)
- The alignment (2 bits)
- The fill character (21 bits)
- Whether a width is specified (1 bit)
- Whether a precision is specified (1 bit)
- If used, the width (a full usize)
- If used, the precision (a full usize)
Everything except the last two can simply fit in a `u32` (those add up to 31 bits in total).
If we can accept a max width and precision of u16::MAX, we can make a `FormattingOptions` that is exactly 64 bits in size; the same size as a thin reference on most platforms.
If, additionally, we also limit the number of formatting arguments, we can also reduce the size of `fmt::Arguments` (that is, of a `format_args!()` expression).
Revert "Use workspace lints for crates in `compiler/` #138084"
Revert <https://github.com/rust-lang/rust/pull/138084> to buy time to consider options that avoids breaking downstream usages of cargo on distributed `rustc-src` artifacts, where such cargo invocations fail due to inability to inherit `lints` from workspace root manifest's `workspace.lints` (this is only valid for the source rust-lang/rust workspace, but not really the distributed `rustc-src` artifacts). The problem is that the `rustc-src` component doesn't include the root `Cargo.toml` manifest.
This breakage was reported in https://github.com/rust-lang/rust/issues/138304.
This reverts commit 48caf81484, reversing changes made to c6662879b2.
cc `@RalfJung`
r? `@nnethercote` (sorry, I didn't consider this being a thing 💀)
Revert <https://github.com/rust-lang/rust/pull/138084> to buy time to
consider options that avoids breaking downstream usages of cargo on
distributed `rustc-src` artifacts, where such cargo invocations fail due
to inability to inherit `lints` from workspace root manifest's
`workspace.lints` (this is only valid for the source rust-lang/rust
workspace, but not really the distributed `rustc-src` artifacts).
This breakage was reported in
<https://github.com/rust-lang/rust/issues/138304>.
This reverts commit 48caf81484, reversing
changes made to c6662879b2.
By naming them in `[workspace.lints.rust]` in the top-level
`Cargo.toml`, and then making all `compiler/` crates inherit them with
`[lints] workspace = true`. (I omitted `rustc_codegen_{cranelift,gcc}`,
because they're a bit different.)
The advantages of this over the current approach:
- It uses a standard Cargo feature, rather than special handling in
bootstrap. So, easier to understand, and less likely to get
accidentally broken in the future.
- It works for proc macro crates.
It's a shame it doesn't work for rustc-specific lints, as the comments
explain.
Rollup of 17 pull requests
Successful merges:
- #137827 (Add timestamp to unstable feature usage metrics)
- #138041 (bootstrap and compiletest: Use `size_of_val` from the prelude instead of imported)
- #138046 (trim channel value in `get_closest_merge_commit`)
- #138053 (Increase the max. custom try jobs requested to `20`)
- #138061 (triagebot: add a `compiler_leads` ad-hoc group)
- #138064 (Remove - from xtensa targets cpu names)
- #138075 (Use final path segment for diagnostic)
- #138078 (Reduce the noise of bootstrap changelog warnings in --dry-run mode)
- #138081 (Move `yield` expressions behind their own feature gate)
- #138090 (`librustdoc`: flatten nested ifs)
- #138092 (Re-add `DynSend` and `DynSync` impls for `TyCtxt`)
- #138094 (a small borrowck cleanup)
- #138098 (Stabilize feature `const_copy_from_slice`)
- #138103 (Git ignore citool's target directory)
- #138105 (Fix broken link to Miri intrinsics in documentation)
- #138108 (Mention me (WaffleLapkin) when changes to `rustc_codegen_ssa` occur)
- #138117 ([llvm/PassWrapper] use `size_t` when building arg strings)
r? `@ghost`
`@rustbot` modify labels: rollup
Provide more context on resolve error caused from incorrect RTN
When encountering a resolve E0575 error for an associated method (when a type was expected), see if it could have been an intended return type notation bound.
```
error[E0575]: expected associated type, found associated function `Trait::method`
--> $DIR/bad-inputs-and-output.rs:31:36
|
LL | fn foo_qualified<T: Trait>() where <T as Trait>::method(i32): Send {}
| ^^^^^^^^^^^^^^^^^^^^^^^^^ not a associated type
|
help: you might have meant to use the return type notation syntax
|
LL - fn foo_qualified<T: Trait>() where <T as Trait>::method(i32): Send {}
LL + fn foo_qualified<T: Trait>() where T::method(..): Send {}
|
```
Built on top of #137824, only second commit is relevant for review.
r? ````````@compiler-errors````````
When `#![feature(min_generic_const_args)]` is enabled, we now lower all
const paths in generic arg position to `hir::ConstArgKind::Path`. We
then lower assoc const paths to `ty::ConstKind::Unevaluated` since we
can no longer use the anon const expression lowering machinery. In the
process of implementing this, I factored out `hir_ty_lowering` code that
is now shared between lowering assoc types and assoc consts.
This PR also introduces a `#[type_const]` attribute for trait assoc
consts that are allowed as const args. However, we still need to
implement code to check that assoc const definitions satisfy
`#[type_const]` if present (basically is it a const path or a
monomorphic anon const).
When encountering a resolve E0575 error for an associated method (when a type was expected), see if it could have been an intended return type notation bound.
```
error[E0575]: expected associated type, found associated function `Trait::method`
--> $DIR/bad-inputs-and-output.rs:31:36
|
LL | fn foo_qualified<T: Trait>() where <T as Trait>::method(i32): Send {}
| ^^^^^^^^^^^^^^^^^^^^^^^^^ not a associated type
|
help: you might have meant to use the return type notation syntax
|
LL - fn foo_qualified<T: Trait>() where <T as Trait>::method(i32): Send {}
LL + fn foo_qualified<T: Trait>() where T::method(..): Send {}
|
```
Implement `#[cfg]` in `where` clauses
This PR implements #115590, which supports `#[cfg]` attributes in `where` clauses.
The biggest change is, that it adds `AttrsVec` and `NodeId` to the `ast::WherePredicate` and `HirId` to the `hir::WherePredicate`.
Tweak incorrect ABI suggestion and make suggestion verbose
Provide a better suggestion message, and make the suggestion verbose.
```
error[E0703]: invalid ABI: found `riscv-interrupt`
--> $DIR/riscv-discoverability-guidance.rs:17:8
|
LL | extern "riscv-interrupt" fn isr() {}
| ^^^^^^^^^^^^^^^^^ invalid ABI
|
= note: invoke `rustc --print=calling-conventions` for a full list of supported calling conventions
help: there's a similarly named valid ABI `riscv-interrupt-m`
|
LL | extern "riscv-interrupt-m" fn isr() {}
| ++
```
unconditionally lower match arm even if it's unneeded for never pattern in match
fixes#137708
Lowering arm body is skipped when lowering match arm with never pattern, but we may need the HirId for DefId in the body in later passes. And then we got the ICE `No HirId for DefId`.
Fixes this by lowering the arm body even if it's unneeded for never pattern in match, so that we can generate HirId and use it then.
r? `@compiler-errors`
Provide a better suggestion message, and make the suggestion verbose.
```
error[E0703]: invalid ABI: found `riscv-interrupt`
--> $DIR/riscv-discoverability-guidance.rs:17:8
|
LL | extern "riscv-interrupt" fn isr() {}
| ^^^^^^^^^^^^^^^^^ invalid ABI
|
= note: invoke `rustc --print=calling-conventions` for a full list of supported calling conventions
help: there's a similarly named valid ABI `"riscv-interrupt-m"`
|
LL | extern "riscv-interrupt-m" fn isr() {}
| ++
```
Greatly simplify lifetime captures in edition 2024
Remove most of the `+ Captures` and `+ '_` from the compiler, since they are now unnecessary with the new edition 2021 lifetime capture rules. Use some `+ 'tcx` and `+ 'static` rather than being overly verbose with precise capturing syntax.
Give `global_asm` a fake body to store typeck results, represent `sym fn` as a hir expr to fix `sym fn` operands with lifetimes
There are a few intertwined problems with `sym fn` operands in both inline and global asm macros.
Specifically, unlike other anon consts, they may evaluate to a type with free regions in them without actually having an item-level type annotation to give them a "proper" type. This is in contrast to named constants, which always have an item-level type annotation, or unnamed constants which are constrained by their position (e.g. a const arg in a turbofish, or a const array length).
Today, we infer the type of the operand by looking at the HIR typeck results; however, those results are region-erased, so during borrowck we ICE since we don't expect to encounter erased regions. We can't just fill this type with something like `'static`, since we may want to use real (free) regions:
```rust
fn foo<'a>() {
asm!("/* ... */", sym bar::<&'a ()>);
}
```
The first idea may be to represent `sym fn` operands using *inline* consts instead of anon consts. This makes sense, since inline consts can reference regions from the parent body (like the `'a` in the example above). However, this introduces a problem with `global_asm!`, which doesn't *have* a parent body; inline consts *must* be associated with a parent body since they are not a body owner of their own. In #116087, I attempted to fix this by using two separate `sym` operands for global and inline asm. However, this led to a lot of confusion and also some unattractive code duplication.
In this PR, I adjust the lowering of `global_asm!` so that it's lowered in a "fake" HIR body. This body contains a single expression which is `ExprKind::InlineAsm`; we don't *use* this HIR body, but it's used in typeck and borrowck so that we can properly infer and validate the the lifetimes of `sym fn` operands.
I then adjust the lowering of `sym fn` to instead be represented with a HIR expression. This is both because it's no longer necessary to represent this operand as an anon const, since it's *just* a path expression, and also more importantly to sidestep yet another ICE (https://github.com/rust-lang/rust/issues/137179), which has to do with the existing code breaking an invariant of def-id creation and anon consts. Specifically, we are not allowed to synthesize a def-id for an anon const when that anon const contains expressions with def-ids whose parent is *not* that anon const. This is somewhat related to https://github.com/rust-lang/rust/pull/130443#issuecomment-2445678945, which is also a place in the compiler where synthesizing anon consts leads to def-id parenting issue.
As a side-effect, this consolidates the type checking for inline and global asm, so it allows us to simplify `InlineAsmCtxt` a bit. It also allows us to delete a bit of hacky code from anon const `type_of` which was there to detect `sym fn` operands specifically. This also could be generalized to support `const` asm operands with types with lifetimes in them. Since we specifically reject these consts today, I'm not going to change the representation of those consts (but they'd just be turned into inline consts).
r? oli-obk -- mostly b/c you're patient and also understand the breadth of the code that this touches, please reassign if you don't want to review this.
Fixes#111709Fixes#96304Fixes#137179
