Rust 2018: NLL migrate mode => hard error
As per decision on a language team meeting as described in https://github.com/rust-lang/rust/pull/63565#issuecomment-528563744, we refuse to downgrade NLL errors, that AST borrowck accepts, into warnings and keep them as hard errors.
cc @rust-lang/lang
cc @rust-lang/wg-compiler-nll
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.
Fix invalid span generation when it should be div
Fixes#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
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#61206.
or-patterns: Uniformly use `PatKind::Or` in AST & Fix/Cleanup resolve
Following up on work in https://github.com/rust-lang/rust/pull/63693 and https://github.com/rust-lang/rust/pull/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 https://github.com/rust-lang/rust/issues/54883
cc @dlrobertson @matthewjasper
r? @petrochenkov
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#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.
When encountering a likely intended turbofish without `::`, bubble
up the diagnostic instead of emitting it to allow the parser to recover
more gracefully and avoid uneccessary type errors that are likely to be
wrong.
This moves the two methods from the `EmitterWriter` impl to trait
default methods in the `Emitter` trait so that they can be re-used by
the `AnnotateSnippetEmitterWriter`.
Closes#61810
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.
Not doing this leads to building two copies of e.g. num_cpus in the
sysroot and _llvm deps, leading to conflicts between the two when
compiling librustc_codegen_llvm. It's not entirely clear why this is the
case after the changes in this PR but likely has something to do with a
subtle difference in ordering or similar.
