Skip to content

Conversation

matthiaskrgr
Copy link
Member

Successful merges:

Failed merges:

r? @ghost
@rustbot modify labels: rollup

Create a similar rollup

jyn514 and others added 24 commits August 24, 2021 19:55
This should make it substantially less annoying, and hopefully more people will find it useful. In particular, it will no longer run tidy each time you run `git commit --amend` or rebase a branch. This also warns if you have the old script in pre-commit; see the HACK comment for details.
Performing UTF-8 decode outside the JSON module makes more sense in almost all cases.
It previously pointed to rust-lang#57563, the conglomerate issue for `const fn` (presumably under the feature gate `const_fn`). `const_fn_trait_bounds` weren't mentioned here, so this commit changes its tracking issue to a new one.
Signed-off-by: Inteon <42113979+inteon@users.noreply.github.com>
This should cover a mostly cross-platform subset of supported exit codes.
…strap.py I missed this in rust-lang#89757; it made `x.py test src/bootstrap` very slow.
Previously, rustbuild would give strange errors if you tried to reuse the same build directory under two names: ``` $ mkdir tmp && cd tmp $ ../x.py check Building rustbuild Finished dev [unoptimized] target(s) in 35.27s Checking stage0 std artifacts (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu) ^C $ cd .. $ mv tmp/build build $ ./x.py check Building rustbuild Compiling bootstrap v0.0.0 (/home/jnelson/rust-lang/rust/src/bootstrap) Finished dev [unoptimized] target(s) in 11.18s failed to execute command: "/home/jnelson/rust-lang/rust/tmp/build/x86_64-unknown-linux-gnu/stage0/bin/rustc" "--target" "x86_64-unknown-linux-gnu" "--print" "target-libdir" error: No such file or directory (os error 2) ``` This fixes the error. Reusing the same build directory is useful if you want to test path-things in bootstrap itself, without having to recompile it each time. For good measure, this also reruns the build script when PATH changes.
Make the pre-commit script pre-push instead This should make it substantially less annoying, and hopefully more people will find it useful. In particular, it will no longer run tidy each time you run `git commit --amend` or rebase a branch. This also warns if you have the old script in pre-commit; see the HACK comment for details. r? ``@Mark-Simulacrum`` cc ``@caass``
… r=camelid Suggest 1-tuple parentheses on exprs without existing parens A follow-on from rust-lang#86116, split out from rust-lang#90677. This alters the suggestion to add a trailing comma to create a 1-tuple - previously we would only apply this if the relevant expression was parenthesised. We now make the suggestion regardless of parentheses, which reduces the fragility of the check (w.r.t formatting). e.g. ```rust let a: Option<(i32,)> = Some(3); ``` gets the below suggestion: ```rust let a: Option<(i32,)> = Some((3,)); // ^ ^^ ``` This change also improves the suggestion in other ways, such as by only making the suggestion if the types would match after the suggestion is applied and making the suggestion a multipart suggestion.
Cleanup c_str.rs Some code cleanups in `c_str.rs`. No functional changes. ref: bytecodealliance/rustix#163
Add From<u8> for ExitCode This should cover a mostly cross-platform subset of supported exit codes. We decided to stick with `u8` initially since its the common subset between all platforms that we support (excluding wasm which I think only works with `true` or `false`). Posix is supposed to take i32s, but in practice many unix platforms mask out all but the low 8 bits or in some cases the 8-15th bits. Windows takes a u32 instead of an i32. Bourne-compatible shells also report signals as exitcode 128 + `signal_no`, so there's some ambiguity there when returning exit codes > 127, but it is possible to disambiguate them on the other side so we decided against restricting the possible codes further than to `u8`. ## Related - Detailed analysis of exit code support on various platforms: https://internals.rust-lang.org/t/mini-pre-rfc-redesigning-process-exitstatus/5426 - rust-lang#48711 - rust-lang#43301 - https://rust-lang.zulipchat.com/#narrow/stream/219381-t-libs/topic/Termination.2FExit.20Status.20Stabilization
…etup, r=Mark-Simulacrum Fix linking stage1 toolchain in `./x.py setup` Closes [92319](rust-lang#92319) Fix linking stage1 toolchain in `./x.py setup`. I guess this can be considered a follow up to rust-lang#89212 by ```@Sl1mb0.``` We create 2 directories and 1 file that are required by rustup to [link a custom toolchain from path](https://github.com/rust-lang/rustup/blob/5225e87a5d974ab5f1626bcb2a7b43f76ab883f0/src/toolchain.rs#L479-L497). cc ```@jyn514``` and ```@Mark-Simulacrum``` as they were active in rust-lang#89206
…=bjorn3 Drop json::from_reader Just a small cleanup -- this was essentially unused; the one use site is better suited to reading from &str regardless.
…s-const_fn_trait_bound, r=oli-obk Update tracking issue for `const_fn_trait_bound` It previously pointed to rust-lang#57563, the conglomerate issue for `const fn` (presumably under the feature gate `const_fn`). This tracking issue doesn't mention anything about `const_fn_trait_bound`(the only occurrence of "trait bound" is for the now-removed `?const Trait` syntax), which can be confusing to people who want to find out more about trait bounds on `const fn`s. This pull request changes the tracking issue to one meant specifically for `const_fn_trait_bound`, rust-lang#93706, which can help collect information on this feature's stabilization and point users towards `const_trait_impl` if they're looking for const-in-const-contexts trait bounds. Fixes rust-lang#93679. ```@rustbot``` modify labels +A-const-fn +F-const_trait_impl
…rk-Simulacrum Use shallow clones for submodules managed by rustbuild, not just bootstrap.py I missed this in rust-lang#89757; it made `x.py test src/bootstrap` very slow.
…ulacrum Rerun bootstrap's build script when RUSTC changes Previously, rustbuild would give strange errors if you tried to reuse the same build directory under two names: ``` $ mkdir tmp && cd tmp $ ../x.py check Building rustbuild Finished dev [unoptimized] target(s) in 35.27s Checking stage0 std artifacts (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu) ^C $ cd .. $ mv tmp/build build $ ./x.py check Building rustbuild Compiling bootstrap v0.0.0 (/home/jnelson/rust-lang/rust/src/bootstrap) Finished dev [unoptimized] target(s) in 11.18s failed to execute command: "/home/jnelson/rust-lang/rust/tmp/build/x86_64-unknown-linux-gnu/stage0/bin/rustc" "--target" "x86_64-unknown-linux-gnu" "--print" "target-libdir" error: No such file or directory (os error 2) ``` This fixes the error. Reusing the same build directory is useful if you want to test path-related things in bootstrap itself, without having to recompile it each time. For good measure, this also reruns the build script when PATH changes.
@rustbot rustbot added 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 7, 2022
@matthiaskrgr
Copy link
Member Author

@bors r+ rollup=never p=9

@bors
Copy link
Collaborator

bors commented Feb 7, 2022

📌 Commit ae6a34c has been approved by matthiaskrgr

@bors bors added the S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. label Feb 7, 2022
@bors
Copy link
Collaborator

bors commented Feb 7, 2022

⌛ Testing commit ae6a34c with merge 91f390627c081bf987fe53ac335dbfcb37ea0844...

@rust-log-analyzer
Copy link
Collaborator

The job dist-various-2 failed! Check out the build log: (web) (plain)

Click to see the possible cause of the failure (guessed by this bot)
169 | 1..255 => Self::FAILURE, | ^^^^^^ | = note: see issue #37854 <https://github.com/rust-lang/rust/issues/37854> for more information = help: add `#![feature(exclusive_range_pattern)]` to the crate attributes to enable For more information about this error, try `rustc --explain E0658`. [RUSTC-TIMING] std test:false 1.657 warning: `std` (lib) generated 1 warning error: could not compile `std` due to previous error; 1 warning emitted 
@bors
Copy link
Collaborator

bors commented Feb 7, 2022

💔 Test failed - checks-actions

@bors 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 Feb 7, 2022
@m-ou-se
Copy link
Member

m-ou-se commented Feb 7, 2022

That failure is caused by #93445. Posted a comment there.

@m-ou-se m-ou-se closed this Feb 7, 2022
@matthiaskrgr matthiaskrgr deleted the rollup-376pxvd branch February 13, 2022 00:53
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

rollup A PR which is a rollup 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.