Remove `DefId` from `EarlyParamRegion`
Currently we represent usages of `Region` parameters via the `ReEarlyParam` or `ReLateParam` variants. The `ReEarlyParam` is effectively equivalent to `TyKind::Param` and `ConstKind::Param` (i.e. it stores a `Symbol` and a `u32` index) however it also stores a `DefId` for the definition of the lifetime parameter.
This was used in roughly two places:
- Borrowck diagnostics instead of threading the appropriate `body_id` down to relevant locations. Interestingly there were already some places that had to pass down a `DefId` manually.
- Some opaque type checking logic was using the `DefId` field to track captured lifetimes
I've split this PR up into a commit for generate rote changes to diagnostics code to pass around a `DefId` manually everywhere, and another commit for the opaque type related changes which likely require more careful review as they might change the semantics of lints/errors.
Instead of manually passing the `DefId` around everywhere I previously tried to bundle it in with `TypeErrCtxt` but ran into issues with some call sites of `infcx.err_ctxt` being unable to provide a `DefId`, particularly places involved with trait solving and normalization. It might be worth investigating adding some new wrapper type to pass this around everywhere but I think this might be acceptable for now.
This pr also has the effect of reducing the size of `EarlyParamRegion` from 16 bytes -> 8 bytes. I wouldn't expect this to have any direct performance improvement however, other variants of `RegionKind` over `8` bytes are all because they contain a `BoundRegionKind` which is, as far as I know, mostly there for diagnostics. If we're ever able to remove this it would shrink the `RegionKind` type from `24` bytes to `12` (and with clever bit packing we might be able to get it to `8` bytes). I am curious what the performance impact would be of removing interning of `Region`'s if we ever manage to shrink `RegionKind` that much.
Sidenote: by removing the `DefId` the `Debug` output for `Region` has gotten significantly nicer. As an example see this opaque type debug print before vs after this PR:
`Opaque(DefId(0:13 ~ impl_trait_captures[aeb9]::foo::{opaque#0}), [DefId(0:9 ~ impl_trait_captures[aeb9]::foo::'a)_'a/#0, T, DefId(0:9 ~ impl_trait_captures[aeb9]::foo::'a)_'a/#0])`
`Opaque(DefId(0:13 ~ impl_trait_captures[aeb9]::foo::{opaque#0}), ['a/#0, T, 'a/#0])`
r? `@compiler-errors` (I would like someone who understands the opaque type setup to atleast review the type system commit, but the rest is likely reviewable by anyone)
If a const function is unstable overall (and thus, in all circumstances
I know of, also const-unstable), we should show the option to use it as
const. You need to enable a feature to use the function at all anyway.
If the function is stabilized without also being const-stabilized, then
we do not show the const keyword and instead show "const: unstable" in
the version info.
Try to not reinstall tools in mingw CI
Reinstalling the tools seems prone to failure (e.g. [latest](https://github.com/rust-lang/rust/pull/125529#issuecomment-2130919307)) and is more work. It also seems unnecessary as CI actually uses a vendored tarball for builds.
cc `@mati865`
completely refactor how we manage blocking and unblocking threads
This hides a lot of invariants from the implementation of the synchronization primitives, and makes sure we never have to release or acquire a vector clock on another thread but the active one.
fix(opt-dist): respect existing config.toml
This is another step toward making opt-dist work in sandboxed environments. See also <https://github.com/rust-lang/rust/pull/125465>.
opt-dist verifies the final built rustc against a subset of rustc test
suite. However it overwrote the pre-existing `config.toml` [^1],
and that results in ./vendor/ directory removed [^2].
Instead of overwriting, this patch use `--set <config-value>` to
override paths to rustc / cargo / llvm-config.
[^1]: 606afbb617/src/tools/opt-dist/src/tests.rs (L62-L77)
[^2]: 8679004993/src/bootstrap/bootstrap.py (L1057)
tidy: stop special-casing tests/ui entry limit
It is genuinely more annoying to have this error, now that this value is below the general `ENTRY_LIMIT` cap, when one is trying to clean out tests from tests/ui! This code has served its purpose well, let it rest now rather than force it to continue haunting us.
Avoid clone when constructing runnable label.
I stumbled across this when reading this code. This seems like an unnecessary allocation (though likely small?)
It's confusing because if a function is unstable overall, there's no
need to highlight the constness is also unstable. Technically, these
attributes (overall stability and const-stability) are separate, but in
practice, we don't even show the const-unstable's feature flag (it's
normally the same as the overall function).
This is another step toward making opt-dist work in sandboxed environments
opt-dist verifies the final built rustc against a subset of rustc test
suite. However it overwrote the pre-existing `config.toml` [^1],
and that results in ./vendor/ directory removed [^2].
Instead of overwriting, this patch use `--set <config-value>` to
override paths to rustc / cargo / llvm-config.
[^1]: 606afbb617/src/tools/opt-dist/src/tests.rs (L62-L77)
[^2]: 8679004993/src/bootstrap/bootstrap.py (L1057)
Rollup of 7 pull requests
Successful merges:
- #121377 (Stabilize `LazyCell` and `LazyLock`)
- #122986 (Fix c_char on AIX)
- #123803 (Fix `VecDeque::shrink_to` UB when `handle_alloc_error` unwinds.)
- #124080 (Some unstable changes to where opaque types get defined)
- #124667 (Stabilize `div_duration`)
- #125472 (tidy: validate LLVM component names in tests)
- #125523 (Exit the process a short time after entering our ctrl-c handler)
r? `@ghost`
`@rustbot` modify labels: rollup
tidy: validate LLVM component names in tests
LLVM component names are not immediately obvious (they usually omit any suffixes on the target arch name), and if they're incorrect, the test will silently never run.
This happened [here](https://github.com/rust-lang/rust/pull/125220#discussion_r1612626002), and it would be nice to prevent it.
Stabilize `LazyCell` and `LazyLock`
Closes#109736
This stabilizes the [`LazyLock`](https://doc.rust-lang.org/stable/std/sync/struct.LazyLock.html) and [`LazyCell`](https://doc.rust-lang.org/stable/std/cell/struct.LazyCell.html) types:
```rust
static HASHMAP: LazyLock<HashMap<i32, String>> = LazyLock::new(|| {
println!("initializing");
let mut m = HashMap::new();
m.insert(13, "Spica".to_string());
m.insert(74, "Hoyten".to_string());
m
});
let lazy: LazyCell<i32> = LazyCell::new(|| {
println!("initializing");
92
});
```
r? libs-api
Rollup of 8 pull requests
Successful merges:
- #125271 (use posix_memalign on almost all Unix targets)
- #125451 (Fail relating constants of different types)
- #125478 (Bump bootstrap compiler to the latest beta compiler)
- #125498 (Stop using the avx512er and avx512pf x86 target features)
- #125510 (remove proof tree formatting, make em shallow)
- #125513 (Don't eagerly monomorphize drop for types that are impossible to instantiate)
- #125514 (Structurally resolve before `builtin_index` in EUV)
- #125527 (Add manual Sync impl for ReentrantLockGuard)
r? `@ghost`
`@rustbot` modify labels: rollup
Bump bootstrap compiler to the latest beta compiler
This PR updates the bootstrap compiler, aka stage0 to the latest beta version, since it contains rust-lang/cargo#13925.
It removes those unconditional Cargo warnings:
```
warning: [...]/rust/library/core/Cargo.toml: unused manifest key: lints.rust.unexpected_cfgs.check-cfg
warning: [...]/rust/library/std/Cargo.toml: unused manifest key: lints.rust.unexpected_cfgs.check-cfg
warning: [...]/rust/library/alloc/Cargo.toml: unused manifest key: lints.rust.unexpected_cfgs.check-cfg
```
for all contributors/users of this repository (including CI).
I don't know if that's something we do, or if it's even advisable, feel free to close.
r? `@Mark-Simulacrum`
Update cargo
7 commits in 84dc5dc11a9007a08f27170454da6097265e510e..a8d72c675ee52dd57f0d8f2bae6655913c15b2fb
2024-05-20 18:57:08 +0000 to 2024-05-24 03:34:17 +0000
- Improve error description when deserializing partial field struct (rust-lang/cargo#13956)
- fix: remove symlink dir on Windows (rust-lang/cargo#13910)
- Fix wrong type of rustc-flags in documentation (rust-lang/cargo#13957)
- Add more high level traces (rust-lang/cargo#13951)
- upgrade gix from 0.62 to 0.63 (rust-lang/cargo#13948)
- Use `i32` rather than `usize` as "default integer" in library template (rust-lang/cargo#13939)
- fetch specific commits even if the github fast path fails (rust-lang/cargo#13946)
r? ghost
compiler: validate.rs belongs next to what it validates
It's hard to find code that is deeply nested and far away from its callsites, so let's move `rustc_const_eval::transform::validate` into `rustc_mir_transform`, where all of its callers are. As `rustc_mir_transform` already depends on `rustc_const_eval`, the added visible dependency edge doesn't mean the dependency tree got any worse.
This also lets us unnest the `check_consts` module.
I did look into moving everything inside `rustc_const_eval::transform` into `rustc_mir_transform`. It turned out to be a much more complex operation, with more concerns and real edges into the `const_eval` crate, whereas this was both faster and more obvious.
