Re-export more `rustc_span::symbol` things from `rustc_span`.
`rustc_span::symbol` defines some things that are re-exported from `rustc_span`, such as `Symbol` and `sym`. But it doesn't re-export some closely related things such as `Ident` and `kw`. So you can do `use rustc_span::{Symbol, sym}` but you have to do `use rustc_span::symbol::{Ident, kw}`, which is inconsistent for no good reason.
This commit re-exports `Ident`, `kw`, and `MacroRulesNormalizedIdent`, and changes many `rustc_span::symbol::` qualifiers to `rustc_span::`. This is a 300+ net line of code reduction, mostly because many files with two `use rustc_span` items can be reduced to one.
r? `@jieyouxu`
`rustc_span::symbol` defines some things that are re-exported from
`rustc_span`, such as `Symbol` and `sym`. But it doesn't re-export some
closely related things such as `Ident` and `kw`. So you can do `use
rustc_span::{Symbol, sym}` but you have to do `use
rustc_span::symbol::{Ident, kw}`, which is inconsistent for no good
reason.
This commit re-exports `Ident`, `kw`, and `MacroRulesNormalizedIdent`,
and changes many `rustc_span::symbol::` qualifiers in `compiler/` to
`rustc_span::`. This is a 200+ net line of code reduction, mostly
because many files with two `use rustc_span` items can be reduced to
one.
Rollup of 7 pull requests
Successful merges:
- #133265 (Add a range argument to vec.extract_if)
- #133801 (Promote powerpc64le-unknown-linux-musl to tier 2 with host tools)
- #134323 (coverage: Dismantle `map_data.rs` by moving its responsibilities elsewhere)
- #134378 (An octuple of polonius fact generation cleanups)
- #134408 (Regression test for RPIT inheriting lifetime from projection)
- #134423 (bootstrap: use specific-purpose ui test path for `test_valid` self-test)
- #134426 (Fix typo in uint_macros.rs)
Failed merges:
- #133103 (Pass FnAbi to find_mir_or_eval_fn)
r? `@ghost`
`@rustbot` modify labels: rollup
bootstrap: use specific-purpose ui test path for `test_valid` self-test
I wanted to move some ui tests around in #134418, which broke `test_valid` since it was referencing two non-specific-purpose ui tests. This PR instead adds two dummy tests under `tests/ui/bootstrap/self-test/`, for that purpose specifically.
r? bootstrap
An octuple of polonius fact generation cleanups
This PR is extracted from https://github.com/rust-lang/rust/pull/134268 for easier review and contains its first 8 commits. They have already been reviewed by ````@jackh726```` over there.
r? ````@jackh726````
coverage: Dismantle `map_data.rs` by moving its responsibilities elsewhere
This is a series of incremental changes that combine to let us get rid of `coverageinfo/map_data.rs`, by moving all of its responsibilities into more appropriate places.
Some of the notable consequences are:
- We once again build the per-CGU file table on the fly while preparing individual covfun records, instead of building the whole table up-front. The up-front approach was introduced by #117042 to work around various other problems in generating the covmap/covfun records, but subsequent cleanups have made that approach no longer necessary.
- Expression conversion and mapping-region conversion are now performed directly in `mapgen::covfun`, which should make future changes easier.
- We no longer insert unused function instances into the same map that is also used to track used function instances. This helps to decouple the handling of used vs unused functions.
---
There should be no meaningful change to compiler output. The file table is no longer sorted, because reordering it would invalidate the file indices stored in individual covfun records, but the table order should still be deterministic (albeit arbitrary).
There are some subsequent cleanups that I intend to investigate, but this is enough change for one PR.
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.
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.
This patch dismantles what was left of `FunctionCoverage` in `map_data.rs`,
replaces `function_coverage_map` with a set, and overhauls how we prepare
covfun records for unused functions.
`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>
The checks in `is_eligible_for_coverage` include `is_fn_like`, but will also
exclude various function-like things that cannot possibly have coverage
instrumentation.
