The enum debuginfo patch includes a legacy mode that is used when
building against LLVM 5 and LLVM 6. The main enum debuginfo tests
have been updated to rely on the new approach and a new-enough gdb.
This patch makes a copy of these tests so that the fallback mode will
continue to be tested.
Note that nil-enum.rs is not copied; it seemed not to provide enough
value to bother.
A new header directive is added, "ignore-llvm-version". I will send a
patch to update the rustc documentation once this lands.
Bug #52452 notes some debuginfo test regressions when moving to gdb
8.1. This series will also cause versions of gdb before 8.2 to fail
when a recent LLVM is used -- DW_TAG_variant_part support was not
added until 8.2.
This patch updates one of the builders to a later version of Ubuntu,
which comes with gdb 8.2. It updates the relevant tests to require
both a new-enough LLVM and a new-enough gdb; the subsequent patch
arranges to continue testing the fallback mode.
The "gdbg" results are removed from these tests because the tests now
require a rust-enabled gdb.
If you read closely, you'll see that some of the lldb results in this
patch still look a bit strange. This will be addressed in a
subsequent patch; I believe the fix is to disable the Python
pretty-printers when lldb is rust-enabled.
Currently lldb tests are run only on macOS, and gdb tests are only run
elsewhere. This patch changes this to run tests depending on what is
available.
One test is changed, as it was previously marked as failing on macOS,
whereas really it is a generic failure with lldb.
Closes#54721
Run debuginfo tests against rust-enabled lldb, when possible
If the rust-enabled lldb was built, then use it when running the
debuginfo tests. Updating the lldb submodule was necessary as this
needed a way to differentiate the rust-enabled lldb, so I added a line
to the --version output.
This adds compiletest commands to differentiate between the
rust-enabled and non-rust-enabled lldb, as is already done for gdb. A
new "rust-lldb" header directive is also added, but not used in this
patch; I plan to use it in #54004.
This updates all the tests.
If the rust-enabled lldb was built, then use it when running the
debuginfo tests. Updating the lldb submodule was necessary as this
needed a way to differentiate the rust-enabled lldb, so I added a line
to the --version output.
This adds compiletest commands to differentiate between the
rust-enabled and non-rust-enabled lldb, as is already done for gdb. A
new "rust-lldb" header directive is also added, but not used in this
patch; I plan to use it in #54004.
This updates all the tests.
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.
This upgrades the OSX builders to the `xcode9.3-moar` image which has 3 cores as
opposed to the 2 that our builders currently have. Should help make those OSX
builds a bit speedier!
A few pretty-printers were returning a quoted string from their
to_string method. It's preferable in gdb to return a lazy string and to
let gdb handle the display by having a "display_hint" method that
returns "string" -- it lets gdb settings (like "set print ...") work, it
handles corrupted strings a bit better, and it passes the information
along to IDEs.
prefer hyphens in test files named after issue numbers
We have a lot of tests with filenames honoring particular issues by
number. Typically, these are called issue-${issue_no}.rs (note the
hyphen):
```
$ find . -regextype posix-egrep -regex '.*/issue-[0-9]*.rs' | wc
1289 1289 35935
```
We also had a much smaller number of files that are like this, but don't
have a hyphen in between the substring `issue` and the number:
```
$ find . -regextype posix-egrep -regex '.*/issue[0-9]*.rs'
./debuginfo/issue14411.rs
./debuginfo/issue12886.rs
./debuginfo/issue13213.rs
./debuginfo/issue22656.rs
./debuginfo/issue7712.rs
./compile-fail/issue32829.rs
./run-pass/issue24353.rs
./run-pass/issue34796.rs
./run-pass/issue18173.rs
./run-pass/issue22346.rs
./run-pass/auxiliary/issue13507.rs
./run-pass/issue26127.rs
./run-pass/issue22008.rs
./run-pass/issue34569.rs
./run-pass/issue29927.rs
./run-pass/issue36260.rs
```
Some would argue that the inconsistency is æsthetically displeasing,
hence this trivial patch. (Note that run-pass/auxiliary/issue13507.rs
has an excuse; it's `use`d in run-pass/issue-13507-2.rs; the matter of
there being two different compile-fail tests with different name
conventions for issue no. 32829 is also neglected here for the sake of
keeping this trivial cleanup patch as trivial as possible for ease of
review.)
Fix debuginfo for unsized struct members
The member was given the size of a fat pointer, which caused
llvm to emit DWARF attributes for a 128-bit bitfield.
The current image is `xcode7.3`, Travis's current default. Unfortunately this
has a version of LLDB which doesn't support debuginfo-lldb tests (see #32520),
so we're not running LLDB tests on Travis yet.
This switches us to the newest image from Travis, `xcode8.2`, which should have
a newer version of LLDB we can run tests against.
We have a lot of tests with filenames honoring particular issues by
number. Typically, these are called issue-${issue_no}.rs (note the
hyphen):
```
$ find . -regextype posix-egrep -regex '.*/issue-[0-9]*.rs' | wc
1289 1289 35935
```
We also had a much smaller number of files that are like this, but don't
have a hyphen in between the substring `issue` and the number:
```
$ find . -regextype posix-egrep -regex '.*/issue[0-9]*.rs'
./debuginfo/issue14411.rs
./debuginfo/issue12886.rs
./debuginfo/issue13213.rs
./debuginfo/issue22656.rs
./debuginfo/issue7712.rs
./compile-fail/issue32829.rs
./run-pass/issue24353.rs
./run-pass/issue34796.rs
./run-pass/issue18173.rs
./run-pass/issue22346.rs
./run-pass/auxiliary/issue13507.rs
./run-pass/issue26127.rs
./run-pass/issue22008.rs
./run-pass/issue34569.rs
./run-pass/issue29927.rs
./run-pass/issue36260.rs
```
Some would argue that the inconsistency is æsthetically displeasing,
hence this trivial patch. (Note that run-pass/auxiliary/issue13507.rs
has an excuse; it's `use`d in run-pass/issue-13507-2.rs; the matter of
there being two different compile-fail tests with different name
conventions for issue #32829 is also neglected here for the sake of
keeping this trivial cleanup patch as trivial as possible for ease of
review.)
This commit configures our `.travis.yml` to test the full suite of tests we have
on Buildbot right now. A whole mess of docker images are added to the `src/ci`
directory which represent all the build environments for each configuration.
Each of these environments is then configured in `.travis.yml` to run on the
auto branch.
Note that the full matrix of tests aren't intended to be run on all PRs.
Instead, we continue to run only one entry in the matrix, forcing all others to
finish quickly. Only the `auto` branch should run the full matrix of builds.
Also note that the infrastructure hasn't quite been allocated yet to the
rust-lang/rust repository, so everything is disabled for now except for the one
build that happens on PRs. Once that infrastructure is allocated though we can
enable this and let it fly!
Notable modifications from the current test suite today:
* Android tests are run in rustbuild instead of the makefiles, for whatever
reason I couldn't get the makefiles to work on Travis.
* A debuginfo test was updated to work with the current version of the Android
NDK.
* Some dependencies in `mk/tests.mk` were fixed to allow running tests in
parallel.
Most of the Rust community agrees that the vec! macro is clearer when
called using square brackets [] instead of regular brackets (). Most of
these ocurrences are from before macros allowed using different types of
brackets.
There is one left unchanged in a pretty-print test, as the pretty
printer still wants it to have regular brackets.
Attribute drop code to block's closing brace, instead of the line where the allocation was done.
Attribute function epilogues to function body's closing brace, rather than the function header.
