Rollup of 6 pull requests #108159
Merged
Rollup of 6 pull requests #108159
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
This is what ISO C strongly implies this is correct, and many processor-specific ABIs imply or mandate this size, so "everyone" (LLVM, gcc...) defaults to emitting enums this way. However, this is by no means guaranteed by ISO C, and the bare-metal Arm targets show it can be overridden, which rustc supports via `c-enum-min-bits` in a target.json. The override is a flag named `-fshort-enums` in clang and gcc, but introducing a CLI flag is probably unnecessary for rustc. This flag can be used by non-Arm microcontroller targets, like AVR and MSP430, but it is not enabled for them by default. Rust programmers who know the size of a target's enums can use explicit reprs, which also lets them match C23 code. This change is most relevant to 16-bit targets: AVR and MSP430. Most of rustc's targets use 32-bit ints, but ILP64 does exist. Regardless, rustc should now correctly handle enums for both very small and very large targets. Thanks to William for confirming MSP430 behavior, and to Waffle for better style and no-core size_of asserts. Co-authored-by: William D. Jones <thor0505@comcast.net> Co-authored-by: Waffle Maybe <waffle.lapkin@gmail.com>
…16-bit-targets, r=WaffleLapkin Default `repr(C)` enums to `c_int` size This is what ISO C strongly implies this is correct, and many processor-specific ABIs imply or mandate this size, so "everyone" (LLVM, gcc...) defaults to emitting enums this way. However, this is by no means guaranteed by ISO C, and the bare-metal Arm targets show it can be overridden, which rustc supports via `c-enum-min-bits` in a target.json. The override is a flag named `-fshort-enums` in clang and gcc, but introducing a CLI flag is probably unnecessary for rustc. This flag can be used by non-Arm microcontroller targets, like AVR and MSP430, but it is not enabled for them by default. Rust programmers who know the size of a target's enums can use explicit reprs, which also lets them match C23 code. This change is most relevant to 16-bit targets: AVR and MSP430. Most of rustc's targets use 32-bit ints, but ILP64 does exist. Regardless, rustc should now correctly handle enums for both very small and very large targets. Thanks to William for confirming MSP430 behavior, and to Waffle for better style and no-core `size_of` asserts. Fixes rust-lang#107361 Fixes rust-lang#77806
Copy `bin/*` and `lib/*.dylib` files to `stage0-sysroot` Fixes rust-lang#101691
fix a line, and do a consistency fix
…Mark-Simulacrum Add compiler-errors to a few more triagebot groups Self-explanatory
…mpiler-errors `BasicBlock::new(0)` -> `START_BLOCK` [no functional changes]
rustbot
added
A-meta
|
@bors r+ rollup=never p=6 |
bors
added
S-waiting-on-bors
|
☀️ Test successful - checks-actions |
|
📌 Perf builds for each rolled up PR: previous master: f4f5fc3e5c In the case of a perf regression, run the following command for each PR you suspect might be the cause: |
1 task
|
Finished benchmarking commit (f722b24): comparison URL. Overall result: no relevant changes - no action needed@rustbot label: -perf-regression Warning ⚠: The following benchmark(s) failed to build:
cc @rust-lang/wg-compiler-performance Instruction countThis benchmark run did not return any relevant results for this metric. Max RSS (memory usage)This benchmark run did not return any relevant results for this metric. CyclesThis benchmark run did not return any relevant results for this metric. |
|
The bootstrapping perf test failed, which is weird. The last few lines of output with the error: Strange. Has anything about the paths changed lately? I guess we can keep watching, see if this is a once-only failure or if it continues. |
|
Hm, the next merge commit also lacks any kind of benchmark... |
|
Only the bootstrap timings are missing, correct ? Make sure the following is toggled.
|
|
Ugh 😅 could we make it say "No relevant results" instead of "No results" if there are results but that checkbox is not ticket? :/ |
|
Implemented here. |
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:
repr(C)enums toc_intsize #107592 (Defaultrepr(C)enums toc_intsize)bin/*andlib/*.dylibfiles tostage0-sysroot#107956 (Copybin/*andlib/*.dylibfiles tostage0-sysroot)BasicBlock::new(0)->START_BLOCK[no functional changes] #108154 (BasicBlock::new(0)->START_BLOCK[no functional changes])Failed merges:
r? @ghost
@rustbot modify labels: rollup
Create a similar rollup