Rollup of 4 pull requests
Successful merges:
- #117298 (Recover from missing param list in function definitions)
- #117373 (Avoid the path trimming ICE lint in error reporting)
- #117441 (Do not assert in op_to_const.)
- #117488 (Update minifier-rs version to 0.3.0)
r? `@ghost`
`@rustbot` modify labels: rollup
Do not assert in op_to_const.
`op_to_const` is used in `try_destructure_mir_constant_for_diagnostics`, which may encounter invalid constants created by optimizations and debugging.
r? ``@oli-obk``
Fixes https://github.com/rust-lang/rust/issues/117368
Avoid the path trimming ICE lint in error reporting
Types or really anything in MIR should never be formatted without path trimming disabled, because its formatting often tries to construct trimmed paths. In this case, the lint turns a nice error report into an irrelevant ICE.
Add FileCheck annotations to MIR-opt inlining tests
Part of #116971, adds FileCheck annotations to MIR-opt tests in `tests/mir-opt/inline`.
I left out a few (such as `inline_cycle`) where it mentioned that the particular outcome of inlining isn't important, just that the inliner doesn't get stuck in an infinite loop.
r? cjgillot
Account for `ref` and `mut` in the wrong place for pattern ident renaming
If the user writes `S { ref field: name }` instead of `S { field: ref name }`, we suggest the correct code.
Fix#72298.
Set max_atomic_width for riscv32*-esp-espidf to 32
Fixes#117305
> Since riscv32 does not have 64-bit atomic instructions, I do not believe there is any way to fix this problem other than setting max_atomic_width of these targets to 32.
This is a breaking change because Atomic\*64 will become unavailable, but all affected targets are tier 3, and the current Atomic*64 violates the standard library's API contract and can cause problems with code that rely on the standard library's atomic types being lock-free.
r? `@Amanieu`
cc `@ivmarkov` `@MabezDev`
Add `unused_enumerate_index` lint
A lint for unused `.enumerate()` indexes (`for (_, x) in iter.enumerate()`).
I wasn't able to find a `rustc_span::sym::Enumerate`, so the code for checking that it's the correct `Enumerate` iterator is a bit weird.
---
changelog: New lint: [`unused_enumerate_index`]: A new lint for checking that the indexes from `.enumerate()` calls are used.
[#10404](https://github.com/rust-lang/rust-clippy/pull/10404)
<!-- changelog_checked -->
Support enum variants in offset_of!
This MR implements support for navigating through enum variants in `offset_of!`, placing the enum variant name in the second argument to `offset_of!`. The RFC placed it in the first argument, but I think it interacts better with nested field access in the second, as you can then write things like
```rust
offset_of!(Type, field.Variant.field)
```
Alternatively, a syntactic distinction could be made between variants and fields (e.g. `field::Variant.field`) but I'm not convinced this would be helpful.
[RFC 3308 # Enum Support](https://rust-lang.github.io/rfcs/3308-offset_of.html#enum-support-offset_ofsomeenumstructvariant-field_on_variant)
Tracking Issue #106655.
Inline and remove `create_session`.
Currently the parts of session initialization that happen within `rustc_interface` are split between `run_compiler` and `create_session`. This split isn't necessary and obscures what's happening.
This commit merges the two functions. I think a single longer function is much clearer than splitting this code across two functions in different modules, especially when `create_session` has 13 parameters, and is misnamed (it also creates the codegen backend). The net result is 43 fewer lines of code.
r? ``@oli-obk``
Don't emit delayed good-path bugs on panic
This should fix#117381, cc ``@RalfJung``
As opposed to delayed bugs, delayed *good path* bugs really don't make sense to show on panics.
Clean up unchecked_math, separate out unchecked_shifts
Tracking issue: #85122
Changes:
1. Remove `const_inherent_unchecked_arith` flag and make const-stability flags the same as the method feature flags. Given the number of other unsafe const fns already stabilised, it makes sense to just stabilise these in const context when they're stabilised.
2. Move `unchecked_shl` and `unchecked_shr` into a separate `unchecked_shifts` flag, since the semantics for them are unclear and they'll likely be stabilised separately as a result.
3. Add an `unchecked_neg` method exclusively to signed integers, under the `unchecked_neg` flag. This is because it's a new API and probably needs some time to marinate before it's stabilised, and while it *would* make sense to have a similar version for unsigned integers since `checked_neg` also exists for those there is absolutely no case where that would be a good idea, IMQHO.
The longer-term goal here is to prepare the `unchecked_math` methods for an FCP and stabilisation since they've existed for a while, their semantics are clear, and people seem in favour of stabilising them.
Match usize/isize exhaustively with half-open ranges
The long-awaited finale to the saga of [exhaustiveness checking for integers](https://github.com/rust-lang/rust/pull/50912)!
```rust
match 0usize {
0.. => {} // exhaustive!
}
match 0usize {
0..usize::MAX => {} // helpful error message!
}
```
Features:
- Half-open ranges behave as expected for `usize`/`isize`;
- Trying to use `0..usize::MAX` will tell you that `usize::MAX..` is missing and explain why. No more unhelpful "`_` is missing";
- Everything else stays the same.
This should unblock https://github.com/rust-lang/rust/issues/37854.
Review-wise:
- I recommend looking commit-by-commit;
- This regresses perf because of the added complexity in `IntRange`; hopefully not too much;
- I measured each `#[inline]`, they all help a bit with the perf regression (tho I don't get why);
- I did not touch MIR building; I expect there's an easy PR there that would skip unnecessary comparisons when the range is half-open.
Currently the parts of session initialization that happen within
`rustc_interface` are split between `run_compiler` and `create_session`.
This split isn't necessary and obscures what's happening.
This commit merges the two functions. I think a single longer function
is much clearer than splitting this code across two functions in
different modules, especially when `create_session` has 13 parameters,
and is misnamed (it also creates the codegen backend). The net result is
43 fewer lines of code.
Replace switch to unreachable by assume statements
`UnreachablePropagation` currently keeps some switch terminators alive in order to ensure codegen can infer the inequalities on the discriminants.
This PR proposes to encode those inequalities as `Assume` statements.
This allows to simplify MIR further by removing some useless terminators.
Rollup of 5 pull requests
Successful merges:
- #113241 (rustdoc: Document lack of object safety on affected traits)
- #117388 (Turn const_caller_location from a query to a hook)
- #117417 (Add a stable MIR visitor)
- #117439 (prepopulate opaque ty storage before using it)
- #117451 (Add support for pre-unix-epoch file dates on Apple platforms (#108277))
r? `@ghost`
`@rustbot` modify labels: rollup
Update cargo
7 commits in 708383d620e183a9ece69b8fe930c411d83dee27..b4d18d4bd3db6d872892f6c87c51a02999b80802
2023-10-27 21:09:26 +0000 to 2023-10-31 18:19:10 +0000
- refactor(toml): Cleanup noticed on the way to rust-lang/cargo#12801 (rust-lang/cargo#12902)
- feat(trim-paths): set env `CARGO_TRIM_PATHS` for build scripts (rust-lang/cargo#12900)
- feat: implement RFC 3127 `-Ztrim-paths` (rust-lang/cargo#12625)
- docs: clarify config to use vendored source is printed to stdout (rust-lang/cargo#12893)
- Improve the margin calculation for the search command's UI (rust-lang/cargo#12890)
- Add new packages to [workspace.members] automatically (rust-lang/cargo#12779)
- refactor(toml): Decouple parsing from interning system (rust-lang/cargo#12881)
r? ghost
