internal: Sync from downstream #17259
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…nt, r=compiler-errors Reimpl meaningful test name lint MCP658 This reintroduces the tidy rule originally proposed in rust-lang/rust#113583 that then became an MCP in rust-lang/compiler-team#658 which eventually surfaced a quite-reasonable request for a diagnostic enhancement. I have added that to the rule. It produces output like this: ``` tidy error: file `ui/unsized/issue-115809.rs` must begin with a descriptive name, try `{reason}-issue-115809.rs` tidy error: file `ui/unsized/issue-115203.rs` must begin with a descriptive name, try `{reason}-issue-115203.rs` tidy error: file `ui/privacy/issue-113860-2.rs` must begin with a descriptive name, try `{reason}-issue-113860.rs` tidy error: file `ui/privacy/issue-117997.rs` must begin with a descriptive name, try `{reason}-issue-117997.rs` tidy error: file `ui/privacy/issue-119463.rs` must begin with a descriptive name, try `{reason}-issue-119463.rs` tidy error: file `ui/privacy/auxiliary/issue-117997.rs` must begin with a descriptive name, try `{reason}-issue-117997.rs` tidy error: file `ui/privacy/auxiliary/issue-119463-extern.rs` must begin with a descriptive name, try `{reason}-issue-119463.rs` tidy error: file `ui/privacy/issue-113860-1.rs` must begin with a descriptive name, try `{reason}-issue-113860.rs` tidy error: file `ui/privacy/issue-113860.rs` must begin with a descriptive name, try `{reason}-issue-113860.rs` tidy error: file `ui/const-generics/generic_const_exprs/const_kind_expr/issue_114151.rs` must begin with a descriptive name, try `{reason}-issue-114151.rs` tidy error: file `ui/did_you_mean/issue-114112.rs` must begin with a descriptive name, try `{reason}-issue-114112.rs` tidy error: file `ui/did_you_mean/issue-105225.rs` must begin with a descriptive name, try `{reason}-issue-105225.rs` tidy error: file `ui/did_you_mean/issue-105225-named-args.rs` must begin with a descriptive name, try `{reason}-issue-105225.rs` ``` You get the idea. There are some tests which merely would require reordering of the name according to the rule. I could modify the diagnostic further to identify those, but doing such would make it prone to bad suggestions. I have opted to trust contributors to recognize the diagnostic is robotic, as the pattern we are linting on is easier to match if we do not speculate on what parts of the name are meaningful: sometimes a word is a reason, but sometimes it is a mere "tag", such as with a pair like: - issue-314159265-blue.rs - issue-314159265-red.rs Starting them with `red-` and `blue-` means they do not sort together, despite being related, and the color names are still not very descriptive. Recognizing a good name is an open-ended task, though this pair might be: - colored-circle-gen-blue.rs - colored-circle-gen-red.rs Deciding exactly *how* to solve this is not the business of tidy, only recognizing a what. r? `@compiler-errors`
…r=compiler-errors pattern_analysis: Move constructor selection logic to `PlaceInfo` This is a small refactor PR. There was a dense bit of constructor-related logic in `compute_exhaustiveness_and_usefulness`. I'm moving it out into a `PlaceInfo` method to make it easier to follow both separately. I also have plans that will complicate it further so it's good that it's somewhat encapsulated. r? `@compiler-errors`
Change leak check and suspicious auto trait lint warning messages The leak check lint message "this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!" is misleading as some cases may not be phased out and could end being accepted. This is under discussion still. The suspicious auto trait lint the change in behavior already happened, so the new message is probably more accurate. r? `@lcnr` Closes #93367
unstable-book: Separate testing and production sanitizers This is a redo of [this PR](rust-lang/rust#108942). Left the commit as before (except for reflowing to 80-width), since it already got approved.
…=oli-obk
Merge `CompilerError::CompilationFailed` and `CompilerError::ICE`.
`CompilerError` has `CompilationFailed` and `ICE` variants, which seems reasonable at first. But the way it identifies them is flawed:
- If compilation errors out, i.e. `RunCompiler::run` returns an `Err`, it uses `CompilationFailed`, which is reasonable.
- If compilation panics with `FatalError`, it catches the panic and uses `ICE`. This is sometimes right, because ICEs do cause `FatalError` panics, but sometimes wrong, because certain compiler errors also cause `FatalError` panics. (The compiler/rustdoc/clippy/whatever just catches the `FatalError` with `catch_with_exit_code` in `main`.)
In other words, certain non-ICE compilation failures get miscategorized as ICEs. It's not possible to reliably distinguish the two cases, so this commit merges them. It also renames the combined variant as just `Failed`, to better match the existing `Interrupted` and `Skipped` variants.
Here is an example of a non-ICE failure that causes a `FatalError` panic, from `tests/ui/recursion_limit/issue-105700.rs`:
```
#![recursion_limit="4"]
#![invalid_attribute]
#![invalid_attribute]
#![invalid_attribute]
#![invalid_attribute]
#![invalid_attribute]
//~^ERROR recursion limit reached while expanding
fn main() {{}}
```
r? ``@spastorino``
Move the extra directives for `Mode::CoverageRun` into `iter_header` When these extra directives were ported over as part of #112300, it made sense to introduce `iter_header_extra` and pass them in as an extra argument. But now that #120881 has added a `mode` parameter to `iter_header` for its own purposes, it's slightly simpler to move the coverage special-case code directly into `iter_header` as well. This lets us get rid of `iter_header_extra`.
Allow AST and HIR visitors to return `ControlFlow` Alternative to #108598. Since rust-lang/libs-team#187 was rejected, this implements our own version of the `Try` trait (`VisitorResult`) and the `try` macro (`try_visit`). Since this change still allows visitors to return `()`, no changes have been made to the existing ones. They can be done in a separate PR.
Drive-by `DUMMY_SP` -> `Span` and fmt changes Noticed these while doing something else. There's no practical change, but it's preferable to use `DUMMY_SP` as little as possible, particularly when we have perfectlly useful `Span`s available.
Add regression test for #103369 The issue was fixed in 1.70.0. Closes #103369.
Remove an old hack for rustdoc Since #78696 has been resolved
Make `is_nonoverlapping` `#[inline]` It showed up with 3% execution time in a compiler profile. backlink to #120848 r? ``@saethlin``
return `ty::Error` when equating `ty::Error` This helps iron out a difference in diagnostics between `Sub` and `Equate` relations, which I'm currently trying to unify. r? oli-obk
Rollup of 10 pull requests Successful merges: - #120716 (Change leak check and suspicious auto trait lint warning messages) - #121195 (unstable-book: Separate testing and production sanitizers) - #121205 (Merge `CompilerError::CompilationFailed` and `CompilerError::ICE`.) - #121233 (Move the extra directives for `Mode::CoverageRun` into `iter_header`) - #121256 (Allow AST and HIR visitors to return `ControlFlow`) - #121307 (Drive-by `DUMMY_SP` -> `Span` and fmt changes) - #121308 (Add regression test for #103369) - #121310 (Remove an old hack for rustdoc) - #121311 (Make `is_nonoverlapping` `#[inline]`) - #121319 (return `ty::Error` when equating `ty::Error`) r? `@ghost` `@rustbot` modify labels: rollup
Always evaluate free constants and statics, even if previous errors occurred work towards rust-lang/rust#79738 We will need to evaluate static items before the `definitions.freeze()` below, as we will start creating new `DefId`s (for nested allocations) within the `eval_static_initializer` query. But even without that motivation, this is a good change. Hard errors should always be reported and not silenced if other errors happened earlier.
…r, r=davidtwco Overhaul `Diagnostic` and `DiagnosticBuilder` Implements the first part of rust-lang/compiler-team#722, which moves functionality and use away from `Diagnostic`, onto `DiagnosticBuilder`. Likely follow-ups: - Move things around, because this PR was written to minimize diff size, so some things end up in sub-optimal places. E.g. `DiagnosticBuilder` has impls in both `diagnostic.rs` and `diagnostic_builder.rs`. - Rename `Diagnostic` as `DiagInner` and `DiagnosticBuilder` as `Diag`. r? `@davidtwco`
Use intrinsics::debug_assertions in debug_assert_nounwind This is the first item in rust-lang/rust#120848. Based on the benchmarking in this PR, it looks like, for the programs in our benchmark suite, enabling all these additional checks does not introduce significant compile-time overhead, with the single exception of `Alignment::new_unchecked`. Therefore, I've added `#[cfg(debug_assertions)]` to that one call site, so that it remains compiled out in the distributed standard library. The trailing commas in the previous calls to `debug_assert_nounwind!` were causing the macro to expand to `panic_nouwnind_fmt`, which requires more work to set up its arguments, and that overhead alone is measured between this perf run and the next: rust-lang/rust#120863 (comment)
…=matthewjasper match lowering: eagerly simplify match pairs This removes one important complication from match lowering. Before this, match pair simplification (which includes collecting bindings and type ascriptions) was intertwined with the whole match lowering algorithm. I'm avoiding this by storing in each `MatchPair` the sub-`MatchPair`s that correspond to its subfields. This makes it possible to simplify everything (except or-patterns) in `Candidate::new()`. This should open up further simplifications. It will also give us proper control over the order of bindings. r? `@matthewjasper`
…jasper match lowering: simplify empty candidate selection In match lowering, `match_simplified_candidates` is tasked with removing candidates that are fully matched and linking them up properly. The code that does that was needlessly complicated; this PR simplifies it. The overall change isn't big but I split it up into tiny commits to convince myself that I was correctly preserving behavior. The test changes are all due to the first commit. Let me know if you'd prefer me to split up the PR to make reviewing easier. r? `@matthewjasper`
Add "algebraic" fast-math intrinsics, based on fast-math ops that cannot return poison Setting all of LLVM's fast-math flags makes our fast-math intrinsics very dangerous, because some inputs are UB. This set of flags permits common algebraic transformations, but according to the [LangRef](https://llvm.org/docs/LangRef.html#fastmath), only the flags `nnan` (no nans) and `ninf` (no infs) can produce poison. And this uses the algebraic float ops to fix rust-lang/rust#120720 cc `@orlp`
Remove useless `'static` bounds on `Box` allocator #79327 added `'static` bounds to the allocator parameter for various `Box` + `Pin` APIs to ensure soundness. But it was a bit overzealous, some of the bounds aren't actually needed.
Automatic Rustup
Improve UEFI stdio Fixed some things suggested in last PR: #116207 cc `@dvdhrm` cc `@nicholasbishop`
…-obk,Amanieu require simd_insert, simd_extract indices to be constants As discussed in rust-lang/rust#77477 (see in particular [here](rust-lang/rust#77477 (comment))). This PR doesn't touch codegen yet -- the first step is to ensure that the indices are always constants; the second step is to then make use of this fact in backends. Blocked on rust-lang/stdarch#1530 propagating to the rustc repo.
Make intrinsic fallback bodies cross-crate inlineable This change was prompted by the stage1 compiler spending 4% of its time when compiling the polymorphic-recursion MIR opt test in `unlikely`. Intrinsic fallback bodies like `unlikely` should always be inlined, it's very silly if they are not. To do this, we enable the fallback bodies to be cross-crate inlineable. Not that this matters for our workloads since the compiler never actually _uses_ the "fallback bodies", it just uses whatever was cfg(bootstrap)ped, so I've also added `#[inline]` to those. See the comments for more information. r? oli-obk
bump few deps Bumps `sysinfo`, `tabled`; dedupes `env_logger`; drops `is-terminal` https://github.com/zhiburt/tabled/blob/v0.15.1/CHANGELOG.md https://github.com/GuillaumeGomez/sysinfo/blob/v0.30.5/CHANGELOG.md
cargo update
Make `Barrier::new()` const I guess this was just missed in #97791? `@rustbot` label T-libs-api -T-libs
Implement `MappedMutexGuard`, `MappedRwLockReadGuard`, and `MappedRwLockWriteGuard`. ACP: rust-lang/libs-team#260 Tracking issue: rust-lang/rust#117108 <details> <summary> (Outdated) </summary> `MutexState`/`RwLockState` structs ~~Having `sys::(Mutex|RwLock)` and `poison::Flag` as separate fields in the `Mutex`/`RwLock` would require `MappedMutexGuard`/`MappedRwLockWriteGuard` to hold an additional pointer, so I combined the two fields into a `MutexState`/`RwLockState` struct. This should not noticeably affect perf or layout, but requires an additional field projection when accessing the former `.inner` or `.poison` fields (now `.state.inner` and `.state.poison`).~~ If this is not desired, then `MappedMutexGuard`/`MappedRwLockWriteGuard` can instead hold separate pointers to the two fields. </details> The doc-comments are mostly copied from the existing `*Guard` doc-comments, with some parts from `lock_api::Mapped*Guard`'s doc-comments. Unresolved question: Are more tests needed?
…rister Make `Ty::builtin_deref` just return a `Ty` Nowhere in the compiler are we using the mutability part of the `TyAndMut` that we used to return.
Rollup of 5 pull requests Successful merges: - #124615 (coverage: Further simplify extraction of mapping info from MIR) - #124778 (Fix parse error message for meta items) - #124797 (Refactor float `Primitive`s to a separate `Float` type) - #124888 (Migrate `run-make/rustdoc-output-path` to rmake) - #124957 (Make `Ty::builtin_deref` just return a `Ty`) r? `@ghost` `@rustbot` modify labels: rollup
Rename some `FulfillmentErrorCode`/`ObligationCauseCode` variants to be less redundant 1. Rename some `FulfillmentErrorCode` variants. 2. Always use `ObligationCauseCode::` to prefix a code, rather than using a glob import and naming them through `traits::`. 3. Rename some `ObligationCauseCode` variants -- I wasn't particularly thorough with thinking of a new names for these, so could workshop them if necessary. 4. Misc stuff from renaming. r? lcnr
Avoid `alloca`s in codegen for simple `mir::Aggregate` statements
The core idea here is to remove the abstraction penalty of simple newtypes in codegen.
Even something simple like constructing a
```rust
#[repr(transparent)] struct Foo(u32);
```
forces an `alloca` to be generated in nightly right now.
Certainly LLVM can optimize that away, but it would be nice if it didn't have to.
Quick example:
```rust
#[repr(transparent)]
pub struct Transparent32(u32);
#[no_mangle]
pub fn make_transparent(x: u32) -> Transparent32 {
let a = Transparent32(x);
a
}
```
on nightly we produce <https://rust.godbolt.org/z/zcvoM79ae>
```llvm
define noundef i32 `@make_transparent(i32` noundef %x) unnamed_addr #0 {
%a = alloca i32, align 4
store i32 %x, ptr %a, align 4
%0 = load i32, ptr %a, align 4, !noundef !3
ret i32 %0
}
```
but after this PR we produce
```llvm
define noundef i32 `@make_transparent(i32` noundef %x) unnamed_addr #0 {
start:
ret i32 %x
}
```
(even before the optimizer runs).
…ckHoleFox Refactor Apple `target_abi` This was bundled together with `Arch`, which complicated a few code paths and meant we had to do more string matching than necessary. CC `@BlackHoleFox` as you've worked on the Apple target spec before Related: Is there a reason why `Target`/`TargetOptions` use `StaticCow` for so many things, instead of an enum with defined values (and perhaps a catch-all case for custom target json files)? Tagging `@Nilstrieb,` as you might know?
Match ergonomics 2024: let `&` patterns eat `&mut` r? `@Nadrieril` cc rust-lang/rust#123076 `@rustbot` label A-edition-2024 A-patterns
use key-value format in stage0 file Currently, we are working on the python removal task on bootstrap. Which means we have to extract some data from the stage0 file using shell scripts. However, parsing values from the stage0.json file is painful because shell scripts don't have a built-in way to parse json files. This change simplifies the stage0 file format to key-value pairs, which makes it easily readable from any environment. See the zulip thread for more details: https://rust-lang.zulipchat.com/#narrow/stream/326414-t-infra.2Fbootstrap/topic/Using.20different.20format.20in.20the.20stage0.20file
std::alloc: use posix_memalign instead of memalign on solarish `memalign` on Solarish requires the alignment to be at least the size of a pointer, which we did not honor. `posix_memalign` also requires that, but that code path already takes care of this requirement. close GH-124787
Refactor examples and enhance documentation in result.rs - Replaced `map` with `map_err` in the error handling example for correctness - Reordered example code to improve readability and logical flow - Added assertions to examples to demonstrate expected outcomes
Re-add `From<f16> for f64`
This impl was originally added in #122470 before being removed in #123830 due to #123831. However, the issue only affects `f32` (which currently only has one `From<{float}>` impl, `From<f32>`) as `f64` already has two `From<{float}>` impls (`From<f32>` and `From<f64>`) and is also the float literal fallback type anyway. Therefore it is safe to re-add `From<f16> for f64`.
This PR also updates the FIXME link to point to the open issue #123831 rather than the closed issue #123824.
Tracking issue: #116909
`@rustbot` label +F-f16_and_f128 +T-libs-api
`rustc_resolve` cleanups Some improvements I found while looking through this code. r? `@estebank`
Add `-` (stdin) support in rustdoc This PR adds support for the special `-` input which threats the input as coming from *stdin* instead of being a filepath. Doing this also makes `rustdoc` consistent with `rustc` and ~~every~~ other tools. Full [motivation](rust-lang/rust#124611 (comment)). Fixes rust-lang/rust#123671 r? `@fmease`
alloc: implement FromIterator for Box<str> `Box<[T]>` implements `FromIterator<T>` using `Vec<T>` + `into_boxed_slice()`. Add analogous `FromIterator` implementations for `Box<str>` matching the current implementations for `String`. Remove the `Global` allocator requirement for `FromIterator<Box<str>>` too. ACP: rust-lang/libs-team#196
rustbot
added
the
S-waiting-on-review
|
@bors r+ |
|
☀️ Test successful - checks-actions |
|
Wow, our changelog generation made a mess out of this:
|
This was referenced May 28, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.