add `Cargo.lock` to CI-rustc allowed list for non-CI env
Changes to dependencies usually require modifying `Cargo.toml`, which would already invalidate the CI-rustc cache if done in non-allowed paths. On non-CI environment, it should be safe to add `Cargo.lock` to the list of allowed paths as there is no real risk aside from a very rare false positive in cases like minor bumps to non-allowed path dependencies without modifying the `Cargo.toml` files.
Fixesrust-lang/rust#141986
Run `calculate_matrix` job on `master` to cache citool builds
As discussed in https://rust-lang.zulipchat.com/#narrow/channel/242791-t-infra/topic/PR.20ci.20seems.20much.20to.20slow/with/523028903, the current `rust-cache` solution for `citool` doesn't work, because we don't ever write to the cache from `master`, so the cache is empty on PR CI jobs.
This PR runs the `calculate_matrix` job on `master`, with the only motivation to actually prime the cache.
r? `@marcoieni`
Simplify and optimize `VecCache`'s `SlotIndex::from_index`
Simplify and optimize `SlotIndex::from_index`
Break out bucket 0 (containing `idx < 4096`) as an early return, which
simplifies the remainder of the function, and allows optimizing the
`checked_ilog2` since it can no longer return `None`.
This reduces the runtime of `vec_cache::tests::slot_index_exhaustive`
(which calls `SlotIndex::from_index` for every `u32`, twice) from ~15.5s
to ~13.3s.
Separately, simplify the test case as well. (The old and new code passes with
the old and new test case.)
---
Noticed because `slot_index_exhaustive` stood out as taking unusually long compared to other tests, so I started investigating what it was doing.
Don't walk into `Certainty::Yes` goals
Don't walk into `Certainty::Yes` goals in the pending obligation finding code, since they will not have been stalled on an infer var anyways
Remove CollectItemTypesVisitor
I always felt like we were very unnecessarily walking the HIR, let's see if perf agrees
There is lots to ~~improve~~ consolidate further here, as we still have 3 item wfchecks:
* check_item (matching on the hir::ItemKind)
* actually doing trait solver based checks (by using HIR spans)
* lower_item (matching on the hir::ItemKind after loading it again??)
* just ensure_ok-ing a bunch of queries
* check_item_type (matching on DefKind)
* some type based checks, mostly ensure_ok-ing a bunch of queries
fixesrust-lang/rust#121429
Move coroutine_by_move_body_def_id into the big check_crate body owner loop
This avoids starting a parallel loop in sequence and instead runs all the queries for a specific DefId together.
bootstrap: build std sans leaf frame pointers
Sometimes leaf frame-pointers can impact LLVM inlining choices, and that can be a real problem for things like `mul_add`.
Fast path for stalled obligations on self ty
If we see that the `self` type of a goal is an infer var, then don't try to compute the goal at all, since we know that it'll be forced ambiguous.
This is currently only implemented when there are no opaques in the environment. We could extend it to check that the self type is not related to any already defined opaques via subtyping, but I'll leave that as a follow-up.
---
Also stall coerce and subtype predicates if both of their vars are not resolved to concrete types.
---
~~Also, we don't care if the goal is higher-ranked for the sized and copy/clone fast path.~~ pulling this out into another PR.
r? lcnr
modularize the config module bootstrap
Currently, our `config` module is quite large over 3,000 lines, and handles a wide range of responsibilities. This PR aims to break it down into smaller, more focused submodules to improve readability and maintainability:
* **`toml`**: Introduces a dedicated `toml` submodule within the `config` module. Its sole purpose is to define configuration-related structs along with their corresponding deserialization logic. It also contains the `parse_inner` method, which serves as the central function for extracting relevant information from the TOML structs and constructing the final configuration.
* **`rust`, `dist`, `install`, `llvm`, `build`, `gcc`, and others**: Each of these modules contains TOML subsections specific to their domain, along with the logic necessary to convert them into parts of the final configuration struct.
* **`config/mod.rs`**: Contains shared types and enums used across multiple TOML subsections.
* **`config/config.rs`**: Houses the logic that integrates all the TOML subsections into the complete configuration struct.
r? `@kobzol`
Add a new `mismatched-lifetime-syntaxes` lint
The lang-team [discussed this](https://hackmd.io/nf4ZUYd7Rp6rq-1svJZSaQ) and I attempted to [summarize](https://github.com/rust-lang/rust/pull/120808#issuecomment-2701863833) their decision. The summary-of-the-summary is:
- Using two different kinds of syntax for elided lifetimes is confusing. In rare cases, it may even [lead to unsound code](https://github.com/rust-lang/rust/issues/48686)! Some examples:
```rust
// Lint will warn about these
fn(v: ContainsLifetime) -> ContainsLifetime<'_>;
fn(&'static u8) -> &u8;
```
- Matching up references with no lifetime syntax, references with anonymous lifetime syntax, and paths with anonymous lifetime syntax is an exception to the simplest possible rule:
```rust
// Lint will not warn about these
fn(&u8) -> &'_ u8;
fn(&'_ u8) -> &u8;
fn(&u8) -> ContainsLifetime<'_>;
```
- Having a lint for consistent syntax of elided lifetimes will make the [future goal](https://github.com/rust-lang/rust/issues/91639) of warning-by-default for paths participating in elision much simpler.
---
This new lint attempts to accomplish the goal of enforcing consistent syntax. In the process, it supersedes and replaces the existing `elided-named-lifetimes` lint, which means it starts out life as warn-by-default.
jsondocck: Refactor directive handling
Best reviewed commit by commit.
1. Moves directive handling into its own file. This makes it easier to link to in the dev-guide (https://github.com/rust-lang/rustc-dev-guide/pull/2422#discussion_r2112724234), but also makes the code nicer in it's own right
2. Renames command to directive. This is what compiletest uses, and it's nice to not have 2 words for this.
r? ``@GuillaumeGomez``
`tests/ui`: A New Order [3/N]
Some `tests/ui/` housekeeping, to trim down number of tests directly under `tests/ui/`. Part of rust-lang/rust#133895.
r? ``@jieyouxu``
UnsafePinned: also include the effects of UnsafeCell
This tackles https://github.com/rust-lang/rust/issues/137750 by including an `UnsafeCell` in `UnsafePinned`, thus imbuing it with all the usual properties of interior mutability (no `noalias` nor `dereferenceable` on shared refs, special treatment by Miri's aliasing model). The soundness issue is not fixed yet because coroutine lowering does not use `UnsafePinned`.
The RFC said that `UnsafePinned` would not permit mutability on shared references, but since then, https://github.com/rust-lang/rust/issues/137750 has demonstrated that this is not tenable. In the face of those examples, I propose that we do the "obvious" thing and permit shared mutable state inside `UnsafePinned`. This seems loosely consistent with the fact that we allow going from `Pin<&mut T>` to `&T` (where the former can be aliased with other pointers that perform mutation, and hence the same goes for the latter) -- but the `as_ref` example shows that we in fact would need to add this `UnsafeCell` even if we didn't have a safe conversion to `&T`, since for the compiler and Miri, `&T` and `Pin<&T>` are basically the same type.
To make this possible, I had to remove the `Copy` and `Clone` impls for `UnsafePinned`.
Tracking issue: https://github.com/rust-lang/rust/issues/125735
Cc ``@rust-lang/lang`` ``@rust-lang/opsem`` ``@Sky9x``
I don't think this needs FCP since the type is still unstable -- we'll finally decide whether we like this approach when `UnsafePinned` is moved towards stabilization (IOW, this PR is reversible). However, I'd still like to make sure that the lang team is okay with the direction I am proposing here.
Move placeholder handling to a proper preprocessing step
This commit breaks out the logic of placheolder rewriting into its own preprocessing step. It's one of the more boring
parts of #130227.
The only functional change from this is that the preprocessing step (where extra `r: 'static` constraints are added) is performed upstream of Polonius legacy, finally affecting Polonius. That is mostly a by-product, though.
This should be reviewable by anyone in the compiler team, so
r? rust-lang/compiler
Merge `compiler-builtins` as a Josh subtree
Use the Josh [1] utility to add `compiler-builtins` as a subtree, which
will allow us to stop using crates.io for updates. This is intended to
help resolve some problems when unstable features change and require
code changes in `compiler-builtins`, which sometimes gets trapped in a
bootstrap cycle.
This was done using `josh-filter` built from the r24.10.04 tag:
git fetch https://github.com/rust-lang/compiler-builtins.git 233434412fe7eced8f1ddbfeddabef1d55e493bd
josh-filter ":prefix=library/compiler-builtins" FETCH_HEAD
git merge --allow-unrelated FILTERED_HEAD
The HEAD in the `compiler-builtins` repository is 233434412f ("fix an if
statement that can be collapsed").
[1]: https://github.com/josh-project/josh
Use ccache for stage0 tool builds
Now after the stage0 redesign, we can actually start ccaching the build of the compiler itself. We can also cache the bootstrap tools, since these are also built with the stage0 compiler.
Stage0 compiler builds are now being cached: https://github.com/rust-lang/rust/actions/runs/15397246267#summary-43321151192 (`..bootstrap::core::build_steps::compile::Rustc 483.10s 40.41s -91.6%`). It's not a gigantic win everywhere, but it should help. It seems to make the Linux jobs ~10 minute faster. It should be especially useful on PR builds after https://github.com/rust-lang/rust/pull/141948.
r? `@jieyouxu`
try-job: `x86_64-gnu-llvm-19*`
try-job: `x86_64-msvc*`
try-job: `x86_64-apple*`
try-job: `dist-x86_64-linux`
Laurențiu Nicola
bors
Matthias Krüger
Tshepang Mbambo
The rustc-dev-guide Cronjob Bot
León Orell Valerian Liehr
cyrgani
许杰友 Jieyou Xu (Joe)
Jieyou Xu
onur-ozkan
Rageking8