Rollup of 13 pull requests #129977
Closed
Rollup of 13 pull requests #129977
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
Because it's the target libdir. `--print` uses the same terminology, and it's a simple way to make it obviously different from `$sysroot/lib`.
Determining this path occasionally fails locally for unknown reasons, resulting in the build failing with an unhelpful `StripPrefixError(())` panic message. In order to track down why that's happening, include some relevant information in the panic message when that failure occurs.
We recently had an issue because some rustlib files were missing (like: "error[E0463]: can't find crate for rustc_ast") when building tools that rely on rustc. This patch fixes that by copying those files as required. Signed-off-by: onur-ozkan <work@onurozkan.dev>
... can not be correctly gated using #[cfg] macro
Signed-off-by: onur-ozkan <work@onurozkan.dev>
…-ozkan Call the target libdir target libdir Because it's the target libdir. `--print` uses the same terminology, and it's a simple way to make it obviously different from `$sysroot/lib`.
…llot Add an internal lint that warns when accessing untracked data Some methods access data that is not tracked by the query system and should be used with caution. As suggested in rust-lang#128815 (comment), in this PR I propose a lint (modeled on the `potential_query_instability` lint) that warns when using some specially-annotatted functions. I can't tell myself if this lint would be that useful, compared to renaming `Steal::is_stolen` to `is_stolen_untracked`. This would depend on whether there are other functions we'd want to lint like this. So far it seems they're called `*_untracked`, which may be clear enough. r? ``@oli-obk``
…d-items, r=t-rustdoc-frontend [rustdoc] Sort impl associated items by kinds and then by appearance Following [this zulip discussion](https://rust-lang.zulipchat.com/#narrow/stream/266220-t-rustdoc/topic/.22Freeze.22.20order.20of.20items.20in.20.28trait.29.20impls.3F), I implemented it. This brings the following change: impl associated items will now be grouped by kind and will now be first sorted by kind and then by the order they are declared in the source code (like currently). The kinds are sorted in the following order: 1. Constants 2. Types 3. Functions The reason behind this order is that associated constants can be used in associated types (like length in arrays) and both associated types and associated constants can be used in associated functions. So if an associated item from the same impl is used, its definition will always be above where it's being used. cc ```@camelid``` r? ```@notriddle```
…tmcm clarify that addr_of creates read-only pointers Stacked Borrows does make this UB, but Tree Borrows does not. This is tied up with rust-lang#56604 and other UCG discussions. Also see [this collection of links](Rust-for-Linux/linux#950 (comment)) where rustc treats `addr_of!` as a "non-mutating use". So, let's better be careful for now.
…arsan68 bootstrap: Try to track down why `initial_libdir` sometimes fails When I try to run `x` commands from the command-line, I occasionally see a mysterious failure that looks something like this: ```text thread 'main' panicked at src/lib.rs:341:14: called `Result::unwrap()` on an `Err` value: StripPrefixError(()) ``` It happens often enough to be annoying, but rarely enough that I can't reproduce it at will. The error message points to a particular `unwrap` call, but doesn't include enough context to determine *why* the failure occurs. Re-running the command almost always works, so I suspect some kind of filesystem race condition (possibly involving VSCode invoking bootstrap at the same time), but there's not much I can do with the information I currently have. So this PR includes some relevant information in the panic message when the failure occurs, in the hope that doing so will make the cause easier to track down when the failure occurs again.
…rors explain why Rvalue::Len still exists I just spent a bit of time trying to remove this until I realized why that's non-trivial. Let's document that for the next person. :)
…RalfJung s390x: Fix a regression related to backchain feature In rust-lang#127506, we introduced a new IBM Z-specific target feature, `backchain`. This particular `target-feature` was available as a function-level attribute in LLVM 17 and below, so some hacks were used to avoid blowing up LLVM when querying the supported LLVM features. This led to an unfortunate regression where `cfg!(target-feature = "backchain")` will always return true. This pull request aims to fix this issue, and a test has been introduced to ensure it will never happen again. Fixes rust-lang#129927. r? `@RalfJung`
…=Kobzol copy rustc rustlib artifacts from ci-rustc We recently (since rust-lang#129311) had an issue because some rustlib files were missing (like: "error[E0463]: can't find crate for rustc_ast") when building tools that rely on rustc. This patch fixes that by copying those files as required. r? Kobzol Blocker for rust-lang#122709
…er, r=Kobzol use the bootstrapped compiler for `test-float-parse` test Fixes rust-lang#122709 (comment). Blocker for rust-lang#122709
…pietroalbini Add compat note for trait solver change r? `@pietroalbini` `@BoxyUwU` cc `@lcnr`
…separators, r=tgross35 Add digit separators in `Duration` examples `@rustbot` label A-docs
Temporarily remove fmease from the review rotation Namely for like a week. I seriously need to work off my review backlog! r? fmease
…bertlarsan68 forward linker option to lint-docs This fixes an error found when building the doc for a cross-built toolchain. ``` warning: the code example in lint `unstable_syntax_pre_expansion` in /buildroots/chenx97/rustc-1.80.1-src/compiler/rustc_lint_defs/src/builtin.rs failed to generate the expected output: did not find lint `unstable_syntax_p re_expansion` in output of example, got: error: linking with `cc` failed: exit status: 1 ... ``` Closes: rust-lang#129956
rustbot
added
A-meta
|
@bors r+ rollup=never p=13 |
bors
added
S-waiting-on-bors
|
The job Click to see the possible cause of the failure (guessed by this bot) |
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.
Successful merges:
initial_libdirsometimes fails #129775 (bootstrap: Try to track down whyinitial_libdirsometimes fails)test-float-parsetest #129943 (use the bootstrapped compiler fortest-float-parsetest)Durationexamples #129947 (Add digit separators inDurationexamples)r? @ghost
@rustbot modify labels: rollup
Create a similar rollup