Rollup of 9 pull requests by matthiaskrgr · Pull Request #93734 · rust-lang/rust (original) (raw)

matthiaskrgr

@jyn514

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.

@bobrippling

@bobrippling

@bobrippling

@bobrippling

@bobrippling

@Mark-Simulacrum

Performing UTF-8 decode outside the JSON module makes more sense in almost all cases.

@yerke

@PatchMixolydic

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.

@inteon

Signed-off-by: Inteon 42113979+inteon@users.noreply.github.com

@yaahc @dtolnay

This should cover a mostly cross-platform subset of supported exit codes.

@bobrippling

@bobrippling

@jyn514

…strap.py

I missed this in rust-lang#89757; it made x.py test src/bootstrap very slow.

@jyn514

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.

@matthiaskrgr

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

@matthiaskrgr

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

let a: Option<(i32,)> = Some(3);

gets the below suggestion:

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.

@matthiaskrgr

@matthiaskrgr

@matthiaskrgr

@matthiaskrgr

…=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.

@matthiaskrgr

…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 fns. 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

@matthiaskrgr

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

@matthiaskrgr

…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

@bors r+ rollup=never p=9

@bors

📌 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

⌛ Testing commit ae6a34c with merge 91f390627c081bf987fe53ac335dbfcb37ea0844...

@rust-log-analyzer

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

@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

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