Rename `elem_offset` to `element_offset`
Tracking issue: #126769
Renames `slice::elem_offset` to `slice::element_offset` and improves the documentation of it and its related methods.
The current documentation can be misinterpreted (as explained [here](https://github.com/rust-lang/rust/issues/126769#issuecomment-2453363897)).
docs: Mention `spare_capacity_mut()` in `Vec::set_len`
I recently went down a small rabbit hole when trying to identify safe use of `Vec::set_len`. The solution was `Vec::spare_capacity_mut`. I think the docs on `Vec::set_len` benefit from mentioning this method.
A possible counter-argument could be that the [clippy lint `uninit_vec`](https://rust-lang.github.io/rust-clippy/master/index.html#/uninit_vec) already nudges people in the right direction. However, I think a working example on `Vec::set_len` is still beneficial.
Happy to hear your thoughts on the matter. 😊
Speed up `Parser::expected_tokens`
The constant pushing/clearing of `Parser::expected_tokens` during parsing is slow. This PR speeds it up greatly.
r? `@estebank`
Make sure we handle `backwards_incompatible_lint` drops appropriately in drop elaboration
In #131326, a new kind of scheduled drop (`drop_kind: DropKind::Value` + `backwards_incompatible_lint: true`) was added so that we could insert a new kind of no-op MIR statement (`backward incompatible drop`) for linting purposes.
These drops were intended to have *no side-effects*, but drop elaboration code forgot to handle these drops specially and they were handled otherwise as normal drops in most of the code. This ends up being **unsound** since we insert more than one drop call for some values, which means that `Drop::drop` could be called more than once.
This PR fixes this by splitting out the `DropKind::ForLint` and adjusting the code. I'm not totally certain if all of the places I've adjusted are either reachable or correct, but I'm pretty certain that it's *more* correct than it was previously.
cc `@dingxiangfei2009`
r? nikomatsakis
Fixes#134482
Remove a duplicated check that doesn't do anything anymore.
fixes#134005
This code didn't actually `lub` the type of the previous expressions, but just the current type over and over again. Changing it to using the actual expression type does not change anything either, so may as well remove the entire loop.
coverage: Store coverage source regions as `Span` until codegen (take 2)
This is an attempt to re-land #133418:
> Historically, coverage spans were converted into line/column coordinates during the MIR instrumentation pass.
> This PR moves that conversion step into codegen, so that coverage spans spend most of their time stored as Span instead.
> In addition to being conceptually nicer, this also reduces the size of coverage mappings in MIR, because Span is smaller than 4x u32.
That PR was reverted by #133608, because in some circumstances not covered by our test suite we were emitting coverage metadata that was causing `llvm-cov` to exit with an error (#133606).
---
The implementation here is *mostly* the same, but adapted for subsequent changes in the relevant code (e.g. #134163).
I believe that the changes in #134163 should be sufficient to prevent the problem that required the original PR to be reverted. But I haven't been able to reproduce the original breakage in a regression test, and the `llvm-cov` error message is extremely unhelpful, so I can't completely rule out the possibility of this breaking again.
r? jieyouxu (reviewer of the original PR)
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.
Some destructor/drop related tweaks
Two random tweaks I got from investigating some stuff around drops in edition 2024:
1. Use the `TypingEnv` of the mir builder, rather than making it over again.
2. Rename the `id` field from `Scope` to `local_id`, to reflect that it's a local id, and remove the `item_local_id()` accessor which just returned the id field.
Forbid overwriting types in typeck
While trying to figure out some type setting logic in https://github.com/rust-lang/rust/pull/134248 I realized that we sometimes set a type twice. While hopefully that would have been the same type, we didn't ensure that at all and just silently accepted it. So now we reject setting it twice, unless errors are happening, then we don't care.
Best reviewed commit by commit.
No behaviour change is intended.
reduce compiler `Assemble` complexity
`compile::Assemble` is already complicated by its nature (as it handles core internals like recursive building logic, etc.) and also handles half of `LldWrapper` tool logic for no good reason since it should be done in the build step directly.
This change moves it there to reduce complexity of `compile::Assemble` logic.
Fix intra doc links not generated inside footnote definitions
Fixes#132208.
The problem was that we were running the `Footnote` "pass" before the `LinkReplacer` one. Sadly, the change is bigger than it should because we can't specialize the `Iterator` trait implementation, forcing me to add a new type to handle the other `Iterator` kind (the one which still has the `Range`).
r? ``@notriddle``
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`
In codegen, a used function with `FunctionCoverageInfo` but no mappings has
historically indicated a bug. However, that will no longer be the case after
moving some fallible span-processing steps into codegen.
Currently it relies on having the right integer for every variant, and
if you add a variant you need to adjust the integers for all subsequent
variants, which is a pain.
This commit introduces a match guard formulation that takes advantage of
the enum-to-integer conversion to avoid specifying the integer for each
variant. And it does this via a macro to avoid lots of boilerplate.
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.
This is a naming convention used in a handful of spots in the parser for
delimiters. It confused me when I first saw it a long time ago, and I've
never liked it. A web search says "Bra-ket notation" exists in linear
algebra but the terminology has zero prior use in a programming context,
as far as I can tell.
This commit changes it to `open`/`close`, which is consistent with the
rest of the compiler.
The most significant is `check_keyword`: it now only pushes to
`expected_token_types` if the keyword check fails, which matches how all
the other `check` methods work.
The remainder are just tweaks to make these methods more consistent with
each other.
Point at lint name instead of whole attr for gated lints
```
warning: unknown lint: `test_unstable_lint`
--> $DIR/warn-unknown-unstable-lint-inline.rs:4:10
|
LL | #![allow(test_unstable_lint, another_unstable_lint)]
| ^^^^^^^^^^^^^^^^^^
|
= note: the `test_unstable_lint` lint is unstable
= help: add `#![feature(test_unstable_lint)]` to the crate attributes to enable
= note: this compiler was built on YYYY-MM-DD; consider upgrading it if it is out of date
note: the lint level is defined here
--> $DIR/warn-unknown-unstable-lint-inline.rs:3:9
|
LL | #![warn(unknown_lints)]
| ^^^^^^^^^^^^^
warning: unknown lint: `test_unstable_lint`
--> $DIR/warn-unknown-unstable-lint-inline.rs:4:29
|
LL | #![allow(test_unstable_lint, another_unstable_lint)]
| ^^^^^^^^^^^^^^^^^^^^^
|
= note: the `another_unstable_lint` lint is unstable
= help: add `#![feature(another_unstable_lint)]` to the crate attributes to enable
= note: this compiler was built on YYYY-MM-DD; consider upgrading it if it is out of date
```
This is particularly relevant when there are multiple lints in the same `warn` attribute. Pointing at the smaller span makes it clearer which one the warning is complaining about.
Advent of `tests/ui` (misc cleanups and improvements) [3/N]
Part of #133895.
Misc improvements to some ui tests immediately under `tests/ui/`.
Best reviewed commit-by-commit. Each commit's commit message contains further elaboration and rationale for changes.
r? compiler
Update books
## rust-lang/book
21 commits in 9900d976bbfecf4e8124da54351a9ad85ee3c7f3..ad2011d3bcad9f152d034faf7635c22506839d58
2024-12-16 16:11:34 UTC to 2024-12-05 19:19:24 UTC
- Ch. 10: clarify note about compiler errors and `'static` (rust-lang/book#4164)
- Introduce `let`-`else` statement (rust-lang/book#3702)
- Fix misleading explanation of comma in `$(),*` (rust-lang/book#3800)
- ch18-03: Matching Named Variables: mention `if let`/`while let` (rust-lang/book#3110)
- Ch. 4: Rephrase/clarify paragraph on reference scope (rust-lang/book#3688)
- Simplify note about functions in ch13-01-closures.md (rust-lang/book#3699)
- fix: make the reason more understandable (rust-lang/book#4074)
- Fixed grammatical error in the comment on line 22 (rust-lang/book#3180)
- ch17-02: Monomorphization applies to generics in general (rust-lang/book#3367)
- Ch. 21: Use `Vec::drain` to teach alternatives to `Option` (rust-lang/book#4159)
- fix(typo): correct punctuation in ch15-06-reference-cycles.md (rust-lang/book#4155)
- Ch. 20: show both `impl Fn` and `Box<dyn Fn>` (rust-lang/book#4152)
- Add `use super::*;` to unit-test examples. (rust-lang/book#4151)
- Remove emphasis on four-space indents (rust-lang/book#4150)
- Fix `.git-blame-ignore-revs` file (rust-lang/book#4149)
- Rust 2024: distinguish `unsafe fn` vs. `unsafe` blocks (rust-lang/book#4148)
- Update README.md typo (rust-lang/book#4146)
- Ch. 15.5: account for improved error message (rust-lang/book#4142)
- Document use of rustfmt and dprint for formatting (rust-lang/book#4138)
- tools: fix nostarch build reference to mdbook-trpl (rust-lang/book#4137)
- Revise sentence to not refer to two subjects as it (rust-lang/book#4136)
## edition-guide
6 commits in 128669297c8a7fdf771042eaec18b8adfaeaf0cd..bc4ce51e1d4dacb9350a92e95f6159a42de2f8c6
2024-12-03 22:02:43 +0000 to 2024-12-18 05:34:59 +0000
- Add chapter for 2024 match ergonomics reservations (rust-lang/edition-guide#349)
- Re-title "Additions to the prelude" (rust-lang/edition-guide#348)
- Show tail expression temporary example that fails in 2024 (rust-lang/edition-guide#345)
- Add more triagebot labeling support (rust-lang/edition-guide#346)
- 2024: Assignment operator RHS indentation (rust-lang/edition-guide#341)
- 2024: Add chapter on single-line `where` clauses (rust-lang/edition-guide#340)
## rust-lang/nomicon
1 commits in 0674321898cd454764ab69702819d39a919afd68..97e84a38c94bf9362b11284c20b2cb4adaa1e868
2024-12-10 02:41:27 UTC to 2024-12-10 02:41:27 UTC
- races.md: data race -> race condition to violate memory safety (rust-lang/nomicon#470)
## reference
8 commits in ede56d1bbe132bac476b5029cd6d7508ca9572e9..9f41bc11342d46544ae0732caf14ec0bcaf27376
2024-12-03 22:26:55 +0000 to 2024-12-18 23:04:30 +0000
- `coverage` attribute (rust-lang/reference#1628)
- Clarify that `extern crate foo as føø` is allowed (rust-lang/reference#1697)
- Fix rule auto-linking on Windows (rust-lang/reference#1698)
- Reflect rust#133422 & rust#133587 to inline assembly documentation (rust-lang/reference#1695)
- Describe async closures (rust-lang/reference#1692)
- Update closures for edition 2021 disjoint closure capturing (rust-lang/reference#1521)
- Fix paragraphs with trailing `\1` (rust-lang/reference#1696)
- Add triagebot autolabel (rust-lang/reference#1694)
## rust-lang/rust-by-example
1 commits in e1d1f2cdcee4d52b9a01ff7c448be4372a377b70..76406337f4131253443aea0ed7e7f451b464117c
2024-12-07 00:24:30 UTC to 2024-12-07 00:24:30 UTC
- Fix#1900 (rust-lang/rust-by-example#1901)
## rust-lang/rustc-dev-guide
9 commits in b21d99b770f9aceb0810c843847c52f86f45d2ed..7f7ba48f04abc2ad25e52f30b5e2bffa286b019f
2024-12-16 07:12:01 UTC to 2024-12-05 05:01:46 UTC
- Specify what a CGU is (rust-lang/rustc-dev-guide#2163)
- functionality removed from codebase (part 2) (rust-lang/rustc-dev-guide#2160)
- functionality removed from codebase (rust-lang/rustc-dev-guide#2159)
- remove polymorphization (rust-lang/rustc-dev-guide#2158)
- squashing: recommend --keep-base when squashing without a conflict (rust-lang/rustc-dev-guide#2157)
- update section even more (rust-lang/rustc-dev-guide#2156)
- extend closure constraints section (rust-lang/rustc-dev-guide#2155)
- Remove `//@ compare-output-lines-by-subset` directive (rust-lang/rustc-dev-guide#2151)
- Document `needs-target-has-atomic` directive (rust-lang/rustc-dev-guide#2154)
-Znext-solver: modify candidate preference rules
This implements the design proposed in the FCP in #132325 and matches the old solver behavior. I hope the inline comments are all sufficiently clear, I personally think this is a fairly clear improvement over the existing approach using `fn discard_impls_shadowed_by_env`. This fixes https://github.com/rust-lang/trait-system-refactor-initiative/issues/96.
This also fixes#133639 which encounters an ICE in negative coherence when evaluating the where-clause. Given the features required to trigger this ICE 🤷
r? ``@compiler-errors``
Stabilize `#[diagnostic::do_not_recommend]`
This PR seeks to stabilize the `#[diagnostic::do_not_recommend]`attribute.
This attribute was first proposed as `#[do_not_recommend`] attribute in RFC 2397 (https://github.com/rust-lang/rfcs/pull/2397). It gives the crate authors the ability to not suggest to the compiler to not show certain traits in its error messages.
With the presence of the `#[diagnostic]` tool attribute namespace it was decided to move the attribute there, as that lowers the amount of guarantees the compiler needs to give about the exact way this influences error messages. It turns the attribute into a hint which can be ignored. In addition to the original proposed functionality this attribute now also hides the marked trait in help messages ("This trait is implemented by: ").
The attribute does not accept any argument and can only be placed on trait implementations. If it is placed somewhere else a lint warning is emitted and the attribute is otherwise ignored. If an argument is detected a lint warning is emitted and the argument is ignored. This follows the rules outlined by the diagnostic namespace.
This attribute allows crates like diesel to improve their error messages drastically. The most common example here is the following error message:
```
error[E0277]: the trait bound `&str: Expression` is not satisfied
--> /home/weiznich/Documents/rust/rust/tests/ui/diagnostic_namespace/do_not_recommend.rs:53:15
|
LL | SelectInt.check("bar");
| ^^^^^ the trait `Expression` is not implemented for `&str`, which is required by `&str: AsExpression<Integer>`
|
= help: the following other types implement trait `Expression`:
Bound<T>
SelectInt
note: required for `&str` to implement `AsExpression<Integer>`
--> /home/weiznich/Documents/rust/rust/tests/ui/diagnostic_namespace/do_not_recommend.rs:26:13
|
LL | impl<T, ST> AsExpression<ST> for T
| ^^^^^^^^^^^^^^^^ ^
LL | where
LL | T: Expression<SqlType = ST>,
| ------------------------ unsatisfied trait bound introduced here
```
By applying the new attribute to the wild card trait implementation of
`AsExpression` for `T: Expression` the error message becomes:
```
error[E0277]: the trait bound `&str: AsExpression<Integer>` is not satisfied
--> $DIR/as_expression.rs:55:15
|
LL | SelectInt.check("bar");
| ^^^^^ the trait `AsExpression<Integer>` is not implemented for `&str`
|
= help: the trait `AsExpression<Text>` is implemented for `&str`
= help: for that trait implementation, expected `Text`, found `Integer`
```
which makes it much easier for users to understand that they are facing a type mismatch.
Other explored example usages include:
* This standard library error message: https://github.com/rust-lang/rust/pull/128008
* That bevy derived example:
e1f3068995/tests/ui/diagnostic_namespace/do_not_recommend/supress_suggestions_in_help.rs (No
more tuple pyramids)
Fixes#51992
r? ``@compiler-errors``
This PR also adds a few more tests, makes sure that all the tests are run for the old and new trait solver and adds a check that the attribute does not contain arguments.
ci: Move dist-aarch64-linux to an aarch64 runner
Move the dist-aarch64-linux CI job to an aarch64 runner instead of cross-compiling it from an x86 one. This will make it possible to perform optimisations such as LTO, PGO and BOLT later on.
r? `@Kobzol`
try-job: dist-aarch64-linux
try-job: dist-x86_64-linux
try-job: dist-i686-linux
