Rollup of 8 pull requests #127169
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
|
@bors r+ rollup=never p=8 |
bors
added
S-waiting-on-bors
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
|
@bors retry |
bors
added
S-waiting-on-bors
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:
box_pointerslint. #126018 (Remove thebox_pointerslint.)run-make-supportlibraryargsAPI #127161 (Improverun-make-supportlibraryargsAPI)r? @ghost
@rustbot modify labels: rollup
Create a similar rollup