Rustup #3786
Merged
Rustup #3786
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
Delegation: second attempt to improve perf Possible perf fix for rust-lang/rust#125929 r? `@petrochenkov`
…r=Amanieu improve error message when `global_asm!` uses `asm!` operands follow-up to rust-lang/rust#128207 what was ``` error: expected expression, found keyword `in` --> src/lib.rs:1:31 | 1 | core::arch::global_asm!("{}", in(reg)); | ^^ expected expression ``` becomes ``` error: the `in` operand cannot be used with `global_asm!` --> $DIR/parse-error.rs:150:19 | LL | global_asm!("{}", in(reg)); | ^^ the `in` operand is not meaningful for global-scoped inline assembly, remove it ``` the span of the error is just the keyword, which means that we can't create a machine-applicable suggestion here. The alternative would be to attempt to parse the full operand, but then if there are syntax errors in the operand those would be presented to the user, even though the parser already knows that the output won't be valid. Also that would require more complexity in the parser. So I think this is a nice improvement at very low cost.
time.rs: remove "Basic usage text" Only one example is given (for each method)
Miri: add a flag to do recursive validity checking The point of this flag is to allow gathering experimental data for rust-lang/unsafe-code-guidelines#412.
rustdoc: Cleanup `CacheBuilder` code for building search index This code was very convoluted and hard to reason about. It is now (I hope) much clearer and more suitable for both future enhancements and future cleanups. I'm doing this as a precursor, with no UI changes, to changing rustdoc to [ignore blanket impls][1] in type-based search. [1]: rust-lang/rust#128471 (comment) r? ``@notriddle``
allow setting `link-shared` and `static-libstdcpp` with CI LLVM These options also affect `compiler/rustc_llvm` builds. They should be configurable even when using CI LLVM. r? ```@cuviper```
…eGomez rustdoc: make the hover trail for doc anchors a bit bigger https://rust-lang.zulipchat.com/#narrow/stream/266220-t-rustdoc/topic/Weird.20markdown.20heading.20rendering.3F r? ```@GuillaumeGomez``` ### Screenshots (the purple part is the padding, which the mouse can pass through to hover over it) | Before | After | |--|--| |  | 
Update rinja version to 0.3.0 r? ```@notriddle```
Rollup of 7 pull requests Successful merges: - #128305 (improve error message when `global_asm!` uses `asm!` operands) - #128526 (time.rs: remove "Basic usage text") - #128531 (Miri: add a flag to do recursive validity checking) - #128578 (rustdoc: Cleanup `CacheBuilder` code for building search index) - #128589 (allow setting `link-shared` and `static-libstdcpp` with CI LLVM) - #128615 (rustdoc: make the hover trail for doc anchors a bit bigger) - #128620 (Update rinja version to 0.3.0) r? `@ghost` `@rustbot` modify labels: rollup
…mease Check divergence value first before doing span operations in `warn_if_unreachable` It's more expensive to extract the span's desugaring first rather than check the value of the divergence enum. For some reason I inverted these checks, probably for readability, but as a consequence I regressed perf: rust-lang/rust#128443 (comment) r? fmease
Move the standard library to a separate workspace This ensures that the Cargo.lock packaged for it in the rust-src component is up-to-date, allowing rust-analyzer to run cargo metadata on the standard library even when the rust-src component is stored in a read-only location as is necessary for loading crates.io dependencies of the standard library. This also simplifies tidy's license check for runtime dependencies as it can now look at all entries in library/Cargo.lock without having to filter for just the dependencies of runtime crates. In addition this allows removing an exception in check_runtime_license_exceptions that was necessary due to the compiler enabling a feature on the object crate which pulls in a dependency not allowed for the standard library. While cargo workspaces normally enable dependencies of multiple targets to be reused, for the standard library we do not want this reusing to prevent conflicts between dependencies of the sysroot and of tools that are built using this sysroot. For this reason we already use an unstable cargo feature to ensure that any dependencies which would otherwise be shared get a different -Cmetadata argument as well as using separate build dirs. This doesn't change the situation around vendoring. We already have several cargo workspaces that need to be vendored. Adding another one doesn't change much. There are also no cargo profiles that are shared between the root workspace and the library workspace anyway, so it doesn't add any extra work when changing cargo profiles.
|
@bors r+ |
|
☀️ Test successful - checks-actions |
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.