Fix `VecDeque::shrink_to` UB when `handle_alloc_error` unwinds.
Fixes#123369
For `VecDeque` it's relatively simple to restore the buffer into a consistent state so this PR does just that.
Note that with its current implementation, `shrink_to` may change the internal arrangement of elements in the buffer, so e.g. `[D, <uninit>, A, B, C]` will become `[<uninit>, A, B, C, D]` and `[<uninit>, <uninit>, A, B, C]` may become `[B, C, <uninit>, <uninit>, A]` if `shrink_to` unwinds. This shouldn't be an issue though as we don't make any guarantees about the stability of the internal buffer arrangement (and this case is impossible to hit on stable anyways).
This PR also includes a test with code adapted from #123369 which fails without the new `shrink_to` code. Does this suffice or do we maybe need more exhaustive tests like in #108475?
cc `@Amanieu`
`@rustbot` label +T-libs
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
Add assert_unsafe_precondition to unchecked_{add,sub,neg,mul,shl,shr} methods
(Old PR is haunted, opening a new one. See #117494 for previous discussion.)
This ensures that these preconditions are actually checked in debug mode, and hopefully should let people know if they messed up. I've also replaced the calls (I could find) in the code that use these intrinsics directly with those that use these methods, so that the asserts actually apply.
More discussions on people misusing these methods in the tracking issue: https://github.com/rust-lang/rust/issues/85122.
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
Add manual Sync impl for ReentrantLockGuard
Fixes: #125526
Tracking Issue: #121440
this impl is even shown in the summary in the tracking issue, but apparently was forgotten in the actual implementation
remove proof tree formatting, make em shallow
Debugging via tracing `RUSTC_LOG=rustc_trait_selection::solve=debug` is now imo slightly more readable then the actual proof tree formatter. Removing everything that's not needed for the `analyse` visitor allows us to remove a bunch of code.
I personally believe that we should continue to use tracing over proof trees for debugging:
- it eagerly prints, allowing us to debug ICEs
- the proof tree builder ends up going out of sync with the actual runtime behavior, which is confusing
- using shallow proof trees is a lot more performant as we frequently do not recurse into all nested goals when using an analyse visitor
- this allows us to clean up the implementation and remove some code
r? ```@compiler-errors```
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`
Fail relating constants of different types
fixes#121585fixes#121858fixes#124151
I gave this several attempts before, but we lost too many important diagnostics until I managed to make compilation never bail out early. We have reached this point, so now we can finally fix all those ICEs by bubbling up an error instead of continueing when we encounter a bug.
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
The body of these benchmarks is close to empty but not literally empty.
This was making the runtime of the benchmarks (which are compiled
without optimizations!) flicker between 9 ns and 10 ns runtime, which
changes the padding and breaks the test. Recent changes to the standard
library have pushed the runtime closer to 10 ns when unoptimized, which
is why we haven't seen such failures before in CI.
Contributors can also induce such failures before this PR by running the
run-make tests while the system is under heavy load.
Warn (or error) when `Self` ctor from outer item is referenced in inner nested item
This implements a warning `SELF_CONSTRUCTOR_FROM_OUTER_ITEM` when a self constructor from an outer impl is referenced in an inner nested item. This is a proper fix mentioned https://github.com/rust-lang/rust/pull/117246#discussion_r1374648388.
This warning is additionally bumped to a hard error when the self type references generic parameters, since it's almost always going to ICE, and is basically *never* correct to do.
This also reverts part of https://github.com/rust-lang/rust/pull/117246, since I believe this is the proper fix and we shouldn't need the helper functions (`opt_param_at`/`opt_type_param`) any longer, since they shouldn't really ever be used in cases where we don't have this problem.
Rollup of 7 pull requests
Successful merges:
- #125467 (Only suppress binop error in favor of semicolon suggestion if we're in an assignment statement)
- #125483 (compiler: validate.rs belongs next to what it validates)
- #125485 (Migrate `run-make/rustdoc-with-output-dir-option` to `rmake.rs`)
- #125497 (Fix some SIMD intrinsics documentation)
- #125501 (Resolve anon const's parent predicates to direct parent instead of opaque's parent)
- #125503 (rustdoc-json: Add test for keywords with `--document-private-items`)
- #125519 (tag more stuff with `WG-trait-system-refactor`)
r? `@ghost`
`@rustbot` modify labels: rollup
Resolve anon const's parent predicates to direct parent instead of opaque's parent
When an anon const is inside of an opaque, #99801 added a hack to resolve the anon const's parent predicates *not* to the opaque's predicates, but to the opaque's *parent's* predicates. This is insufficient when considering nested opaques.
This means that the `predicates_of` an anon const might reference duplicated lifetimes (installed by `compute_bidirectional_outlives_predicates`) when computing known outlives in MIR borrowck, leading to these ICEs:
Fixes#121574Fixes#118403
~~Instead, we should be using the `OpaqueTypeOrigin` to acquire the owner item (fn/type alias/etc) of the opaque, whose predicates we're fine to mention.~~
~~I think it's a bit sketchy that we're doing this at all, tbh; I think it *should* be fine for the anon const to inherit the predicates of the opaque it's located inside. However, that would also mean that we need to make sure the `generics_of` that anon const line up in the same way.~~
~~None of this is important to solve right now; I just want to fix these ICEs so we can land #125468, which accidentally fixes these issues in a different and unrelated way.~~
edit: We don't need this special case anyways because we install the right parent item in `generics_of` anyways:
213ad10c8f/compiler/rustc_hir_analysis/src/collect/generics_of.rs (L150)
r? `@BoxyUwU`
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.
Only suppress binop error in favor of semicolon suggestion if we're in an assignment statement
Similar to #123722, we are currently too aggressive when delaying a binop error with the expectation that we'll emit another error elsewhere. This adjusts that heuristic to be more accurate, at the cost of some possibly poorer suggestions.
Fixes#125458
Rollup of 5 pull requests
Successful merges:
- #125455 (Make `clamp` inline)
- #125477 (Run rustfmt on files that need it.)
- #125481 (Fix the dead link in the bootstrap README)
- #125482 (Notify kobzol after changes to `opt-dist`)
- #125489 (Revert problematic opaque type change)
r? `@ghost`
`@rustbot` modify labels: rollup
Run rustfmt on files that need it.
Somehow these files aren't properly formatted. By default `x fmt` and `x tidy` only check files that have changed against master, so if an ill-formatted file somehow slips in it can stay that way as long as it doesn't get modified(?)
I found these when I ran `x fmt` explicitly on every `.rs` file in the repo, while working on
https://github.com/rust-lang/compiler-team/issues/750.
Make `clamp` inline
Context: rust-lang/rust-clippy#12826
This results in slightly more optimized assembly. (And most important, it's now less than lines than just manually clamping a value)
Simplify key-based thread locals
This PR simplifies key-based thread-locals by:
* unifying the macro expansion of `const` and non-`const` initializers
* reducing the amount of code in the expansion
* simply reallocating on recursive initialization instead of going through `LazyKeyInner`
* replacing `catch_unwind` with the shared `abort_on_dtor_unwind`
It does not change the initialization behaviour described in #110897.
