- Move it to `rustc_parse`, which is the only crate that uses it. This
lets us remove all the `pub` markers from it.
- Change `next_ref` and `look_ahead` to `get` and `bump`, which work
better for the `rustc_parse` uses.
- This requires adding a `TokenStream::get` method, which is simple.
- In `TokenCursor`, we currently duplicate the
`DelimSpan`/`DelimSpacing`/`Delimiter` from the surrounding
`TokenTree::Delimited` in the stack. This isn't necessary so long as
we don't prematurely move past the `Delimited`, and is a small perf
win on a very hot code path.
- In `parse_token_tree`, we clone the relevant `TokenTree::Delimited`
instead of constructing an identical one from pieces.
Currently there are two ways to peek at a `TokenStreamIter`.
- Wrap it in a `Peekable` and use that traits `peek` method.
- Use `TokenStreamIter`'s inherent `peek` method.
Some code uses one, some use the other. This commit converts all places
to the inherent method. This eliminates mixing of `TokenStreamIter` and
`Peekable<TokenStreamIter>` and some use of `impl Iterator` and `dyn
Iterator`.
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.
bootstrap: fix a comment
I don't actually know if this is right, though... but "a single call to `paths` will only ever generate a single call to `paths`" just does not make sense.
Fix some comments related to upvars handling
I'm tidying up my ergonomic ref counting PR and I'm going to make some small, simple and unrelated changes outside that PR, so the main PR sticks more straight to the point.
rustc_borrowck: Suggest changing `&raw const` to `&raw mut` if applicable
Closes#127562
For reference, here is the diff compared to the original error reported in that issue before #134244 stopped suggesting the invalid syntax:
```
diff --git a/tests/ui/borrowck/no-invalid-mut-suggestion-for-raw-pointer-issue-127562.stderr b/tests/ui/borrowck/no-invalid-mut-suggestion-for-raw-pointer-issue-127562.stderr
index 0da5d15cf7f..dbe834b6b78 100644
--- a/tests/ui/borrowck/no-invalid-mut-suggestion-for-raw-pointer-issue-127562.stderr
+++ b/tests/ui/borrowck/no-invalid-mut-suggestion-for-raw-pointer-issue-127562.stderr
``@@`` -6,8 +6,8 ``@@`` LL | unsafe { *ptr = 3; }
|
help: consider changing this to be a mutable pointer
|
-LL | let ptr = &mut raw const val;
- | +++
+LL | let ptr = &raw mut val;
+ | ~~~
error: aborting due to 1 previous error
```
Use links to edition guide for edition migrations
This switches the migration lints for the 2024 edition to point to the edition guide documentation instead of the tracking issues. I expect the documentation should be easier to understand for a user, compared to most of the issues which don't have any direct information, and can be a bit confusing to navigate, or have outdated information.
Rename `rustc_mir_build::build` to `builder`
GitHub's “Go to file” feature silently ignores all files in this module, presumably because they are in a directory named `build`, which is mistaken for a build-output directory. That makes it meaningfully harder to view those files and their history via GitHub.
This PR sidesteps that issue by renaming `build` to `builder`, which in context has basically the same meaning, but can't be mistaken for a build-output directory.
---
Extracted from #133404, after #133592 changed the .gitignore rule from `build/` to `/build`. The problem of GitHub ignoring these files still exists even after that change, which suggests that GitHub's behaviour is a hard-coded heuristic that isn't influenced by the repository's git settings.
Currently this PR doesn't include the tidy rule forbidding `build` as a module name, but that could be added if people think it's a good idea.
Handle fndef rendering together with signature rendering
Pulled out of https://github.com/rust-lang/rust/pull/134353
Changes some highlighting in type mismatch errors around fndefs
rework winnowing to sensibly handle global where-bounds
There may be multiple ways to prove a given trait-bound. In case there are multiple such applicable candidates we need to somehow merge them or bail with ambiguity. When merging candidates we prefer some over others for multiple reasons:
- we want to guide inference during typeck, even if not strictly necessary
- to avoid ambiguity if there if there are at most lifetime differences
- old solver needs exactly one candidate
- new solver only needs to handle lifetime differences
- we disable normalization via impls if the goal is proven by using a where-bound
## The approach in this PR[^1]
- always prefer trivial builtin impls[^6]
- then prefer non-global[^global] where-bounds
- if there exists exactly one where-bound, guide inference
- if there are multiple where-bounds even if some of them are global, ambig
- then prefer alias bounds[^2] and builtin trait object candidates[^3][^2]
- merge everything ignoring global where-bounds
- if there are no other candidates, try using global where-bounds[^5]
**We disable normalization via impls when using non-global where-bounds or alias-bounds, even if we're unable to normalize by using the where-bound.**
[^1]: see the source for more details
[^2]: [we arbitrary select a single object and alias-bound candidate in case multiple apply and they don't impact inference](a4cedecc9e/compiler/rustc_trait_selection/src/traits/select/mod.rs (L1906-L1911)). This should be unnecessary in the new solver.
[^3]: Necessary for `dyn Any` and https://github.com/rust-lang/rust/issues/57893
[^global]: a where-bound is global if it is not higher-ranked and doesn't contain any generic parameters, `'static` is ok
[^5]: global where-bounds are only used if they are unsatisfiable, i.e. no impl candidate exists
[^6]: they don't constrain inference and don't add any lifetime constraints
## Why this behavior?
### inference guidance via where-bounds and alias-bounds
#### where-bounds
```rust
fn method_selection<T: Into<u64>>(x: T) -> Option<u32> {
x.into().try_into().ok()
// prove `T: Into<?0>` and then select a method `?0`,
// needs eager inference.
}
```
While the above pattern exists in the wild, I think that most inference guidance due to where-bounds is actually unintended. I believe we may want to restrict inference guidance in the future, e.g. limit it to where-bounds whose self-type is a param.
#### alias-bounds
```rust
pub trait Dyn {
type Word: Into<u64>;
fn d_tag(&self) -> Self::Word;
fn tag32(&self) -> Option<u32> {
self.d_tag().into().try_into().ok()
// prove `Self::Word: Into<?0>` and then select a method
// on `?0`, needs eager inference.
}
}
```
### Disable normalization via impls when using where-bounds
cc https://github.com/rust-lang/trait-system-refactor-initiative/issues/125
```rust
trait Trait<'a> {
type Assoc;
}
impl<T> Trait<'static> for T {
type Assoc = ();
}
// normalizing requires `'a == 'static`, the trait bound does not.
fn foo<'a, T: Trait<'a>>(_: T::Assoc) {}
```
If an impl adds constraints not required by a where-bound, using the impl may cause compilation failure avoided by treating the associated type as rigid.
This is also why we can always use trivial builtin impls, even for normalization. They are guaranteed to never add any requirements.
### Lower priority for global where-bounds
A where-bound is considered global if it does not refer to any generic parameters and is not higher-ranked. It may refer to `'static`.
This means global where-bounds are either always fully implied by an impl or unsatisfiable. We don't really care about the inference behavior of unsatisfiable where-bounds :3
If a where-bound is fully implied then using an applicable impl for normalization cannot result in additional constraints. As this is the - afaict only - reason why we disable normalization via impls in the first place, we don't have to disable normalization via impls when encountering global where-bounds.
### Consider global where-bounds at all
Given that we just use impls even if there exists a global where-bounds, you may ask why we don't just ignore these global where-bounds entirely: we use them to weaken the inference guidance from non-global where-bounds.
Without a global where-bound, we currently prefer non-global where bounds even though there would be an applicable impl as well. By adding a non-global where-bound, this *unnecessary* inference guidance is disabled, allowing the following to compile:
```rust
fn check<Color>(color: Color)
where
Vec: Into<Color> + Into<f32>,
{
let _: f32 = Vec.into();
// Without the global `Vec: Into<f32>` bound we'd
// eagerly use the non-global `Vec: Into<Color>` bound
// here, causing this to fail.
}
struct Vec;
impl From<Vec> for f32 {
fn from(_: Vec) -> Self {
loop {}
}
}
```
[There exist multiple crates which rely on this behavior](https://github.com/rust-lang/rust/pull/124592#issuecomment-2104541495).
## Design considerations
We would like to be able to normalize via impls as much as possible. Disabling normalization simply because there exists a where-bound is undesirable.
For the sake of backwards compatability I intend to mostly mirror the current inference guidance rules and then explore possible improvements once the new solver is done. I do believe that removing unnecessary inference guidance where possible is desirable however.
Whether a where-bound is global depends on whether used lifetimes are `'static`. The where-bound `u32: Trait<'static>` is either entirely implied by an impl, meaning that it does not have to disable normalization via impls, **while `u32: Trait<'a>` needs to disable normalization via impls as the impl may only hold for `'static`**. Considering all where-bounds to be non-global once they contain any region is unfortunately a breaking change.
## How does this differ from stable
The currently stable approach is order dependent:
- it prefers impls over global where-bounds: impl > global
- it prefers non-global where-bounds over impls: non-global > impl
- it treats all where-bounds equally: global = non-global
This means that whether we bail with ambiguity or simply use the non-global where bound depending on the *order of where-clauses* and *number of applicable impl candidates*. See the tests added in the first commit for more details. With this PR we now always bail with ambiguity.
I've previously tried to always use the non-global candidate, causing unnecessary inference guidance and undesirable breakage. This already went through an FCP in #124592. However, I consider the new approach to be preferable as it exclusively removes incompleteness. It also doesn't cause any crater breakage.
## How to support this in the new solver :o
**This is separately implemented in #133643 and not part of this FCP!**
To implement the global vs non-global where-bound distinction, we have to either keep `'static` in the `param_env` when canonicalizing, or eagerly distinguish global from non-global where-bounds and provide that information to the canonical query.
The old solver currently keeps `'static` only the `param_env`, replacing it with an inference variable in the `value`.
a4cedecc9e/compiler/rustc_infer/src/infer/canonical/canonicalizer.rs (L49-L64)
I dislike that based on *vibes* and it may end up being a problem once we extend the environment inside of the solver as [we must not rely on `'static` in the `predicate` as it would get erased in MIR typeck](https://github.com/rust-lang/trait-system-refactor-initiative/issues/30).
An alternative would be to eagerly detect trivial where-bounds when constructing the `ParamEnv`. We can't entirely drop them [as explained above](https://hackmd.io/qoesqyzVTe2v9cOgFXd2SQ#Consider-true-global-where-bounds-at-all), so we'd instead replace them with a new clause kind `TraitImpliedByImpl` which gets entirely ignored except when checking whether we should eagerly guide inference via a where-bound. This approach can be extended to where-bounds which are currently not considered global to stop disabling normalization for them as well.
Keeping `'static` in the `param_env` is the simpler solution here and we should be able to move to the second approach without any breakage. I therefore propose to keep `'static` in the environment for now.
---
r? `@compiler-errors`
Remove queries from the driver interface
All uses of driver queries in the public api of rustc_driver have been removed in https://github.com/rust-lang/rust/pull/134130 already. This removes driver queries from rustc_interface and does a couple of cleanups around TyCtxt construction and entering enabled by this removal.
Finishes the removal of driver queries started with https://github.com/rust-lang/rust/pull/126834.
In #129533 the main hash function changed and the order of `-Z
input-stats` output changed, which showed that it is dependent on the
hash function, even though it is sorted. That's because entries with the
same cumulative size are ordered in a way that depends on the hash
function.
This commit fixes that by using the entry label as the secondary
ordering key.
`CheckAttrVisitor::check_doc_keyword` checks `#[doc(keyword = "..")]`
attributes to ensure they are on an empty module, and that the value is
a non-empty identifier.
The `rustc::existing_doc_keyword` lint checks these attributes to ensure
that the value is the name of a keyword.
It's silly to have two different checking mechanisms for these
attributes. This commit does the following.
- Changes `check_doc_keyword` to check that the value is the name of a
keyword (avoiding the need for the identifier check, which removes a
dependency on `rustc_lexer`).
- Removes the lint.
- Updates tests accordingly.
There is one hack: the `SelfTy` FIXME case used to used to be handled by
disabling the lint, but now is handled with a special case in
`is_doc_keyword`. That hack will go away if/when the FIXME is fixed.
Co-Authored-By: Guillaume Gomez <guillaume1.gomez@gmail.com>
Rollup of 9 pull requests
Successful merges:
- #134124 (CI: use free runners for x86_64-gnu-llvm jobs)
- #134197 (rustc_mir_build: Clarify that 'mirrored' does not mean 'flipped' or 'reversed')
- #134260 (Correctly handle comments in attributes in doctests source code)
- #134277 (rustdoc-search: handle `impl Into<X>` better)
- #134284 (Keep track of patterns that could have introduced a binding, but didn't)
- #134337 (reject unsound toggling of RISCV target features)
- #134371 (Check for array lengths that aren't actually `usize`)
- #134385 (tests/ui/asm: Remove uses of rustc_attrs, lang_items, and decl_macro features by using minicore)
- #134386 (Some trait method vs impl method signature difference diagnostic cleanups)
r? `@ghost`
`@rustbot` modify labels: rollup
Since the previos commit renamed `assignment_rhs_span` to just
`rhs_span` there is no need for a variable just to shorten the
expression on the next line. Inline the variable.
Some trait method vs impl method signature difference diagnostic cleanups
Just some things I noticed while debugging a weird diagnostic in https://github.com/rust-lang/rust/pull/134353
best reviewed commit by commit
Check for array lengths that aren't actually `usize`
I wish typeck wouldn't give us `ty::Array`s that have this problem in the first place, but we can check for it.
Fixes#134352
cc ``@matthiaskrgr``
reject unsound toggling of RISCV target features
~~Stacked on top of https://github.com/rust-lang/rust/pull/133417, only the last commit is new.~~
Works towards https://github.com/rust-lang/rust/issues/132618 (but more [remains to be done](https://github.com/rust-lang/rust/pull/134337#issuecomment-2544228958))
Part of https://github.com/rust-lang/rust/issues/116344
Cc ``@beetrees`` I hope I got everything. I didn't do anything about "The f and zfinx features are incompatible" and that's not an ABI thing (right?) and I am not sure how to handle it with these ABI checks.
r? ``@workingjubilee``
Ideally we'd also reject target specs that disable the `f` feature but set an ABI that requires `f`... but I don't want to duplicate this logic. I have some ideas for how maybe the entire float ABI check logic should be different, now that we have some examples of what these ABI checks look like, but that will be a future PR.
Keep track of patterns that could have introduced a binding, but didn't
When we recover from a pattern parse error, or a pattern uses `..`, we keep track of that and affect resolution error for missing bindings that could have been provided by that pattern. We differentiate between `..` and parse recovery. We silence resolution errors likely caused by the pattern parse error.
```
error[E0425]: cannot find value `title` in this scope
--> $DIR/struct-pattern-with-missing-fields-resolve-error.rs:18:30
|
LL | if let Website { url, .. } = website {
| ------------------- this pattern doesn't include `title`, which is available in `Website`
LL | println!("[{}]({})", title, url);
| ^^^^^ not found in this scope
```
Fix#74863.
rustdoc-search: handle `impl Into<X>` better
This PR fixes two bugs I ran into while searching the compiler docs:
- It omitted an `impl Trait` entry in the type signature field, producing `TyCtxt, , Symbol -> bool`
- It didn't let me search for `TyCtxt, DefId, Symbol -> bool` even though that's a perfectly good description of the function I was looking for (the function actually used `impl Into<DefId>`
r? ``@GuillaumeGomez`` cc ``@lolbinarycat``
Correctly handle comments in attributes in doctests source code
Fixes https://github.com/rust-lang/rust/issues/134221.
The problem was that attributes are "inlined" (backlines are stripped), then when there is an inline comment inside it, the attribute is never considered valid (since unclosed). Fix was to simply put back backlines in case it's a multiline attribute.
r? ``@notriddle``
