Automatic Rustup #4534
Merged
Automatic Rustup #4534
Conversation
This file contains hidden or 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
![workflows-miri[bot]](https://avatars.githubusercontent.com/u/5430905?s=60&v=4){kind=small}
The fallback is to just ignore the arguments. That is a valid implementation because this intrinsic is just a hint. I also added `miri::intrinsic_fallback_is_spec` annotation, so that miri now supports these operations. A prefetch intrinsic call is valid on any pointer.
Fix parameter order for `_by()` variants of `min` / `max`/ `minmax` in `std::cmp` We saw a regression introduced in version `1.86` that seems to be coming from switching the order of `v1` and `v2` when calling `comparison` functions in `min_by` / `max_by` / `minmax_by` (cf. this PR: rust-lang/rust#136307) When the `compare` function is not symmetric in the arguments, this leads to false results. Apparently, the test cases do not cover this scenario currently. While asymmetric comparison may be an edge case, but current behavior is unexpected nevertheless.
…echeck, r=notriddle Rustdoc: typecheck scrape-examples.js more typechecking progress, this time we're mostly held back by the fact that `document.querySelectorAll` can't return nice types if its given a compound query (see the issue linked in a code comment). Additionally, it seems like the generated `data-locs` attribute has fields that are never used by anything? r? ```@notriddle```
…twco mention lint group in default level lint note ### Summary This PR updates lint diagnostics so that default-level notes now mention the lint group they belong to, if any. Fixes: rust-lang/rust#65464. ### Example ```rust fn main() { let x = 5; } ``` Before: ``` = note: `#[warn(unused_variables)]` on by default ``` After: ``` = note: `#[warn(unused_variables)]` (part of `#[warn(unused)]`) on by default ``` ### Unchanged Cases Messages remain the same when the lint level is explicitly set, e.g.: * Attribute on the lint `#[warn(unused_variables)]`: ``` note: the lint level is defined here LL | #[warn(unused_variables)] | ^^^^^^^^^^^^^^^^ ``` * Attribute on the group `#[warn(unused)]:`: ``` = note: `#[warn(unused_variables)]` implied by `#[warn(unused)]` ``` * CLI option `-W unused`: ``` = note: `-W unused-variables` implied by `-W unused` = help: to override `-W unused` add `#[allow(unused_variables)]` ``` * CLI option `-W unused-variables`: ``` = note: requested on the command line with `-W unused-variables` ```
Clarify EOF handling for `BufRead::skip_until` This aligns `BufRead::skip_until`'s description more with `BufRead::read_until` in terms of how it handles EOF and extends the doctest to include this behavior.
…er-2, r=Kobzol,madsmtm Demote x86_64-apple-darwin to Tier 2 with host tools Switch to only using aarch64 runners (implying we are now cross-compiling) and stop running tests. In the future, we could enable (some?) tests via Rosetta 2. This implements the decision from rust-lang/rfcs#3841.
…lolbinarycat Fix bug where `rustdoc-js` tester would not pick the right `search.js` file if there is more than one It happened to me quite a few times recently when I worked on the search index: 1. I make a change in search.js 2. I run `rustdoc-js` tests 3. nothing changes So my solution was to simply remove the folder, but it's really suboptimal. With this PR, it now picks the most recently modified file. cc ```@lolbinarycat```
Implement feature `int_lowest_highest_one` for integer and NonZero types Tracking issue: rust-lang/rust#145203 Implement the accepted ACP rust-lang/rust#145203 for methods that find the index of the least significant (lowest) and most significant (highest) set bit in an integer for signed, unsigned, and NonZero types. Also add unit tests for all these types.
std_detect: RISC-V platform guide documentation This is practically a revert of a revert, making the commit e907456b2e10622ccd854a3bba8d02ce170b5dbb on `stdarch` come around again with minor fixes, enhancements and adjustments. An excerpt from the original commit message follows: Since there's no architectural feature detection on RISC-V (unlike `CPUID` on x86 architectures and some system registers on Arm/AArch64), runtime feature detection entirely depends on the platform-specific facility. As a result, availability of each feature heavily depends on the platform and its version. To help users make a decision for feature checking on a RISC-V system, this commit adds a platform guide with minimum supported platform versions.
Add runtime detection for APX-F and AVX10 This was missed in rust-lang/rust#139534 and rust-lang/rust#139675 `@rustbot` label O-x86_64 O-x86_32 A-target-feature r? `@Amanieu`
`std_detect`: Use `rustc-std-workspace-*` to pull in `compiler-builtins` rust-lang/rust#145489 changed `std_detect` to no longer depend on `cfg-if`, which meant it no longer indirectly pulled in `rustc-std-workspace-core` via `cfg-if`. That caused it to no longer depend on `compiler-builtins`. Change `std_detect` to use `rustc-std-workspace-core` and `rustc-std-workspace-alloc`, to integrate with the rustc workspace. This also pulls in `compiler-builtins` via `rustc-std-workspace-core`. Closes: rust-lang/rust#145594
…lacrum Remove the std workspace patch for `compiler-builtins` All dependencies of `std` have dropped the crates.io dependency on `compiler-builtins`, so this patch is no longer needed. Closes: RUST-142265
…wiser Pretty print the name of an future from calling async closure Fixes rust-lang/rust#145606 by introducing a way to customize the path rendering of async closures' futures in the pretty printer API.
add a fallback implementation for the `prefetch_*` intrinsics related ACP: rust-lang/libs-team#638 The fallback is to just ignore the arguments. That is a valid implementation because this intrinsic is just a hint. I also added the `miri::intrinsic_fallback_is_spec` annotation, so that miri now supports these operations. A prefetch intrinsic call is valid on any pointer. (specifically LLVM guarantees this https://llvm.org/docs/LangRef.html#llvm-prefetch-intrinsic) Next, I made the `LOCALITY` argument a const generic. That argument must be const (otherwise LLVM crashes), but that was not reflected in the type. Finally, with these changes, the intrinsic can be safe and `const` (a prefetch at const evaluation time is just a no-op). cc `@Amanieu` r? `@RalfJung`
Rollup of 13 pull requests Successful merges: - rust-lang/rust#139357 (Fix parameter order for `_by()` variants of `min` / `max`/ `minmax` in `std::cmp`) - rust-lang/rust#140314 (Rustdoc: typecheck scrape-examples.js) - rust-lang/rust#140794 (mention lint group in default level lint note) - rust-lang/rust#145006 (Clarify EOF handling for `BufRead::skip_until`) - rust-lang/rust#145252 (Demote x86_64-apple-darwin to Tier 2 with host tools) - rust-lang/rust#145359 (Fix bug where `rustdoc-js` tester would not pick the right `search.js` file if there is more than one) - rust-lang/rust#145381 (Implement feature `int_lowest_highest_one` for integer and NonZero types) - rust-lang/rust#145417 (std_detect: RISC-V platform guide documentation) - rust-lang/rust#145531 (Add runtime detection for APX-F and AVX10) - rust-lang/rust#145619 (`std_detect`: Use `rustc-std-workspace-*` to pull in `compiler-builtins`) - rust-lang/rust#145622 (Remove the std workspace patch for `compiler-builtins`) - rust-lang/rust#145623 (Pretty print the name of an future from calling async closure) - rust-lang/rust#145626 (add a fallback implementation for the `prefetch_*` intrinsics ) r? `@ghost` `@rustbot` modify labels: rollup
… r=petrochenkov Sometimes skip over tokens in `parse_token_tree`. r? `@petrochenkov`
Fix rustc uplifting (take two) The rustc uplifting logic is really annoying.. rust-lang/rust#145557 was not enough to fix it. Consider rust-lang/rust#145534 (comment): in this situation, we do a stage3 build of a cross-compiled rustc (it happens because we run `x test --stage 2`, which mistakenly builds a stage3 rustc, but it doesn't matter what casuses it, what matters is that the stage3 build isn't working). Currently, a stage3 cross-compiled build of rustc works like this: 1) stage0 (host) -> stage1 (host) 2) stage1 (host) -> stage2 (host) 3) stage2 (host) -> stage3 (target) The problem is that in the uplifting logic, I assumed that we will have a stage2 (target) rustc available, which we can uplift. And that would indeed be an ideal solution. But currently, we will actually build a stage2 (*host*) rustc, and only then start the cross-compilation. So the uplifting is broken. I spend a couple of hours trying to fix this, and do the uplifting "from the other direction", so that already when we assemble a stage3 rustc, we notice that an uplift should happen, and we only build stage1 (host) rustc, which also helps avoid one needless rustc build. However, this was relatively complicated and would require larger changes that I was not confident landing at this time. So instead I decided to do a much simpler fix, and just disable rustc uplifting when cross-compiling. Since we currently do the `stage2 (host) -> stage3 (target)` step, it should not actually affect stage3 cross-compiled builds in any way (I hope..), and should only affect stage4+ builds, about which I don't really care (the only change there should be more rustc builds). For normal builds, the stage2 host rustc should (hopefully) always be present, so we shouldn't run into this issue. Eventually, I would like to remove rustc uplifting completely. However, `x test --stage 2` on CI still currently builds a stage3 rustc for some reason, and if we removed uplifting completely, even for non-cross-compiled builds, that would cause an additional rustc build, and that's not great. So for now let's just allow uplifting for non-cross-compiled builds. Fixes rust-lang/rust#145534. r? `@jieyouxu`
Pass `alloc-variant-zeroed` to LLVM Makes use of llvm/llvm-project#138299 (once we pull in a version of LLVM with this attribute). ~~Unfortunately also requires llvm/llvm-project#149336 to work.~~ Closes rust-lang/rust#104847
Tell LLVM about read-only captures `&Freeze` parameters are not only `readonly` within the function, but any captures of the pointer can also only be used for reads. This can now be encoded using the `captures(address, read_provenance)` attribute.
This updates the rust-version file to 125ff8a788c5d6a66917f499abdc00051afe6886.
Pull recent changes from https://github.com/rust-lang/rust via Josh. Upstream ref: 125ff8a788c5d6a66917f499abdc00051afe6886 Filtered ref: bcbe2eb This merge was created using https://github.com/rust-lang/josh-sync.
|
Thank you for contributing to Miri! |
|
Hm, did the Rustc regression range: rust-lang/rust@f605b57...125ff8a |
Closed
|
Seems to be related to compiler-builtins... @tgross35 any idea why this may have broken? rust-lang/rust@988092e is in the regression range. |
|
Specifically:
I think previously compiler-builtins could be built without building any C code and that seems to no longer work in all cases. |
|
This seems to actually build compiler_builtins twice...?!? Seems like not all crates.io dependencies have actually been dropped so removing the patch causes the crates.io version to be pulled in and that one then fails to build. |
|
Ah, rustc-build-sysroot will need some adjustments to deal with the new sysroot layout... RalfJung/rustc-build-sysroot#29. |
|
Hm, do you know what pulled in the crates.io version? The recent versions of all deps currently used by rust-lang/rust should no longer be using the crates.io compiler-builtins, I'm wondering if it got the old version of a dependency for some reason |
|
It was pulled in by the logic in rustc-build-sysroot. |
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.
Update
rustcto rust-lang/rust@125ff8a.