Skip to content
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 6 pull requests #108159

Merged
merged 12 commits into from
Feb 17, 2023
Merged

Rollup of 6 pull requests #108159

merged 12 commits into from
Feb 17, 2023

Conversation

matthiaskrgr
Copy link
Member

Successful merges:

Failed merges:

r? @ghost
@rustbot modify labels: rollup

Create a similar rollup

tshepang and others added 12 commits February 16, 2023 18:58
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 rustbot added A-meta Area: Issues & PRs about the rust-lang/rust repository itself S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-bootstrap Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap) T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. rollup A PR which is a rollup labels Feb 17, 2023
@matthiaskrgr
Copy link
Member Author

@bors r+ rollup=never p=6

@bors
Copy link
Contributor

bors commented Feb 17, 2023

📌 Commit ae5473c has been approved by matthiaskrgr

It is now in the queue for this repository.

@bors 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 Feb 17, 2023
@bors
Copy link
Contributor

bors commented Feb 17, 2023

⌛ Testing commit ae5473c with merge f722b24...

@bors
Copy link
Contributor

bors commented Feb 17, 2023

☀️ Test successful - checks-actions
Approved by: matthiaskrgr
Pushing f722b24 to master...

@bors bors added the merged-by-bors This PR was explicitly merged by bors. label Feb 17, 2023
@bors bors merged commit f722b24 into rust-lang:master Feb 17, 2023
@rustbot rustbot added this to the 1.69.0 milestone Feb 17, 2023
@rust-timer
Copy link
Collaborator

📌 Perf builds for each rolled up PR:

PR# Perf Build Sha
#108154 3f1664a87e637714bb7c5d0912f64f6f742d0c1a
#108149 5cc148065369492df456f2b1062484a9c24db25d
#108144 2fcba110c0736788d5791d4bff19197a383834aa
#108126 3a825094b6785a43d032b081227ef9a338ee2835
#107956 89394208c043edd910fa6c950968ca75fcf349c0
#107592 65316d8083377a664737d6891e0ce289c4660903

previous master: f4f5fc3e5c

In the case of a perf regression, run the following command for each PR you suspect might be the cause: @rust-timer build $SHA

@rust-timer
Copy link
Collaborator

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:

  • rustc

cc @rust-lang/wg-compiler-performance

Instruction count

This 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.

Cycles

This benchmark run did not return any relevant results for this metric.

@nnethercote
Copy link
Contributor

The bootstrapping perf test failed, which is weird. The last few lines of output with the error:

       [RUSTC-TIMING] getopts test:false 0.481
          Compiling proc_macro v0.0.0 (/home/collector/rustc-perf/rust/library/proc_macro)
       [RUSTC-TIMING] proc_macro test:false 2.640
          Compiling test v0.0.0 (/home/collector/rustc-perf/rust/library/test)
       [RUSTC-TIMING] test test:false 3.324
           Finished release [optimized] target(s) in 33.38s
       thread 'main' panicked at 'failed to copy `/home/collector/rustc-perf/target/release/build` to `/home/collector/rustc-perf/rust/build/x86_64-unknown-linux-gnu/stage0-sysroot/bin/build`: the source path is neither a regular file nor a symlink to a regular file', lib.rs:1419:17
       note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

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.

@matthiaskrgr
Copy link
Member Author

Hm, the next merge commit also lacks any kind of benchmark...
I wonder if https://github.com/rust-lang/rust/pull/107956/files messed up things for the benchmark server somehow.

@lqd
Copy link
Member

lqd commented Feb 17, 2023

Only the bootstrap timings are missing, correct ? Make sure the following is toggled.

image

@matthiaskrgr
Copy link
Member Author

Ugh 😅 could we make it say "No relevant results" instead of "No results" if there are results but that checkbox is not ticket? :/

@Kobzol
Copy link
Contributor

Kobzol commented Feb 19, 2023

Implemented here.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-meta Area: Issues & PRs about the rust-lang/rust repository itself merged-by-bors This PR was explicitly merged by bors. 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-bootstrap Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap) T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.