Sync from rust #17254
Closed
Sync from rust #17254
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
Update stdarch submodule I'm syncing the rustc_codegen_gcc backend currently and it seems that the new rustc version we use is not happy with the current stdarch submodule version: https://github.com/rust-lang/rustc_codegen_gcc/actions/runs/7930753019/job/21653642490?pr=439 r? `@Amanieu`
deduplicate infer var instantiation Having 3 separate implementations of one of the most subtle parts of our type system is not a good strategy if we want to maintain a sound type system ✨ while working on this I already found some subtle bugs in the existing code, so that's awesome 🎉 cc #121159 This was necessary as I am not confident in my nll changes in #119106, so I am first cleaning this up in a separate PR. r? `@BoxyUwU`
…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
…ister rustc: Some small changes for the wasm32-wasip2 target This commit has a few changes for the wasm32-wasip2 target. The first two are aimed at improving the compatibility of using `clang` as an external linker driver on this target. The default target to LLVM is updated to match the Rust target and additionally the `-fuse-ld=lld` argument is dropped since that otherwise interferes with clang's own linker detection. The only linker on wasm targets is LLD but on the wasip2 target a wrapper around LLD, `wasm-component-ld`, is used to drive the process and perform steps necessary for componentization. The final commit changes the output of all objects on the wasip2 target to being PIC by default. This improves compatibilty with shared libaries but notably does not mean that there's a turnkey solution for shared libraries. The hope is that by having the standard libray work both with and without dynamic libraries will make experimentation easier.
Do not add leading asterisk in the `PartialEq`
I think we should address this issue, however I am not exactly sure, if this is the right way to do it. It is related to the #123056.
Imagine the simplified code:
```rust
trait MyTrait {}
impl PartialEq for dyn MyTrait {
fn eq(&self, _other: &Self) -> bool {
true
}
}
#[derive(PartialEq)]
enum Bar {
Foo(Box<dyn MyTrait>),
}
```
On the nightly compiler, the `derive` produces invalid code with the weird error message:
```
error[E0507]: cannot move out of `*__arg1_0` which is behind a shared reference
--> src/main.rs:11:9
|
9 | #[derive(PartialEq)]
| --------- in this derive macro expansion
10 | enum Things {
11 | Foo(Box<dyn MyTrait>),
| ^^^^^^^^^^^^^^^^ move occurs because `*__arg1_0` has type `Box<dyn MyTrait>`, which does not implement the `Copy` trait
|
= note: this error originates in the derive macro `PartialEq` (in Nightly builds, run with -Z macro-backtrace for more info)
```
It may be related to the perfect derive problem, although requiring the _type_ to be `Copy` seems unfortunate because it is not necessary. Besides, we are adding the extra dereference only for the diagnostics?
Refactor float `Primitive`s to a separate `Float` type Now there are 4 of them, it makes sense to refactor `F16`, `F32`, `F64` and `F128` out of `Primitive` and into a separate `Float` type (like integers already are). This allows patterns like `F16 | F32 | F64 | F128` to be simplified into `Float(_)`, and is consistent with `ty::FloatTy`. As a side effect, this PR also makes the `Ty::primitive_size` method work with `f16` and `f128`. Tracking issue: #116909 `@rustbot` label +F-f16_and_f128
… r=jieyouxu Migrate `run-make/rustdoc-output-path` to rmake Part of rust-lang/rust#121876. r? ``@jieyouxu``
…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
rustbot
added
the
S-waiting-on-review
|
#17152 only shows 250 commits (as opposed to 1742 here), but that's just a display issue. |
The workflow got disabled due to inactivity again, I re-enabled it now though feel free to trigger a manual publish there if you don't want to wait. I'm not planning on merging anything this week anymore. (though looking at it we don't have manual ones setup in the CI) |
|
This needs to wait for 1.79 because |
|
Meh, that's annoying, guess we should've realized that and called it out since we did get pinged on that PR due to something else. (and 1.79 is still a few weeks away...) Will you need to make a new sync PR if we merge anything before merging this? Assuming no conflicts happen or is that gonna cause issues? |
|
Otherwise I'm sure upstream would be fine to undo that change for that crate until 1.79 releases (as I expect the earlier we get this josh move over with the better, especially since it has been a while since the last sync) |
It was easy to make, I can just make a new one next month. The only issue is that we can't update the rustup version.
Do you think so? I'm not sure. |
I take that as the josh debugging has finally worked out then? 🎉
Shouldn't be too problematic, I don't think any critical bug is in the current rustup version that is fixed right now, nor are there any interesting proc-macro server things outstanding iirc.
It's very minor, I'd be surprised if they said no. |
Hopefully? But only thanks to RalfJung :-).
I filed rust-lang/rust#125240, but I suspect it's going to be deemed as too much churn. |
|
|
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.
Using
josh, this time.Fails to build right now because we need to upgrade to a newer version of
rustc_abi. It should have come out last Sunday, but the workflow didn't run.