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 13 pull requests #64200

Closed

Conversation

Mark-Simulacrum
Copy link
Member

Successful merges:

Failed merges:

r? @ghost

newpavlov and others added 30 commits August 19, 2019 09:47
LLDB's expression parser can't unambiguously resolve local variables in
some cases, as described in rust-lang#47938. Work around this by using names that
don't shadow direct submodules of `core`.
Rustbuild usually writes the LLVM submodule commit in a stamp file, so
we can avoid rebuilding it unnecessarily. However, for builds from a
source tarball (non-git), we were assuming a rebuild is always needed.
This can cause a lot of extra work if any environment like `CFLAGS`
changed between steps like build and install, which are often separate
in distro builds.

Now we also write an empty stamp file if the git commit is unknown, and
its presence is trusted to indicate that no rebuild is needed. An info
message reports that this is happening, along with the stamp file path
that can be deleted to force a rebuild anyway.
GuillaumeGomez and others added 17 commits September 5, 2019 14:15
This commit rejiggers the generics used in the implementation of
`Command::env` with the purpose of reducing the amount of codegen that
needs to happen in consumer crates, instead preferring to generate code
into libstd.

This was found when profiling the compile times of the `cc` crate where
the binary rlib produced had a lot of `BTreeMap` code compiled into it
but the crate doesn't actually use `BTreeMap`. It turns out that
`Command::env` is generic enough to codegen the entire implementation in
calling crates, but in this case there's no performance concern so it's
fine to compile the code into the standard library.

This change is done by removing the generic on the `CommandEnv` map
which is intended to handle case-insensitive variables on Windows.
Instead now a generic isn't used but rather a `use` statement defined
per-platform is used.

With this commit a debug build of `Command::new("foo").env("a", "b")`
drops from 21k lines of LLVM IR to 10k.
We publish this to crates.io, so having non-empty meta is useful
Fuchsia provides a fully monotonic clock.
…050, r=alexcrichton

Rename test locals to work around LLDB bug

LLDB's expression parser can't unambiguously resolve local variables in
some cases, as described in rust-lang#47938. Work around this by using names that
don't shadow direct submodules of `core`.

Closes rust-lang#64050.
…umeGomez

Improve searching in rustdoc and add tests

👋 I have made searching in rustdoc more intuitive, added a couple more tests and made a little shell script to aid testing. Closes rust-lang#63005.

It took me quite a while to figure out how to run the tests for rustdoc (instead of running tests for other crates with rustdoc); the only pointer I found was [hidden in the rustc book](https://rust-lang.github.io/rustc-guide/rustdoc.html#cheat-sheet). Maybe this could be better documented? I shall be delighted to help if it is desirable.
…ark-Simulacrum

Fix regex replacement in theme detection

Fixes rust-lang#64061.

This is sadly a lot of bad luck: after making the changes and re-build the docs, I just forgot to force reload the page. Hence having the old (working) version with two replacements instead of the failing regex. Sorry again about that...

cc @fenhl
r? @Mark-Simulacrum
…ochenkov

or-patterns: Uniformly use `PatKind::Or` in AST & Fix/Cleanup resolve

Following up on work in rust-lang#63693 and rust-lang#61708, in this PR we:

- Uniformly use `PatKind::Or(...)` in AST:

   - Change `ast::Arm.pats: Vec<P<Pat>>` => `ast::Arm.pat: P<Pat>`

   - Change `ast::ExprKind::Let.0: Vec<P<Pat>>` => `ast::ExprKind::Let.0: P<Pat>`

- Adjust `librustc_resolve/late.rs` to correctly handle or-patterns at any level of nesting as a result.

  In particular, the already-bound check which rejects e.g. `let (a, a);` now accounts for or-patterns. The consistency checking (ensures no missing bindings and binding mode consistency) also now accounts for or-patterns. In the process, a bug was found in the current compiler which allowed:

   ```rust
   enum E<T> { A(T, T), B(T) }
   use E::*;
   fn foo() {
       match A(0, 1) {
           B(mut a) | A(mut a, mut a) => {}
       }
   }
   ```

   The new algorithms took a few iterations to get right. I tried several clever schemes but ultimately a version based on a stack of hashsets and recording product/sum contexts was chosen since it is more clearly correct.

- Clean up `librustc_resolve/late.rs` by, among other things, using a new `with_rib` function to better ensure stack dicipline.

- Do not push the change in AST to HIR for now to avoid doing too much in this PR. To cope with  this, we introduce a temporary hack in `rustc::hir::lowering` (clearly marked in the diff).

cc rust-lang#54883
cc @dlrobertson @matthewjasper
r? @petrochenkov
Assume non-git LLVM is fresh if the stamp file exists

Rustbuild usually writes the LLVM submodule commit in a stamp file, so
we can avoid rebuilding it unnecessarily. However, for builds from a
source tarball (non-git), we were assuming a rebuild is always needed.
This can cause a lot of extra work if any environment like `CFLAGS`
changed between steps like build and install, which are often separate
in distro builds.

Now we also write an empty stamp file if the git commit is unknown, and
its presence is trusted to indicate that no rebuild is needed. An info
message reports that this is happening, along with the stamp file path
that can be deleted to force a rebuild anyway.

Fixes rust-lang#61206.
Better way of conditioning the sanitizer builds

Previously the build would take the presence of the LLVM_CONFIG envvar to
mean that the sanitizers should be built, but this is a common envvar that
could be set for reasons unrelated to the rustc sanitizers.

This commit adds a new envvar RUSTC_BUILD_SANITIZERS and uses it instead.

This PR or similar will be necessary in order to work correctly with rust-lang/compiler-builtins#296
…-should-be-div, r=Mark-Simulacrum

Fix invalid span generation when it should be div

Fixes rust-lang#64146.

It changes basically nothing in the display... Can be checked with:

```rust
pub enum X {
    /// Some doc?
    ///
    /// with lines!
    Foo {
        /// a
        ///
        /// b
        x: u32,
        /// Doc!
        ///
        /// ```
        /// yolo
        /// ```
        y: String,
    },
    /// Doc!
    ///
    /// ```
    /// yolo
    /// ```
    Bar(String),
}
```

r? @Mark-Simulacrum
…=sfackler

std: Improve downstream codegen in `Command::env`

This commit rejiggers the generics used in the implementation of
`Command::env` with the purpose of reducing the amount of codegen that
needs to happen in consumer crates, instead preferring to generate code
into libstd.

This was found when profiling the compile times of the `cc` crate where
the binary rlib produced had a lot of `BTreeMap` code compiled into it
but the crate doesn't actually use `BTreeMap`. It turns out that
`Command::env` is generic enough to codegen the entire implementation in
calling crates, but in this case there's no performance concern so it's
fine to compile the code into the standard library.

This change is done by removing the generic on the `CommandEnv` map
which is intended to handle case-insensitive variables on Windows.
Instead now a generic isn't used but rather a `use` statement defined
per-platform is used.

With this commit a debug build of `Command::new("foo").env("a", "b")`
drops from 21k lines of LLVM IR to 10k.
fill metadata in rustc_lexer's Cargo.toml

We publish this to crates.io, so having non-empty meta is useful
…richton

Add Fuchsia to actually_monotonic

Fuchsia provides a fully monotonic clock.

Fix rust-lang#64196

cc @joshlf @tmandry

r? @alexcrichton
@Mark-Simulacrum
Copy link
Member Author

@bors r+ p=10

@bors
Copy link
Contributor

bors commented Sep 6, 2019

📌 Commit 16ee07e has been approved by Mark-Simulacrum

@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 Sep 6, 2019
@bors
Copy link
Contributor

bors commented Sep 6, 2019

⌛ Testing commit 16ee07e with merge ffc7f1906de96c4343128baac1098098385ed416...

@rust-highfive
Copy link
Collaborator

The job LinuxTools of your PR failed (raw log). Through arcane magic we have determined that the following fragments from the build log may contain information about the problem.

Click to expand the log.
2019-09-06T00:57:26.8269972Z ##[command]git remote add origin https://github.com/rust-lang/rust
2019-09-06T00:57:26.8448965Z ##[command]git config gc.auto 0
2019-09-06T00:57:26.8496798Z ##[command]git config --get-all http.https://github.com/rust-lang/rust.extraheader
2019-09-06T00:57:26.8550825Z ##[command]git config --get-all http.proxy
2019-09-06T00:57:26.8677935Z ##[command]git -c http.extraheader="AUTHORIZATION: basic ***" fetch --force --tags --prune --progress --no-recurse-submodules --depth=2 origin +refs/heads/*:refs/remotes/origin/* +refs/pull/64200/merge:refs/remotes/pull/64200/merge
---
2019-09-06T02:57:41.3317069Z Verifying status of rustfmt...
2019-09-06T02:57:41.3329862Z Verifying status of clippy-driver...
2019-09-06T02:57:41.3344150Z This PR updated 'src/tools/clippy', verifying if status is 'test-pass'...
2019-09-06T02:57:41.3354560Z 
2019-09-06T02:57:41.3355184Z ⚠️ We detected that this PR updated 'clippy-driver', but its tests failed.
2019-09-06T02:57:41.3355349Z 
2019-09-06T02:57:41.3355868Z If you do intend to update 'clippy-driver', please check the error messages above and
2019-09-06T02:57:41.3355916Z commit another update.
2019-09-06T02:57:41.3355938Z 
2019-09-06T02:57:41.3356571Z If you do NOT intend to update 'clippy-driver', please ensure you did not accidentally
2019-09-06T02:57:41.3356887Z change the submodule at 'src/tools/clippy'. You may ask your reviewer for the
2019-09-06T02:57:41.3356939Z proper steps.
2019-09-06T02:57:41.3384243Z   local time: Fri Sep  6 02:57:41 UTC 2019
2019-09-06T02:57:41.4241501Z   network time: Fri, 06 Sep 2019 02:57:41 GMT
2019-09-06T02:57:41.4247069Z == end clock drift check ==
2019-09-06T02:57:41.4247069Z == end clock drift check ==
2019-09-06T02:57:42.9844363Z ##[error]Bash exited with code '3'.
2019-09-06T02:57:42.9886234Z ##[section]Starting: Checkout
2019-09-06T02:57:42.9889019Z ==============================================================================
2019-09-06T02:57:42.9889082Z Task         : Get sources
2019-09-06T02:57:42.9889133Z Description  : Get sources from a repository. Supports Git, TfsVC, and SVN repositories.

I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact @TimNN. (Feature Requests)

@bors
Copy link
Contributor

bors commented Sep 6, 2019

💔 Test failed - checks-azure

@rust-highfive
Copy link
Collaborator

The job x86_64-gnu-tools of your PR failed (raw log). Through arcane magic we have determined that the following fragments from the build log may contain information about the problem.

Click to expand the log.
2019-09-06T03:04:06.6337005Z Verifying status of rustfmt...
2019-09-06T03:04:06.6350954Z Verifying status of clippy-driver...
2019-09-06T03:04:06.6364908Z This PR updated 'src/tools/clippy', verifying if status is 'test-pass'...
2019-09-06T03:04:06.6377639Z 
2019-09-06T03:04:06.6378313Z ⚠️ We detected that this PR updated 'clippy-driver', but its tests failed.
2019-09-06T03:04:06.6378387Z 
2019-09-06T03:04:06.6378742Z If you do intend to update 'clippy-driver', please check the error messages above and
2019-09-06T03:04:06.6379283Z commit another update.
2019-09-06T03:04:06.6379336Z 
2019-09-06T03:04:06.6379781Z If you do NOT intend to update 'clippy-driver', please ensure you did not accidentally
2019-09-06T03:04:06.6380140Z change the submodule at 'src/tools/clippy'. You may ask your reviewer for the
2019-09-06T03:04:06.6380253Z proper steps.
2019-09-06T03:04:06.6399370Z   local time: Fri Sep  6 03:04:06 UTC 2019
2019-09-06T03:04:06.7292925Z   network time: Fri, 06 Sep 2019 03:04:06 GMT
2019-09-06T03:04:06.7293596Z == end clock drift check ==
2019-09-06T03:04:06.7293596Z == end clock drift check ==
2019-09-06T03:04:08.3906915Z ##[error]Bash exited with code '3'.
2019-09-06T03:04:08.3954575Z ##[section]Starting: Upload CPU usage statistics
2019-09-06T03:04:08.3963373Z ==============================================================================
2019-09-06T03:04:08.3963480Z Task         : Bash
2019-09-06T03:04:08.3963578Z Description  : Run a Bash script on macOS, Linux, or Windows

I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact @TimNN. (Feature Requests)

@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 Sep 6, 2019
@mati865 mati865 mentioned this pull request Sep 6, 2019
@Centril Centril closed this Sep 6, 2019
@Centril Centril added the rollup A PR which is a rollup label Oct 24, 2019
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.