Fix const items not being allowed to be called `r#move` or `r#static`
Because of an ambiguity with const closures, the parser needs to ensure that for a const item, the `const` keyword isn't followed by a `move` or `static` keyword, as that would indicate a const closure:
```rust
fn main() {
const move // ...
}
```
This check did not take raw identifiers into account, therefore being unable to distinguish between `const move` and `const r#move`. The latter is obviously not a const closure, so it should be allowed as a const item.
This fixes the check in the parser to only treat `const ...` as a const closure if it's followed by the *proper keyword*, and not a raw identifier.
Additionally, this adds a large test that tests for all raw identifiers in all kinds of positions, including `const`, to prevent issues like this one from occurring again.
fixes#137128
Pattern Migration 2024: clean up and comment
This follows up on #136577 by moving the pattern migration logic to its own module, removing a bit of unnecessary complexity, and adding comments. Since there's quite a bit of pattern migration logic now (and potentially more in #136496), I think it makes sense to keep it separate from THIR construction, at least as much as is convenient.
r? ``@Nadrieril``
Overhaul `rustc_middle::limits`
In particular, to make `pattern_complexity` work more like other limits, which then enables some other simplifications.
r? ``@Nadrieril``
Start removing `rustc_middle::hir::map::Map`
`rustc_middle::hir::map::Map` is now just a low-value wrapper around `TyCtxt`. This PR starts removing it.
r? `@cjgillot`
First of all, note that `Map` has three different relevant meanings.
- The `intravisit::Map` trait.
- The `map::Map` struct.
- The `NestedFilter::Map` associated type.
The `intravisit::Map` trait is impl'd twice.
- For `!`, where the methods are all unreachable.
- For `map::Map`, which gets HIR stuff from the `TyCtxt`.
As part of getting rid of `map::Map`, this commit changes `impl
intravisit::Map for map::Map` to `impl intravisit::Map for TyCtxt`. It's
fairly straightforward except various things are renamed, because the
existing names would no longer have made sense.
- `trait intravisit::Map` becomes `trait intravisit::HirTyCtxt`, so named
because it gets some HIR stuff from a `TyCtxt`.
- `NestedFilter::Map` assoc type becomes `NestedFilter::MaybeTyCtxt`,
because it's always `!` or `TyCtxt`.
- `Visitor::nested_visit_map` becomes `Visitor::maybe_tcx`.
I deliberately made the new trait and associated type names different to
avoid the old `type Map: Map` situation, which I found confusing. We now
have `type MaybeTyCtxt: HirTyCtxt`.
The end goal is to eliminate `Map` altogether.
I added a `hir_` prefix to all of them, that seemed simplest. The
exceptions are `module_items` which became `hir_module_free_items` because
there was already a `hir_module_items`, and `items` which became
`hir_free_items` for consistency with `hir_module_free_items`.
It's always good to make `rustc_middle` smaller. `rustc_interface` is
the best destination, because it's the only crate that calls
`get_recursive_limit`.
It's similar to the other limits, e.g. obtained via `get_limit`. So it
makes sense to handle it consistently with the other limits. We now use
`Limit`/`usize` in most places instead of `Option<usize>`, so we use
`Limit::new(usize::MAX)`/`usize::MAX` to emulate how `None` used to work.
The commit also adds `Limit::unlimited`.
Because of an ambiguity with const closures, the parser needs to ensure
that for a const item, the `const` keyword isn't followed by a `move` or
`static` keyword, as that would indicate a const closure:
```rust
fn main() {
const move // ...
}
```
This check did not take raw identifiers into account, therefore being
unable to distinguish between `const move` and `const r#move`. The
latter is obviously not a const closure, so it should be allowed as a
const item.
This fixes the check in the parser to only treat `const ...` as a const
closure if it's followed by the *proper keyword*, and not a raw
identifier.
Additionally, this adds a large test that tests for all raw identifiers in
all kinds of positions, including `const`, to prevent issues like this
one from occurring again.
Rework `name_regions` to not rely on reverse scc graph for non-member-constrain usages
Fixes https://github.com/rust-lang/rust/issues/137015
Splits the `name_regions` into two versions: One meant for member region constraint error reporting (which I've renamed to `name_regions_for_member_constraint`), and one meant *just* to replace region vids with an external region.
Use the latter in the usage sites I added in #136559, since the regions returned by `name_regions_for_member_constraint` are also not *totally* accurate (which is fine for how they're used for member region constraint error reporting -- they're intentionally returning overapproximated universal regions so that we have something to name in `+ use<'a>` suggestions, because opaques can only capture universal regions and since member region constraints don't insert any edges into the region graph, the error region is probably gonna be shorter than a universal region) and because that function requires the reverse scc graph to have been computed which isn't done for our usages in #136559.
Load all builtin targets at once instead of one by one in check-cfg
This PR adds a method on `rustc_target::Target` to load all the builtin targets at once, and then uses that method when constructing the `target_*` values in check-cfg instead of load loading each target one by one by their name, which requires a lookup and was more of a hack anyway.
This may give us some performance improvements as we won't need to do the lookup for the _currently_ 287 targets we have.
rustdoc: improve refdef handling in the unresolved link lint
This commit takes advantage of a feature in pulldown-cmark that makes the list of link definitions available to the consuming application. It produces unresolved link warnings for refdefs that aren't used, and can now produce exact spans for the dest even when it has escapes.
Closes#133150 since this lint would have caught the mistake in that issue, and, along with https://github.com/rust-lang/rust-clippy/pull/13707, most mistakes in this class should produce a warning from one of them.
Rollup of 5 pull requests
Successful merges:
- #135797 (Import initial generated 1.85 relnotes)
- #135909 (Export kernel descriptor for amdgpu kernels)
- #136545 (nvptx64: update default alignment to match LLVM 21)
- #137092 (abi_unsupported_vector_types: say which type is the problem)
- #137097 (Ignore Self in bounds check for associated types with Self:Sized)
r? `@ghost`
`@rustbot` modify labels: rollup
nvptx64: update default alignment to match LLVM 21
This changed in llvm/llvm-project@91cb8f5d32. The commit itself is mostly about some intrinsic instructions, but as an aside it also mentions something about addrspace for tensor memory, which I believe is what this string is telling us.
`@rustbot` label: +llvm-main
Export kernel descriptor for amdgpu kernels
The host runtime (HIP or HSA) expects a kernel descriptor object for each kernel in the ELF file. The amdgpu LLVM backend generates the object. It is created as a symbol with the name of the kernel plus a `.kd` suffix.
Add it to the exported symbols in the linker script, so that it can be found.
For reference, the symbol is created here in LLVM: d5457e4c16/llvm/lib/Target/AMDGPU/MCTargetDesc/AMDGPUTargetStreamer.cpp (L966)
I wrote [a test](6a9115b121) for this as well, I’ll add that once the target is merged and working.
With this, all PRs to get working code for amdgpu are open (this + the target + the two patches adding addrspacecasts for alloca and global variables).
Tracking issue: #135024
r? `@workingjubilee`
This commit takes advantage of a feature in pulldown-cmark that
makes the list of link definitions available to the consuming
application. It produces unresolved link warnings for refdefs
that aren't used, and can now produce exact spans for the dest
even when it has escapes.
Try to recover from path sep error in type parsing
Fixes#129273
Error using `:` in the argument list may mess up the parser.
case `tests/ui/suggestions/struct-field-type-including-single-colon` also changed, seems it's the same meaning, should be OK.
r? `@estebank`
Do not allow attributes on struct field rest patterns
Fixes#81282.
This removes support for attributes on struct field rest patterns (the `..` bit) from the parser. Previously any attributes were being parsed but dropped from the AST, so didn't work and were deleted by rustfmt.
This needs an equivalent change to the reference but I wanted to see how this PR is received first.
The error message it produces isn't great, however it does match the error you get if you try to add attributes to .. in struct expressions atm, although I can understand wanting to do better given this was previously accepted. I think I could move attribute parsing back up to where it was and then emit a specific new error for this case, however I might need some guidance as this is the first time I've messed around inside the compiler.
While this is technically breaking I don't think it's much of an issue: attributes in this position don't currently do anything and rustfmt outright deletes them, meaning it's incredibly unlikely to affect anyone. I have already made the equivalent change to *add* support for attributes (mostly) but the conversation in the linked issue suggested it would be more reasonable to just remove them (and pointed out it's much easier to add support later if we realise we need them).
Fix crate name validation
Reject macro calls inside attribute `#![crate_name]` like in `#![crate_name = concat!("na", "me")]`.
Prior to #117584, the result of the expansion (here: `"name"`) would actually be properly picked up by the compiler and used as the crate name. However since #117584 / on master, we extract the "value" (i.e., the *literal* string literal) of the `#![crate_name]` much earlier in the pipeline way before macro expansion and **skip**/**ignore** any `#![crate_name]`s "assigned to" a macro call. See also #122001.
T-lang has ruled to reject `#![crate_name = MACRO!(...)]` outright very similar to other built-in attributes whose value we need early like `#![crate_type]`. See accepted FCP: https://github.com/rust-lang/rust/issues/122001#issuecomment-2023203182.
Note that the check as implemented in this PR is even more "aggressive" compared to the one of `#![crate_type]` by running as early as possible in order to reject `#![crate_name = MACRO!(...)]` even in "non-normal" executions of `rustc`, namely on *print requests* (e.g., `--print=crate-name` and `--print=file-names`). If I were to move the validation step a bit further back close to the `#![crate_type]` one, `--print=crate-name` (etc.) would *not* exit fatally with an error in this kind of situation but happily report an incorrect crate name (i.e., the "crate name" as if `#![crate_name]` didn't exist / deduced from other sources like `--crate-name` or the file name) which would match the behavior on master. Again, see also #122001.
I'm mentioning this explicitly because I'm not sure if it was that clear in the FCP'ed issue. I argue that my current approach is the most reasonable one. I know (from reading the code and from past experiments) that various print requests are still quite broken (mostly lack of validation).
To the best of my knowledge, there's no print request whose output references/contains a crate *type*, so there's no "inherent need" to move `#![crate_type]`'s validation to happen earlier.
---
Fixes#122001.
https://github.com/rust-lang/rust/labels/relnotes: Compatibility. Breaking change.
mir_build: Clarify some code for lowering `hir::PatExpr` to THIR
A few loosely-related improvements to the code that lowers certain parts of HIR patterns to THIR.
I was originally deferring this until after #136529, but that PR probably won't happen, whereas these changes should hopefully be uncontroversial.
r? Nadrieril or reroll
