improve diagnostics for tests with custom return values
This is an attempt at getting the ball rolling to improve the diagnostics for test functions that return custom `impl Termination` values (see #52436).
An alternative could be to use `eprintln!`, but including this in the panic message felt nicely consistent with how failing test assertions would be reported.
Let me know what you think!
In `librustc_apfloat/ieee.rs`, use the iterator.[r]find methods to
simplify the code. In `libserialize/json.rs`, make use of the fact
that `Vec.last` on an empty `Vec` returns `None` to simplify the
code to a single match.
Add lldb to the build
This optionally adds lldb (and clang, which it needs) to the build.
Because rust uses LLVM 7, and because clang 7 is not yet released, a
recent git master version of clang is used.
The lldb that is used includes the Rust plugin.
lldb is only built when asked for, or when doing a nightly build on
macOS. Only macOS is done for now due to difficulties with the Python
dependency.
This optionally adds lldb (and clang, which it needs) to the build.
Because rust uses LLVM 7, and because clang 7 is not yet released, a
recent git master version of clang is used.
The lldb that is used includes the Rust plugin.
lldb is only built when asked for, or when doing a nightly build on
macOS. Only macOS is done for now due to difficulties with the Python
dependency.
(old) borrowck cleanup
Primarily moves dataflow code based on CFG to borrowck; this is mostly so we don't forget to delete it once it becomes unused after we fully move to MIR borrowck.
Idiomatic improvements to IP method
Since match ergonomics and slice patterns are stable this might be more idiomatic modern Rust implementations of these methods? Or well, slice patterns with `..` are not stabilized yet, so maybe we want to specify all fields but with `_`?
A few cleanups
- change `skip(1).next()` to `nth(1)`
- collapse some `if-else` expressions
- remove a few explicit `return`s
- remove an unnecessary field name
- dereference once instead of matching on multiple references
- prefer `iter().enumerate()` to indexing with `for`
- remove some unnecessary lifetime annotations
- use `writeln!()` instead of `write!()`+`\n`
- remove redundant parentheses
- shorten some enum variant names
- a few other cleanups suggested by `clippy`
rustc_codegen_llvm: Restore the closure env alloca hack for LLVM 5.
This hack was removed in #50949, but without it I found that building
`std` with full debuginfo would print many LLVM `DW_OP_LLVM_fragment`
errors, then die `LLVM ERROR: Failed to strip malformed debug info`.
It doesn't seem to be a problem for LLVM 6, so we can re-enable the hack
just for older LLVM.
This reverts commit da579ef75e.
Fixes#53204.
r? @eddyb
Make sure rlimit is only ever increased
`libc::setrlimit` will fail if we try to set the rlimit to a value lower than it is currently, so make sure we're never trying to do this. Fixes#52801.
driver: set the syntax edition in phase 1
Fixes https://github.com/rust-lang/rust/issues/53203
It seems the way libsyntax handles the desired edition is to use a global, set via `syntax_pos::hygiene::set_default_edition`. Right now, this is set in the driver in `run_compiler`, which is the entry point for running the compiler all the way through to emitting files. Since rustdoc doesn't use this function, it wasn't properly setting this global. (When initially setting up editions in rustdoc, i'd assumed that setting `sessopts.edition` would have done this... `>_>`) This was "fixed" for doctests in https://github.com/rust-lang/rust/pull/52385, but rather than patching in a call to `set_default_edition` in all the places rustdoc sets up the compiler, i've instead moved the call in the driver to be farther in the process. This means that any use of `phase_1_parse_input` with the right session options will have the edition properly set without having to also remember to set libsyntax up separately.
r? @rust-lang/compiler
Don't panic on std::env::vars() when env is null.
Fixes#53200.
Reviewer(s):
* Do I need to do any `#[cfg()]` here?
* Is this use of libc ok for a dev-dependency?
pretty print BTreeSet
I want pretty printing for BTreeSet.
```rust
use std::collections::*;
fn main() {
let mut s = BTreeSet::new();
s.insert(5);
s.insert(3);
s.insert(7);
s.remove(&3);
println!("{:?}", s);
}
```
```
(gdb) b 9
(gdb) p s
$1 = BTreeSet<i32> with 2 elements = {[0] = 5, [1] = 7}
```
This is analogy of pretty printing for C++ std::set.
Move SmallVector and ThinVec out of libsyntax
- move `libsyntax::util::SmallVector` tests to `librustc_data_structures::small_vec`
- remove `libsyntax::util::SmallVector`
- move `libsyntax::util::thin_vec` to `librustc_data_structures::thin_vec`
Other than moving these data structures where they belong it allows modules using `SmallVector<T>` (`SmallVec<[T; 1]>`) to specify their own length (e.g. 8 or 32) independently from `libsyntax`.
rustc_resolve: crates only exist in the type namespace.
Fixes#53333 by resolving `::crate_name` in `TypeNS` alone, which was overlooked in #52923 and didn't break tests, since having `use crate_name;` and a `crate_name` value in the same scope is rare.
