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 18 pull requests #89540

Closed
wants to merge 44 commits into from

Conversation

Manishearth
Copy link
Member

Successful merges:

Failed merges:

r? @ghost
@rustbot modify labels: rollup

Create a similar rollup

AGSaidi and others added 30 commits September 4, 2021 15:11
…rch64

aarch64 prior to v8.4 (FEAT_LSE2) doesn't have an instruction that guarantees
untorn 128b reads except for completing a 128b load/store exclusive pair
(ldxp/stxp) or compare-and-swap (casp) successfully. The requirement to
complete a 128b read+write atomic is actually more expensive and more unfair
than the previous implementation of monotonize() which used a Mutex on aarch64,
especially at large core counts.  For aarch64 switch to the 64b atomic
implementation which is about 13x faster for a benchmark that involves many
calls to Instant::now().
The wrapper is installed as `ld` and `ld64` in `lib\rustlib\<host_target>\bin\gcc-ld` directory and its sole purpose is to invoke `rust-lld` in the parent directory with the correct flavor.
Supertraits of specialization markers could circumvent checks for
min_specialization. Elaborating predicates prevents this.
Keys can be reconstructed from fingerprints that are not DefPathHash, but then
we cannot extract a DefId from them.
The previous macro_rules! parsers failed when an additional modifier was added
with ambiguity errors. The error is pretty unclear as to what exactly the cause
here is, but this change simplifies the argument parsing code such that the
error is avoided.
As the docs at the top of the file say, it is an overloaded pass and
actually runs two lints.
Fixed numerus of error message

Removed superfluous argument

Using pluralize!() instead of code duplication

Adjusted a test
…htriplett

Stabilize try_reserve

Stabilization PR for the [`try_reserve` feature](rust-lang#48043 (comment)).
…4, r=dtolnay

Use the 64b inner:monotonize() implementation not the 128b one for aarch64

aarch64 prior to v8.4 (FEAT_LSE2) doesn't have an instruction that guarantees
untorn 128b reads except for completing a 128b load/store exclusive pair
(ldxp/stxp) or compare-and-swap (casp) successfully. The requirement to
complete a 128b read+write atomic is actually more expensive and more unfair
than the previous implementation of monotonize() which used a Mutex on aarch64,
especially at large core counts.  For aarch64 switch to the 64b atomic
implementation which is about 13x faster for a benchmark that involves many
calls to Instant::now().
path.push() should work as expected on windows verbatim paths

On Windows, std::fs::canonicalize() returns an so-called UNC path.  UNC paths differ with regular paths because:

- This type of path can much longer than a non-UNC path (32k vs 260 characters).
- The prefix for a UNC path is ``Component::Prefix(Prefix::DiskVerbatim(..)))``
- No `/` is allowed
- No `.` is allowed
- No `..` is allowed

Rust has poor handling of such paths. If you join a UNC path with a path with any of the above, then this will not work.

I've implemented a new method `fn join_fold()` which joins paths and also removes any `.` and `..` from it, and replaces `/` with `\` on Windows. Using this function it is possible to use UNC paths without issue. In addition, this function is useful on Linux too; paths can be appended without having to call `canonicalize()` to remove the `.` and `..`.

This PR needs test cases, which can I add. I hope this will a start of a discussion.
…ulacrum

Wrapper for `-Z gcc-ld=lld` to invoke rust-lld with the correct flavor

This PR adds an `lld-wrapper` tool which is installed as `ld` and `ld64` in `lib\rustlib\<host_target>\bin\gcc-ld` directory and whose sole purpose is to invoke `rust-lld` in the parent directory with the correct flavor. Lld decides which flavor to use from either the first two commandline arguments or from the name of the executable (`ld` for GNU/ld flavor, `ld64` for Darwin/Macos/ld64 flavor and so on). Symbolic links could not be used as they are not supported by rustup and on Windows.

The wrapper replaces full copies of rust-lld which added some significant bloat. On UNIXish operating systems it exec rust-lld, on Windows it spawns it as a child process.

Fixes rust-lang#88869.

r? `@Mark-Simulacrum`
cc `@nagisa` `@petrochenkov` `@1000teslas`
…cjgillot

Refactor fingerprint reconstruction

This PR replaces can_reconstruct_query_key with fingerprint_style, which returns the style of the fingerprint for that query. This allows us to avoid trying to extract a DefId (or equivalent) from keys which *are* reconstructible because they're () but not as DefIds.

This is done with the goal of fixing -Zdump-dep-graph, which seems to have broken a while ago (I didn't try to bisect). Currently even on a `fn main() {}` file it'll ICE (you need to also pass -Zquery-dep-graph for it to work at all), and this patch indirectly fixes the cause of that ICE. This also adds a test for it continuing to work.
…komatsakis

Correctly handle supertraits for min_specialization

Supertraits of specialization markers could circumvent checks for
min_specialization. Elaborating predicates prevents this.

r? `@nikomatsakis`
Update to the final LLVM 13.0.0 release
…-obk

Fix bug with query modifier parsing

The previous macro_rules! parsers failed when an additional modifier was added
with ambiguity errors. The error is pretty unclear as to what exactly the cause
here is, but this change simplifies the argument parsing code such that the
error is avoided.

Extracted from other work, and somewhat duplicates 0358edeb5 from rust-lang#85830, but
this approach seems a little simpler to me. Not technically currently necessary but seems
like a good cleanup.
…lett

Fix extra `non_snake_case` warning for shorthand field bindings

Fixes rust-lang#89469. The problem is the innermost `if` condition here:
https://github.com/rust-lang/rust/blob/d14731cb3ced8318d7fc83cbe838f0e7f2fb3b40/compiler/rustc_lint/src/nonstandard_style.rs#L435-L452

This code runs for every `PatKind::Binding`, so if a struct has multiple fields, say A and B, and both are bound in a pattern using shorthands, the call to `self.check_snake_case()` will indeed be skipped in the `check_pat()` call for `A`; but when `check_pat()` is called for `B`, the loop will still iterate over `A`, and `field.ident (= A) != ident (= B)` will be true. I have fixed this by only looking at non-shorthand bindings, and only the binding that `check_pat()` was actually called for.
rustdoc: Improve doctest pass's name and module's name

As the docs at the top of the file say, it is an overloaded pass and
actually runs two lints.
Fixed numerus of error message

When there are redundant trait requirements and these are hidden, a message is generated by the following code snippet:
`format!("{} redundant requirements hidden", count)`
But if there is only a single hidden requirement, it will still print this message in plural instead of singular.
…ckh726

Add test for issue 89118.

This PR adds a test for issue 89118.

Closes rust-lang#89118.
…nkov

Try to recover from a `=>` -> `=` or `->` typo in a match arm

Fixes rust-lang#89396.
update Miri

Let's get the recent fixes and improvements shipped.
r? `@ghost`
@rustbot rustbot added the rollup A PR which is a rollup label Oct 5, 2021
@Manishearth
Copy link
Member Author

@bors r+ p=5

@bors
Copy link
Contributor

bors commented Oct 5, 2021

📌 Commit 11580d9 has been approved by Manishearth

@bors
Copy link
Contributor

bors commented Oct 5, 2021

🌲 The tree is currently closed for pull requests below priority 4. This pull request will be tested once the tree is reopened.

@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 Oct 5, 2021
@bors
Copy link
Contributor

bors commented Oct 5, 2021

⌛ Testing commit 11580d9 with merge 9256860e4c92f2b1f45f36e009444dbf6c2646c7...

@rust-log-analyzer
Copy link
Collaborator

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

Click to see the possible cause of the failure (guessed by this bot)
Building stage0 tool lld-wrapper (x86_64-unknown-linux-gnu)
   Compiling lld-wrapper v0.1.0 (/checkout/src/tools/lld-wrapper)
[RUSTC-TIMING] lld_wrapper test:false 0.319
    Finished release [optimized] target(s) in 0.61s
[TIMING] ToolBuild { compiler: Compiler { stage: 0, host: TargetSelection { triple: "x86_64-unknown-linux-gnu", file: None } }, target: TargetSelection { triple: "x86_64-unknown-linux-gnu", file: None }, tool: "lld-wrapper", path: "src/tools/lld-wrapper", mode: ToolBootstrap, is_optional_tool: false, source_type: InTree, extra_features: ["ld"] } -- 0.622
[TIMING] LldWrapper { compiler: Compiler { stage: 0, host: TargetSelection { triple: "x86_64-unknown-linux-gnu", file: None } }, target: TargetSelection { triple: "x86_64-unknown-linux-gnu", file: None }, flavor_feature: "ld" } -- 0.000
Building stage0 tool lld-wrapper (x86_64-unknown-linux-gnu)
   Compiling lld-wrapper v0.1.0 (/checkout/src/tools/lld-wrapper)
[RUSTC-TIMING] lld_wrapper test:false 0.321
    Finished release [optimized] target(s) in 0.46s
[TIMING] ToolBuild { compiler: Compiler { stage: 0, host: TargetSelection { triple: "x86_64-unknown-linux-gnu", file: None } }, target: TargetSelection { triple: "x86_64-unknown-linux-gnu", file: None }, tool: "lld-wrapper", path: "src/tools/lld-wrapper", mode: ToolBootstrap, is_optional_tool: false, source_type: InTree, extra_features: ["ld64"] } -- 0.477
[TIMING] LldWrapper { compiler: Compiler { stage: 0, host: TargetSelection { triple: "x86_64-unknown-linux-gnu", file: None } }, target: TargetSelection { triple: "x86_64-unknown-linux-gnu", file: None }, flavor_feature: "ld64" } -- 0.000
[TIMING] StartupObjects { compiler: Compiler { stage: 1, host: TargetSelection { triple: "x86_64-unknown-linux-gnu", file: None } }, target: TargetSelection { triple: "x86_64-unknown-freebsd", file: None } } -- 0.000
Building sanitizers for x86_64-unknown-freebsd
running: "cmake" "/checkout/src/llvm-project/compiler-rt" "-G" "Ninja" "-DCMAKE_C_COMPILER_TARGET=x86_64-unknown-freebsd" "-DCOMPILER_RT_BUILD_BUILTINS=OFF" "-DCOMPILER_RT_BUILD_CRT=OFF" "-DCOMPILER_RT_BUILD_LIBFUZZER=OFF" "-DCOMPILER_RT_BUILD_PROFILE=OFF" "-DCOMPILER_RT_BUILD_SANITIZERS=ON" "-DCOMPILER_RT_BUILD_XRAY=OFF" "-DCOMPILER_RT_DEFAULT_TARGET_ONLY=ON" "-DCOMPILER_RT_USE_LIBCXX=OFF" "-DLLVM_CONFIG_PATH=/checkout/obj/build/x86_64-unknown-linux-gnu/llvm/build/bin/llvm-config" "-DCMAKE_INSTALL_MESSAGE=LAZY" "-DCMAKE_SYSTEM_NAME=FreeBSD" "-DCMAKE_C_COMPILER_LAUNCHER=sccache" "-DCMAKE_CXX_COMPILER_LAUNCHER=sccache" "-DCMAKE_C_COMPILER=x86_64-unknown-freebsd11-clang" "-DCMAKE_CXX_COMPILER=x86_64-unknown-freebsd11-clang++" "-DCMAKE_ASM_COMPILER=x86_64-unknown-freebsd11-clang" "-DCMAKE_C_FLAGS=-ffunction-sections -fdata-sections -fPIC --target=x86_64-unknown-freebsd" "-DCMAKE_CXX_FLAGS=-ffunction-sections -fdata-sections -fPIC --target=x86_64-unknown-freebsd -static-libstdc++" "-DCMAKE_INSTALL_PREFIX=/checkout/obj/build/x86_64-unknown-freebsd/native/sanitizers" "-DCMAKE_ASM_FLAGS= -ffunction-sections -fdata-sections -fPIC --target=x86_64-unknown-freebsd" "-DCMAKE_BUILD_TYPE=Release"
-- The C compiler identification is Clang 6.0.0
---
Building stage0 tool lld-wrapper (x86_64-unknown-freebsd)
   Compiling lld-wrapper v0.1.0 (/checkout/src/tools/lld-wrapper)
error[E0463]: can't find crate for `std`
  |
  = note: the `x86_64-unknown-freebsd` target may not be installed
  = help: consider downloading the target with `rustup target add x86_64-unknown-freebsd`
  = help: consider building the standard library from source with `cargo build -Zbuild-std`
For more information about this error, try `rustc --explain E0463`.
[RUSTC-TIMING] lld_wrapper test:false 0.037
[RUSTC-TIMING] lld_wrapper test:false 0.037
error: could not compile `lld-wrapper` due to previous error

@bors
Copy link
Contributor

bors commented Oct 5, 2021

💔 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 Oct 5, 2021
@camelid
Copy link
Member

camelid commented Oct 5, 2021

I'm not certain, but I think it's likely the failure is due to #89288.

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.
Projects
None yet
Development

Successfully merging this pull request may close these issues.