-
Notifications
You must be signed in to change notification settings - Fork 12.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Rollup of 8 pull requests #127169
Closed
Closed
Rollup of 8 pull requests #127169
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
Remove `Rvalue::CheckedBinaryOp` Zulip conversation: <https://rust-lang.zulipchat.com/#narrow/stream/189540-t-compiler.2Fwg-mir-opt/topic/intrinsics.20vs.20binop.2Funop/near/438729996> cc `@RalfJung` While it's a draft, r? ghost
…, r=RalfJung,nikic compiler: add simd_ctpop intrinsic Fairly straightforward addition. cc `@rust-lang/opsem` new (extremely boring) intrinsic
Typical uses of ThinLTO don't have any use for this as a standalone file, but distributed ThinLTO uses this to make the linker phase more efficient. With clang you'd do something like `clang -flto=thin -fthin-link-bitcode=foo.indexing.o -c foo.c` and then get both foo.o (full of bitcode) and foo.indexing.o (just the summary or index part of the bitcode). That's then usable by a two-stage linking process that's more friendly to distributed build systems like bazel, which is why I'm working on this area. I talked some to @teresajohnson about naming in this area, as things seem to be a little confused between various blog posts and build systems. "bitcode index" and "bitcode summary" tend to be a little too ambiguous, and she tends to use "thin link bitcode" and "minimized bitcode" (which matches the descriptions in LLVM). Since the clang option is thin-link-bitcode, I went with that to try and not add a new spelling in the world. Per @dtolnay, you can work around the lack of this by using `lld --thinlto-index-only` to do the indexing on regular .o files of bitcode, but that is a bit wasteful on actions when we already have all the information in rustc and could just write out the matching minimized bitcode. I didn't test that at all in our infrastructure, because by the time I learned that I already had this patch largely written.
The standard library now has the right configs in it's Cargo.toml
rustc_codegen_llvm: add support for writing summary bitcode Typical uses of ThinLTO don't have any use for this as a standalone file, but distributed ThinLTO uses this to make the linker phase more efficient. With clang you'd do something like `clang -flto=thin -fthin-link-bitcode=foo.indexing.o -c foo.c` and then get both foo.o (full of bitcode) and foo.indexing.o (just the summary or index part of the bitcode). That's then usable by a two-stage linking process that's more friendly to distributed build systems like bazel, which is why I'm working on this area. I talked some to `@teresajohnson` about naming in this area, as things seem to be a little confused between various blog posts and build systems. "bitcode index" and "bitcode summary" tend to be a little too ambiguous, and she tends to use "thin link bitcode" and "minimized bitcode" (which matches the descriptions in LLVM). Since the clang option is thin-link-bitcode, I went with that to try and not add a new spelling in the world. Per `@dtolnay,` you can work around the lack of this by using `lld --thinlto-index-only` to do the indexing on regular .o files of bitcode, but that is a bit wasteful on actions when we already have all the information in rustc and could just write out the matching minimized bitcode. I didn't test that at all in our infrastructure, because by the time I learned that I already had this patch largely written.
This replaces the drop_in_place reference with null in vtables. On librustc_driver.so, this drops about ~17k dynamic relocations from the output, since many vtables can now be placed in read-only memory, rather than having a relocated pointer included. This makes a tradeoff by adding a null check at vtable call sites. That's hard to avoid without changing the vtable format (e.g., to use a pc-relative relocation instead of an absolute address, and avoid the dynamic relocation that way). But it seems likely that the check is cheap at runtime.
Add an intrinsic for `ptr::metadata` The follow-up to rust-lang#123840, so we can remove `PtrComponents` and `PtrRepr` from libcore entirely (well, after a bootstrap update). As discussed in <https://rust-lang.zulipchat.com/#narrow/stream/189540-t-compiler.2Fwg-mir-opt/topic/.60ptr_metadata.60.20in.20MIR/near/435637808>, this introduces `UnOp::PtrMetadata` taking a raw pointer and returning the associated metadata value. By no longer going through a `union`, this should also help future PRs better optimize pointer operations. r? ``@oli-obk``
Show files produced by `--emit foo` in json artifact notifications Right now it is possible to ask `rustc` to save some intermediate representation into one or more files with `--emit=foo`, but figuring out what exactly was produced is difficult. This pull request adds information about `llvm_ir` and `asm` intermediate files into notifications produced by `--json=artifacts`. Related discussion: https://internals.rust-lang.org/t/easier-access-to-files-generated-by-emit-foo/20477 Motivation - `cargo-show-asm` parses those intermediate files and presents them in a user friendly way, but right now I have to apply some dirty hacks. Hacks make behavior confusing: hintron/computer-enhance#35 This pull request introduces a new behavior: now `rustc` will emit a new artifact notification for every artifact type user asked to `--emit`, for example for `--emit asm` those will include all the `.s` files. Most users won't notice this behavior, to be affected by it all of the following must hold: - user must use `rustc` binary directly (when `cargo` invokes `rustc` - it consumes artifact notifications and doesn't emit anything) - user must specify both `--emit xxx` and `--json artifacts` - user must refuse to handle unknown artifact types - user must disable incremental compilation (or deal with it better than cargo does, or use a workaround like `save-temps`) in order not to hit rust-lang#88829 / rust-lang#89149
…r=lcnr Remove the `box_pointers` lint. As the comment says, this lint "is mostly historical, and not particularly useful". It's not worth keeping it around. r? `@estebank`
…umentation, r=Amanieu Fix simd_gather documentation There is no idx in the function signature.
Replace some magic booleans in match-lowering with enums This PR takes some boolean arguments used by the match-lowering code, and replaces them with dedicated enums that more clearly express their effect, while also making it much easier to find how each value is ultimately used.
…trieb small correction to fmt::Pointer impl ~~The `addr` method does not require `T: Sized`, and is preferred for use over `expose_provenance`.~~ `expose_provenance` does not require `T: Sized`.
coverage: Avoid getting extra unexpansion info when we don't need it Several callers of `unexpand_into_body_span_with_visible_macro` would immediately discard the additional macro-related information, which is wasteful. We can avoid this by having them instead call a simpler method that just returns the span they care about. This PR also moves the relevant functions out of `coverage::spans::from_mir` and into a new submodule `coverage::unexpand`, so that calling them from `coverage::mappings` is less awkward. There should be no actual changes to coverage-instrumentation output, as demonstrated by the absence of test updates.
Add a regression test for rust-lang#123630 Fixes rust-lang#123630 compiler should not suggest nonsensical signatures, original suggestion was ``` error[E0308]: mismatched types --> src/lib.rs:3:31 | 3 | fn select<F, I>(filter: F) -> Select<F, I> { | ------ ^^^^^^^^^^^^ expected `Select<F, I>`, found `()` | | | implicitly returns `()` as its body has no tail or `return` expression | = note: expected struct `Select<F, I>` found unit type `()` error[E0282]: type annotations needed for `Select<{closure@src/lib.rs:8:22: 8:25}, I>` --> src/lib.rs:8:9 | 8 | let lit = select(|x| match x { | ^^^ | help: consider giving `lit` an explicit type, where the type for type parameter `I` is specified | 8 | let lit: Select<{closure@src/lib.rs:8:22: 8:25}, I> = select(|x| match x { | ++++++++++++++++++++++++++++++++++++++++++++ Some errors have detailed explanations: E0282, E0308. For more information about an error, try `rustc --explain E0282`. ```
…gs, r=Kobzol Improve `run-make-support` library `args` API It allows to pass both `Vec` and slices, which makes it much better (for me at least 😉). r? `@Kobzol`
…bjorn3 Subtree sync for rustc_codegen_cranelift The main highlight this time is support for arm64 macOS in cg_clif. A future PR will enable distributing it as rustup component. r? `@ghost` `@rustbot` label +A-codegen +A-cranelift +T-compiler
rustbot
added
A-run-make
Area: port run-make Makefiles to rmake.rs
S-waiting-on-review
Status: Awaiting review from the assignee but also interested parties.
T-compiler
Relevant to the compiler team, which will review and decide on the PR/issue.
T-libs
Relevant to the library team, which will review and decide on the PR/issue.
rollup
A PR which is a rollup
labels
Jun 30, 2024
@bors r+ rollup=never p=8 |
bors
added
S-waiting-on-bors
Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
and removed
S-waiting-on-review
Status: Awaiting review from the assignee but also interested parties.
labels
Jun 30, 2024
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Jun 30, 2024
…iaskrgr Rollup of 8 pull requests Successful merges: - rust-lang#126018 (Remove the `box_pointers` lint.) - rust-lang#126895 (Fix simd_gather documentation) - rust-lang#126981 (Replace some magic booleans in match-lowering with enums) - rust-lang#127069 (small correction to fmt::Pointer impl) - rust-lang#127157 (coverage: Avoid getting extra unexpansion info when we don't need it) - rust-lang#127160 (Add a regression test for rust-lang#123630) - rust-lang#127161 (Improve `run-make-support` library `args` API) - rust-lang#127162 (Subtree sync for rustc_codegen_cranelift) r? `@ghost` `@rustbot` modify labels: rollup
The job Click to see the possible cause of the failure (guessed by this bot)
|
💔 Test failed - checks-actions |
bors
added
S-waiting-on-review
Status: Awaiting review from the assignee but also interested parties.
and removed
S-waiting-on-bors
Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
labels
Jun 30, 2024
@bors retry |
bors
added
S-waiting-on-bors
Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
and removed
S-waiting-on-review
Status: Awaiting review from the assignee but also interested parties.
labels
Jun 30, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
A-run-make
Area: port run-make Makefiles to rmake.rs
rollup
A PR which is a rollup
S-waiting-on-bors
Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
T-compiler
Relevant to the compiler team, which will review and decide on the PR/issue.
T-libs
Relevant to the library team, which will review and decide on the PR/issue.
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:
box_pointers
lint. #126018 (Remove thebox_pointers
lint.)run-make-support
libraryargs
API #127161 (Improverun-make-support
libraryargs
API)r? @ghost
@rustbot modify labels: rollup
Create a similar rollup