Uh oh!
There was an error while loading. Please reload this page.
Rollup of 13 pull requests - #64200
Closed
Mark-Simulacrum wants to merge 74 commits into
Closed
Conversation
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.
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.
Use wasi crate for Core API Blocked by: bytecodealliance/wasi-rs#5 Blocks: rust-lang/libc#1461 cc @sunfishcode@alexcrichton
Update libc to 0.2.62 Hopefully this will mitigate rust-lang/libc#1489 and rust-lang#64006
…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`. Closesrust-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. Closesrust-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 Fixesrust-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. Fixesrust-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 Fixesrust-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. Fixrust-lang#64196 cc @joshlf@tmandry r? @alexcrichton
Mark-Simulacrum
commented
Sep 6, 2019
MemberAuthor
@bors r+ p=10 |
bors
commented
Sep 6, 2019
Collaborator
📌 Commit 16ee07e has been approved by |
bors
commented
Sep 6, 2019
Collaborator
⌛ Testing commit 16ee07e with merge ffc7f1906de96c4343128baac1098098385ed416... |
rust-highfive
commented
Sep 6, 2019
Contributor
The job Click to expand the log.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 |
bors
commented
Sep 6, 2019
Collaborator
💔 Test failed - checks-azure |
rust-highfive
commented
Sep 6, 2019
Contributor
The job Click to expand the log.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 |
Merged
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for freeto join this conversation on GitHub.
Already have an account?
Sign in to comment
15 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Successful merges:
PatKind::Orin AST & Fix/Cleanup resolve #64111 (or-patterns: Uniformly usePatKind::Orin AST & Fix/Cleanup resolve)Command::env#64186 (std: Improve downstream codegen inCommand::env)Failed merges:
r? @ghost