compiletest: don't register predefined `MSVC`/`NONMSVC` FileCheck prefixes
This was fragile as it was based on host target passed to compiletest,
but the user could cross-compile and run test for a different target
(e.g. cross from linux to msvc, but msvc won't be set on the target).
Furthermore, it was also very surprising as normally revision names
(other than `CHECK`) was accepted as FileCheck prefixes.
This partially reverts the `MSVC`/`NONMSVC` predefined FileCheck
prefix registration introduced historically for some codegen tests.
This makes some codegen tests more verbose since they now need to
explicitly introduce `MSVC`/`NONMSVC` revisions, but I think that's
less surprising, e.g.:
```rs
//@ revisions: MSVC NONMSVC
//`@[MSVC]` only-msvc
//`@[NONMSVC]` ignore-msvc
```
Note that revisions are not *only* FileCheck prefixes in
FileCheck-based test suites, as they also can be used
to conditionally apply certain compiletest directives.
r? `@Zalathar` (or reroll a `r/? compiletest` reviewer)
try-job: x86_64-msvc
try-job: i686-msvc
try-job: x86_64-mingw-1
try-job: i686-mingw
This was fragile as it was based on host target passed to compiletest,
but the user could cross-compile and run test for a different target
(e.g. cross from linux to msvc, but msvc won't be set on the target).
Furthermore, it was also very surprising as normally revision names
(other than `CHECK`) was accepted as FileCheck prefixes.
Variants::Single: do not use invalid VariantIdx for uninhabited enums
~~Stacked on top of https://github.com/rust-lang/rust/pull/133681, only the last commit is new.~~
Currently, `Variants::Single` for an empty enum contains a `VariantIdx` of 0; looking that up in the enum variant list will ICE. That's quite confusing. So let's fix that by adding a new `Variants::Empty` case for types that have 0 variants.
try-job: i686-msvc
cleanup region handling: add `LateParamRegionKind`
The second commit is to enable a split between `BoundRegionKind` and `LateParamRegionKind`, by avoiding `BoundRegionKind` where it isn't necessary.
The third comment then adds `LateParamRegionKind` to avoid having the same late-param region for separate bound regions. This fixes#124021.
r? `@compiler-errors`
The parser pushes a `TokenType` to `Parser::expected_token_types` on
every call to the various `check`/`eat` methods, and clears it on every
call to `bump`. Some of those `TokenType` values are full tokens that
require cloning and dropping. This is a *lot* of work for something
that is only used in error messages and it accounts for a significant
fraction of parsing execution time.
This commit overhauls `TokenType` so that `Parser::expected_token_types`
can be implemented as a bitset. This requires changing `TokenType` to a
C-style parameterless enum, and adding `TokenTypeSet` which uses a
`u128` for the bits. (The new `TokenType` has 105 variants.)
The new types `ExpTokenPair` and `ExpKeywordPair` are now arguments to
the `check`/`eat` methods. This is for maximum speed. The elements in
the pairs are always statically known; e.g. a
`token::BinOp(token::Star)` is always paired with a `TokenType::Star`.
So we now compute `TokenType`s in advance and pass them in to
`check`/`eat` rather than the current approach of constructing them on
insertion into `expected_token_types`.
Values of these pair types can be produced by the new `exp!` macro,
which is used at every `check`/`eat` call site. The macro is for
convenience, allowing any pair to be generated from a single identifier.
The ident/keyword filtering in `expected_one_of_not_found` is no longer
necessary. It was there to account for some sloppiness in
`TokenKind`/`TokenType` comparisons.
The existing `TokenType` is moved to a new file `token_type.rs`, and all
its new infrastructure is added to that file. There is more boilerplate
code than I would like, but I can't see how to make it shorter.
Use field init shorthand where possible
Field init shorthand allows writing initializers like `tcx: tcx` as
`tcx`. The compiler already uses it extensively. Fix the last few places
where it isn't yet used.
EDIT: this PR also updates `rustfmt.toml` to set
`use_field_init_shorthand = true`.
Overhaul keyword handling
The compiler's list of keywords has some problems.
- It contains several items that aren't keywords.
- The order isn't quite right in a couple of places.
- Some of the names of predicates relating to keywords are confusing.
- rustdoc and rustfmt have their own (incorrect) versions of the keyword list.
- `AllKeywords` is unnecessarily complex.
r? ```@jieyouxu```
`rustc_symbol` is the source of truth for keywords.
rustdoc has its own implicit definition of keywords, via the
`is_doc_keyword`. It (presumably) intends to include all keywords, but
it omits `yeet`.
rustfmt has its own explicit list of Rust keywords. It also (presumably)
intends to include all keywords, but it omits `await`, `builtin`, `gen`,
`macro_rules`, `raw`, `reuse`, `safe`, and `yeet`. Also, it does linear
searches through this list, which is inefficient.
This commit fixes all of the above problems by introducing a new
predicate `is_any_keyword` in rustc and using it in rustdoc and rustfmt.
It documents that it's not the right predicate in most cases.
Update cargo
6 commits in 769f622e12db0001431d8ae36d1093fb8727c5d9..99dff6d77db779716dda9ca3b29c26addd02c1be
2024-12-14 04:27:35 +0000 to 2024-12-18 00:55:17 +0000
- fix(build-std): make Resolve align to what to build (rust-lang/cargo#14938)
- test(build-std): Isolate output test to avoid spurious `[BLOCKING]` messages from concurrent runs (rust-lang/cargo#14943)
- docs: fix wrong changelog PR link (rust-lang/cargo#14947)
- docs(unstable): Correct stabilization version for MSRV-resolver (rust-lang/cargo#14945)
- Update release information for home 0.5.11 (rust-lang/cargo#14939)
- Limit release trigger to 0.* tags (rust-lang/cargo#14940)
Because `TokenStreamIter` is a much better name for a `TokenStream`
iterator. Also rename the `TokenStream::trees` method as
`TokenStream::iter`, and some local variables.
As it happens, lookahead values of 0, 1, and 2 all work fine here, due
to the structure of the code. (Values or 3 or greater cause test
failures.) This commit changes the lookahead to zero because that will
facilitate cleanups in subsequent commits.
Field init shorthand allows writing initializers like `tcx: tcx` as
`tcx`. The compiler already uses it extensively. Fix the last few places
where it isn't yet used.
Promote powerpc64le-unknown-linux-musl to tier 2 with host tools
MCP: https://github.com/rust-lang/compiler-team/issues/803
I'm using crosstool-ng for building a toolchain because GCC 9 from `musl-toolchain.sh` has float ABI issues (?) and can't compile LLVM, and writing a crosstool-ng config for a target feels less hacky than yet another target specific shell script. I also defined a kernel version, since there wasn't one specified before. If a lower version is desired, just let me know. I also tried to match the rust configure args with the loongarch64 musl tier 2 target.
The resulting compiler works fine, built with `DEPLOY=1 ./src/ci/docker/run.sh dist-powerpc64le-linux` and tested on Alpine Linux in a VM and on a bare metal POWER8 machine:
```
qemu-ppc64le:/tmp/rust-nightly-powerpc64le-unknown-linux-musl$ ash install.sh
install: creating uninstall script at /usr/local/lib/rustlib/uninstall.sh
install: installing component 'rustc'
install: installing component 'rust-std-powerpc64le-unknown-linux-musl'
install: installing component 'cargo'
install: installing component 'rustfmt-preview'
install: installing component 'rls-preview'
install: installing component 'rust-analyzer-preview'
install: installing component 'llvm-tools-preview'
install: installing component 'clippy-preview'
install: installing component 'miri-preview'
install: installing component 'rust-analysis-powerpc64le-unknown-linux-musl'
install: installing component 'llvm-bitcode-linker-preview'
install: WARNING: failed to run ldconfig. this may happen when not installing as root. run with --verbose to see the error
rust installed.
qemu-ppc64le:~$ echo 'fn main() { println!("hello world"); }' > test.rs
qemu-ppc64le:~$ rustc test.rs
qemu-ppc64le:~$ ./test
hello world
qemu-ppc64le:~$ file test
test: ELF 64-bit LSB executable, 64-bit PowerPC or cisco 7500, OpenPOWER ELF V2 ABI, version 1 (SYSV), statically linked, BuildID[sha1]=596ee6abf9add487ebc54fb71c2076fb6faea013, with debug_info, not stripped
```
try-job: dist-powerpc64le-linux
Split up attribute parsing code and move data types to `rustc_attr_data_structures`
This change renames `rustc_attr` to `rustc_attr_parsing`, and splits up the parsing code. At the same time, all the data types used move to `rustc_attr_data_structures`. This is in preparation of also having a third crate: `rustc_attr_validation`
I initially envisioned this as two separate PRs, but I think doing it in one go reduces the number of ways others would have to rebase their changes on this. However, I can still split them.
r? `@oli-obk` (we already discussed how this is a first step in a larger plan)
For a more detailed plan on how attributes are going to change, see https://github.com/rust-lang/rust/issues/131229
Edit: this looks like a giant PR, but the changes are actually rather trivial. Each commit is reviewable on its own, and mostly moves code around. No new logic is added.
The reason I did this is because I plan to add another field to this struct (indicating whether the item was cfg'ed out), but it seems worthy even separately and removes a bunch of one-letter variable names and tuple-indexing. It is also easy to separate from future changes, so it will be easier to review this way.
