Rollup of 10 pull requests #137352
Closed
Rollup of 10 pull requests #137352
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
The `Box::new(T::default())` implementation of `Box::default` only had two stack copies in debug mode, compared to the current version, which has four. By avoiding creating any `MaybeUninit<T>`'s and just writing `T` directly to the `Box` pointer, the stack usage in debug mode remains the same as the old version.
``` warning: cannot find macro `in_root` in the crate root --> $DIR/key-value-expansion-scope.rs:1:10 | LL | #![doc = in_root!()] | ^^^^^^^ not found in the crate root | = warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release! = note: for more information, see issue rust-lang#124535 <rust-lang#124535> = help: import `macro_rules` with `use` to make it callable above its definition = note: `#[warn(out_of_scope_macro_calls)]` on by default ```
Currently many of them exceed 100 chars, which makes them painful to read on a terminal that is 100 chars wide.
I found the dialect/phase distinction quite confusing when I first read these comments. This commit clarifies things a bit.
The only visible change is to the filenames produce by `-Zdump-mir`. E.g. before and after: ``` h.main.003-000.analysis-post-cleanup.after.mir h.main.2-2-000.analysis-post-cleanup.after.mir ``` It also fixes a FIXME comment.
Also minimize some visibilities in the destination file.
`Postorder` has a `C: Customization<'tcx>` parameter, that gives it flexibility about how it computes successors. But in practice, there are only two `impls` of `Customization`, and one is for the unit type. This commit simplifies things by removing the generic parameter and replacing it with an `Option`.
…cking drops in MIR typeck
It's a misleading name, because it's not interned.
It's a bit weird.
As `unwrap_crate_local`, because it follows exactly the standard form of an `unwrap` function.
Because it has the same fields, and avoids the need to deconstruct the latter to construct the former.
The comments didn't make much sense to me. I asked Matthew Jasper on Zulip about it and they said: > I think that at the time I wanted to replace all (or most of) this > with a reference to the HIR Id of the variable. I'll give this a look > to see if it's still a reasonable idea, but removing the comments is > fine. and then: > I don't think that changing this to an HirId would be better, > recovering the information from the HIR seems like too much effort in > exchange for making the MIR a little smaller.
It's a very small and simple type.
The target feature names are, right now, based on the llvm target feature names. These mostly line up well with the names of [Facility Inidications](https://publibfp.dhe.ibm.com/epubs/pdf/a227832d.pdf#page=301) names. The linux kernel uses shorter, more cryptic names. (e.g. "vector" is `vx`). We can deviate from the llvm names, but the CPU vendor (IBM) does not appear to use e.g. `vx` for what they call `vector`. There are a number of implied target features between the vector facilities (based on the [Facility Inidications](https://publibfp.dhe.ibm.com/epubs/pdf/a227832d.pdf#page=301) table): - 129 The vector facility for z/Architecture is installed in the z/Architecture architectural mode. - 134 The vector packed decimal facility is installed in the z/Architecture architectural mode. When bit 134 is one, bit 129 is also one. - 135 The vector enhancements facility 1 is installed in the z/Architecture architectural mode. When bit 135 is one, bit 129 is also one. - 148 The vector-enhancements facility 2 is installed in the z/Architecture architectural mode. When bit 148 is one, bits 129 and 135 are also one. - 152 The vector-packed-decimal-enhancement facility 1 is installed in the z/Architecture architectural mode. When bit 152 is one, bits 129 and 134 are also one. - 165 The neural-network-processing-assist facility is installed in the z/Architecture architectural mode. When bit 165 is one, bit 129 is also one. - 192 The vector-packed-decimal-enhancement facility 2 is installed in the z/Architecture architectural mode. When bit 192 is one, bits 129, 134, and 152 are also one. And then there are a number of facilities without any implied target features - 45 The distinct-operands, fast-BCR-serialization, high-word, and population-count facilities, the interlocked-access facility 1, and the load/store-oncondition facility 1 are installed in the z/Architecture architectural mode. - 73 The transactional-execution facility is installed in the z/Architecture architectural mode. Bit 49 is one when bit 73 is one. - 133 The guarded-storage facility is installed in the z/Architecture architectural mode. - 150 The enhanced-sort facility is installed in the z/Architecture architectural mode. - 151 The DEFLATE-conversion facility is installed in the z/Architecture architectural mode. The added target features are those that have ISA implications, can be queried at runtime, and have LLVM support. LLVM [defines more target features](https://github.com/llvm/llvm-project/blob/d49a2d2bc9c65c787bfa04ac8ece614da48a8cd5/llvm/lib/Target/SystemZ/SystemZFeatures.td), but I'm not sure those are useful. They can always be added later, and can already be set globally using `-Ctarget-feature`.
…rochenkov Specify scope in `out_of_scope_macro_calls` lint ``` warning: cannot find macro `in_root` in the crate root --> $DIR/key-value-expansion-scope.rs:1:10 | LL | #![doc = in_root!()] | ^^^^^^^ not found in the crate root | = warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release! = note: for more information, see issue rust-lang#124535 <rust-lang#124535> = help: import `macro_rules` with `use` to make it callable above its definition = note: `#[warn(out_of_scope_macro_calls)]` on by default ``` r? ``@petrochenkov``
…r=Amanieu add more `s390x` target features Closes rust-lang#88937 tracking issue: rust-lang#130869 The target feature names are, right now, just the llvm target feature names. These mostly line up well with the names of [Facility Indications](https://publibfp.dhe.ibm.com/epubs/pdf/a227832d.pdf#page=301) names. The linux kernel (and `/proc/cpuinfo`) uses shorter, more cryptic names. (e.g. "vector" is `vx`). We can deviate from the llvm names, but the CPU vendor (IBM) does not appear to use e.g. `vx` for what they call `vector`. There are a number of implied target features between the vector facilities (based on the [Facility Indications](https://publibfp.dhe.ibm.com/epubs/pdf/a227832d.pdf#page=301) table): - 129 The vector facility for z/Architecture is installed in the z/Architecture architectural mode. - 134 The vector packed decimal facility is installed in the z/Architecture architectural mode. When bit 134 is one, bit 129 is also one. - 135 The vector enhancements facility 1 is installed in the z/Architecture architectural mode. When bit 135 is one, bit 129 is also one. - 148 The vector-enhancements facility 2 is installed in the z/Architecture architectural mode. When bit 148 is one, bits 129 and 135 are also one. - 152 The vector-packed-decimal-enhancement facility 1 is installed in the z/Architecture architectural mode. When bit 152 is one, bits 129 and 134 are also one. - 165 The neural-network-processing-assist facility is installed in the z/Architecture architectural mode. When bit 165 is one, bit 129 is also one. - 192 The vector-packed-decimal-enhancement facility 2 is installed in the z/Architecture architectural mode. When bit 192 is one, bits 129, 134, and 152 are also one. The remaining facilities do not have any implied target features (that we provide): - 45 The distinct-operands, fast-BCR-serialization, high-word, and population-count facilities, the interlocked-access facility 1, and the load/store-oncondition facility 1 are installed in the z/Architecture architectural mode. - 73 The transactional-execution facility is installed in the z/Architecture architectural mode. Bit 49 is one when bit 73 is one. - 133 The guarded-storage facility is installed in the z/Architecture architectural mode. - 150 The enhanced-sort facility is installed in the z/Architecture architectural mode. - 151 The DEFLATE-conversion facility is installed in the z/Architecture architectural mode. The added target features are those that have ISA implications, can be queried at runtime, and have LLVM support. LLVM [defines more target features](https://github.com/llvm/llvm-project/blob/d49a2d2bc9c65c787bfa04ac8ece614da48a8cd5/llvm/lib/Target/SystemZ/SystemZFeatures.td), but I'm not sure those are useful. They can always be added later, and can already be set globally using `-Ctarget-feature`. I'll also update the `is_s390x_feature_supported` macro (added in rust-lang/stdarch#1699, not yet on nightly, that needs an stdarch sync) to include these target features. `@Amanieu` you had some reservations about the `"vector"` target feature name. It does appear to be the most "official" name we have. On the one hand the name is very generic, and some of the other names are rather long. For the `neural-network-processing-assist` even LLVM thought that was a bit much and shortened it to `nnp-assist`. Also for `vector-packed-decimal-enhancement facility 1` the llvm naming is inconsistent. On the other hand, the cpuinfo names are very cryptic, and aren't found in the IBM documentation. r? `@Amanieu` cc `@uweigand` `@taiki-e`
…chenkov Some codegen_llvm cleanups Using some more safe wrappers and thus being able to remove a large unsafe block. As a next step we should probably look into safe extern fns
…, r=Nadrieril Use `edition = "2024"` in the compiler (redux) Most of this is binding mode changes, which I fixed by running `x.py fix`. Also adds some miscellaneous `unsafe` blocks for new unsafe standard library functions (the setenv ones), and a missing `unsafe extern` block in some enzyme codegen code, and fixes some precise capturing lifetime changes (but only when they led to errors). cc ``@ehuss`` ``@traviscross``
rustbot
added
A-attributes
|
@bors try |
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Feb 21, 2025
Rollup of 10 pull requests Successful merges: - rust-lang#128080 (Specify scope in `out_of_scope_macro_calls` lint) - rust-lang#135630 (add more `s390x` target features) - rust-lang#136089 (Reduce `Box::default` stack copies in debug mode) - rust-lang#137192 (Remove obsolete Windows ThinLTO+TLS workaround) - rust-lang#137204 (Clarify MIR dialects and phases) - rust-lang#137299 (Simplify `Postorder` customization.) - rust-lang#137302 (Use a probe to avoid registering stray region obligations when re-checking drops in MIR typeck) - rust-lang#137305 (Tweaks in and around `rustc_middle`) - rust-lang#137313 (Some codegen_llvm cleanups) - rust-lang#137333 (Use `edition = "2024"` in the compiler (redux)) r? `@ghost` `@rustbot` modify labels: rollup try-job: aarch64-gnu try-job: armhf-gnu try-job: i686-mingw-1 try-job: i686-mingw-2 try-job: i686-mingw-3 try-job: test-various try-job: x86_64-gnu-nopt try-job: x86_64-msvc-1 try-job: x86_64-msvc-2
|
☀️ Try build successful - checks-actions |
|
@bors r+ rollup=never p=5 |
bors
added
S-waiting-on-bors
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Feb 21, 2025
…kingjubilee Rollup of 10 pull requests Successful merges: - rust-lang#128080 (Specify scope in `out_of_scope_macro_calls` lint) - rust-lang#135630 (add more `s390x` target features) - rust-lang#136089 (Reduce `Box::default` stack copies in debug mode) - rust-lang#137192 (Remove obsolete Windows ThinLTO+TLS workaround) - rust-lang#137204 (Clarify MIR dialects and phases) - rust-lang#137299 (Simplify `Postorder` customization.) - rust-lang#137302 (Use a probe to avoid registering stray region obligations when re-checking drops in MIR typeck) - rust-lang#137305 (Tweaks in and around `rustc_middle`) - rust-lang#137313 (Some codegen_llvm cleanups) - rust-lang#137333 (Use `edition = "2024"` in the compiler (redux)) 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
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:
out_of_scope_macro_callslint #128080 (Specify scope inout_of_scope_macro_callslint)s390xtarget features #135630 (add mores390xtarget features)Box::defaultstack copies in debug mode #136089 (ReduceBox::defaultstack copies in debug mode)Postordercustomization. #137299 (SimplifyPostordercustomization.)rustc_middle#137305 (Tweaks in and aroundrustc_middle)edition = "2024"in the compiler (redux) #137333 (Useedition = "2024"in the compiler (redux))r? @ghost
@rustbot modify labels: rollup
Create a similar rollup