Rollup of 9 pull requests #146142
Closed
Rollup of 9 pull requests #146142
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
…him is exported Previously it would attempt to export the allocator shim even linking for a crate type which pulls in the allocator shim from a dylib rather than locally defining it.
This patch introduces an LSX-optimized version of `analyze_source_file` for the `loongarch64` target. Similar to existing SSE2 implementation for x86, this version: - Processes 16-byte chunks at a time using LSX vector intrinsics. - Quickly identifies newlines in ASCII-only chunks. - Falls back to the generic implementation when multi-byte UTF-8 characters are detected or in the tail portion.
…tside macro matching
LLVM upstream switched layouts to support 256-bit vector load/store.
This bug only shows up when you run htmldocck in a directory other than outdir, and also use globs. Never happened before, which is why we're only seeing it now.
Ensure we emit an allocator shim when only some crate types need one Found this while trying to write a test for rust-lang#145955.
Add LSX accelerated implementation for source file analysis This patch introduces an LSX-optimized version of `analyze_source_file` for the `loongarch64` target. Similar to existing SSE2 implementation for x86, this version: - Processes 16-byte chunks at a time using LSX vector intrinsics. - Quickly identifies newlines in ASCII-only chunks. - Falls back to the generic implementation when multi-byte UTF-8 characters are detected or in the tail portion.
…ochenkov Derive `PartialEq` for `InvisibleOrigin` For rust-lang#145354, we need `PartialEq` for `TokenStream` to "just work". However, due to the special comparison implementation that was used for `InvisibleOrigin`, this wasn't the case. So I derived `PartialEq` for `InvisibleOrigin`, and used the previous special comparison logic only on the single place where it was actually required. r? ````@petrochenkov````
Correct typo in `rustc_errors` comment
…r=petrochenkov fix: Filter suggestion parts that match existing code While testing my changes to make `rustc` use `annotate-snippets`, I encountered a new `clippy` test failure stemming from [two](https://github.com/rust-lang/rust/pull/145273/files#diff-6e8403e31463539666afbc00479cb416dc767a518f562b6e2960630953ee7da2R275-R278) [suggestion](https://github.com/rust-lang/rust/pull/145273/files#diff-6e8403e31463539666afbc00479cb416dc767a518f562b6e2960630953ee7da2R289-R292) output changes in rust-lang#145273. The new output in these two cases feels like a regression as it is not as clear as the old output, and adds unnecessary information. Before rust-lang#145273 (`Diff` style)  After rust-lang#145273 ("multi-line" style)  The reason for the change was that a new suggestion part (which matches existing code) was added on a different line than the existing parts, causing the suggestion style to change from `Diff` to "multi-line". Since this new part matches existing code, no code changes show up in the output for it, but it still makes the suggestion style "multi-line" when it doesn't need to be. To get the old output back, I made it so that suggestion parts that perfectly match existing code get filtered out.
…type-test, r=GuillaumeGomez rustdoc-search: add test case for indexing every item type Test case for rust-lang#146117
llvm: nvptx: Layout update to match LLVM LLVM upstream switched layouts to support 256-bit vector load/store. ```@rustbot``` label llvm-main r? durin42
…g-code-block-fences, r=tgross35 docs(std): add missing closing code block fences in doc comments This PR adds a few closing code block fences which I believe are missing in some doc comments. It seems that rustdoc just autocloses code blocks at the end of doc comments and thus these were easily overlooked: I do not think these code blocks are special in any way. I found these when working on a Clippy lint that checks the last sentence of doc comments for terminal punctuation, and these were failing cases when testing against the std. Therefore I am not entirely sure these are all such cases, but still have high hopes that they are (or at least a well-defined subset of them).
compiletest: cygwin follows windows in using PATH for dynamic libraries ``@Berrysoft``
rustbot
added
A-compiletest
rustbot
added
T-libs
|
@bors r+ rollup=never p=5 |
bors
added
S-waiting-on-bors
|
I suspect #146121 fixes a crashes test |
|
Good eye! |
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:
PartialEqforInvisibleOrigin#146090 (DerivePartialEqforInvisibleOrigin)rustc_errorscomment #146120 (Correct typo inrustc_errorscomment)r? @ghost
@rustbot modify labels: rollup
Create a similar rollup