fixed some clippy warnings in compiletest
This is mainly readability stuff. Whenever the `clone_ref` lint asked me to clone the dereferenced object, I removed the `.clone()` instead, relying on the fact that it has worked so far and the immutable borrow ensures that the value won't change.
add `allow_fail` test attribute
This change allows the user to add an `#[allow_fail]` attribute to
tests that will cause the test to compile & run, but if the test fails
it will not cause the entire test run to fail. The test output will
show the failure, but in yellow instead of red, and also indicate that
it was an allowed failure.
Here is an example of the output: http://imgur.com/a/wt7ga
Make wasm32 buildbot test LLVM backend
This adds the experimental targets option to configure so it can be used
by the builders and changes the wasm32 Dockerfile accordingly. Instead
of using LLVM from the emsdk, the builder's emscripten tools now uses
the Rust in-tree LLVM, since this is the one built with wasm support.
assert_eq failure message easier to read
By having the left and right strings aligned with one another it helps spot the difference between the two far quicker than if they are on the same line.
E.g.
Before:
```
thread 'tests::test_safe_filename' panicked at 'assertion failed: `(left == right)` left: `"-aandb--S123.html"` right: `"-aandb-S123.html"`',
```
After:
```
thread 'tests::test_safe_filename' panicked at 'assertion failed: `(left == right)`
left: `"-aandb--S123.html"`
right: `"-aandb-S123.html"`',
```
When the strings are both on the same line it take a lot longer to spot the difference. It is a small change but the small time savings add up with repetition. This would help Rust be an excellent language to write tests in out of the box.
Closes https://github.com/rust-lang/rust/issues/41615
This change allows the user to add an `#[allow_fail]` attribute to
tests that will cause the test to compile & run, but if the test fails
it will not cause the entire test run to fail. The test output will
show the failure, but in yellow instead of red, and also indicate that
it was an allowed failure.
This is used in wasm32-experimental-emscripten to ensure that emscripten
links against the libc bitcode files produced by the wasm LLVM backend,
instead of using fastcomp.
This adds the experimental targets option to configure so it can be used
by the builders and changes the wasm32 Dockerfile accordingly. Instead
of using LLVM from the emsdk, the builder's emscripten tools now uses
the Rust in-tree LLVM, since this is the one built with wasm support.
This commit deletes the in-tree `getopts` crate in favor of the crates.io-based
`getopts` crate. The main difference here is with a new builder-style API, but
otherwise everything else remains relatively standard.
A long time coming this commit removes the `flate` crate in favor of the
`flate2` crate on crates.io. The functionality in `flate2` originally flowered
out of `flate` itself and is additionally the namesake for the crate. This will
leave a gap in the naming (there's not `flate` crate), which will likely cause a
particle collapse of some form somewhere.
Remove SUMMARY.md of the unstable book as its autogenerated
Its being autogenerated now, as of PR #42612.
It seems I forgot to remove it.
Also, sort the entries of SUMMARY.md alphabetically.
Brings in a few regression fixes on the Cargo side, updates the rls to work
with the newer Cargo, and also updates other crates.io dependencies to pull in
various bug fixes and such.
This commit
* Refactors the collect_lib_features function to work in a
non-checking mode (no bad pointer needed, and list of
lang features).
* Introduces checking whether unstable/stable tags for a
given feature have inconsistent tracking issues.
* Fixes such inconsistencies throughout the codebase.
Autogenerate stubs and SUMMARY.md in the unstable book
Removes a speed bump in compiler development by autogenerating stubs for features in the unstable book. See #42454 for discussion.
The PR contains three commits, separated in order to make review easy:
* The first commit converts the tidy tool from a binary crate to a crate that contains both a library and a binary. In the second commit, we'll use the tidy library
* The second and main commit introduces autogeneration of SUMMARY.md and feature stub files
* The third commit turns off the tidy lint that checks for features without a stub, and removes the stub files. A separate commit due to the large number of files touched
Members of the doc team who wish to document some features can either do this (where `$rustsrc` is the root of the rust repo git checkout):
1. cd to `$rustsrc/src/tools/unstable-book-gen` and then do `cargo run $rustsrc/src $rustsrc/src/doc/unstable-book` to put the stubs into the unstable book
2. cd to `$rustsrc` and run `git ls-files --others --exclude-standard` to list the newly added stubs
3. choose a file to edit, then `git add` it and `git commit`
4. afterwards, remove all changes by the tool by doing `git --reset hard` and `git clean -f`
Or they can do this:
1. remove the comment marker in `src/tools/tidy/src/unstable_book.rs` line 122
2. run `./x.py test src/tools/tidy` to list the unstable features which only have stubs
3. revert the change in 1
3. document one of the chosen unstable features
The changes done by this PR also allow for further development:
* tidy obtains information about tracking issues. We can now forbid differing tracking issues between differing `#![unstable]` annotations. I haven't done this but plan to in a future PR
* we now have a general framework for generating stuff for the unstable book at build time. Further changes can autogenerate a list of the API a given library feature exposes.
The old way to simply click through the documentation after it has been uploaded to rust-lang.org works as well.
r? @nagisa
Fixes#42454
Introduce 'run-pass' header to 'ui' tests in compiletest. Fix issue #36516.
<del>`ui-run` test is a combination of `ui` test and `run-pass` test. It is used to test lint output.</del>
Added support of `// run-pass` header to `ui` tests.
The compiler message of each test must match the corresponding `*.stderr` file like the traditional `ui` tests. Additionally, the compiled output must be executed successfully like the `run-pass` test.
12 `run-pass`/`run-pass-fulldeps` tests are moved to `ui`/`ui-fulldeps` plus the headers. After this move, no `run-pass`/`run-pass-fulldeps` tests should rely on the compiler's JSON message. This allows us to stop passing `--error-format json` in run-pass tests, thus fixing #36516.
The 'run-pass' header cause a 'ui' test to execute the result. It is used
to test the lint output, at the same time ensure those lints won't cause
the source code to become compile-fail.
12 run-pass/run-pass-fulldeps tests gained the header and are moved to
ui/ui-fulldeps. After this move, no run-pass/run-pass-fulldeps tests should
rely on the compiler's JSON message. This allows us to stop passing
`--error-format json` in run-pass tests, thus fixing #36516.
Update rust-installer for Windows executable mode
It now marks a few whitelisted extensions as executable in the tarball,
so Windows packages can be extracted on other platforms and directly
execute install.sh.
It also includes a fix for the chmod on bulk dirs, so now the html docs
won't be marked executable en masse.
Fixes#42121
r? @alexcrichton
When `--quiet` is passed to rustbuild, suppress rustdoc test output unless
failure.
Added a `--quiet` flag to `tidy`, which suppresses the features table.
The actual `--quiet` flag is enabled in #42354.
Since details of failed tests will still be printed, and the name of slow
tests taking >60 to runtime will also be printed, the debugging difficulty
caused by information loss should be minimal; but it is very worthwhile to
keep the log under 10000 lines on Travis CI so that common errors can be
spotted without reading the raw log.
It now marks a few whitelisted extensions as executable in the tarball,
so Windows packages can be extracted on other platforms and directly
execute install.sh.
It also includes a fix for the chmod on bulk dirs, so now the html docs
won't be marked executable en masse.
Fixes#42121
r? @alexcrichton
Also, add detection to treat such comments as tidy errors.
We also remove the found_lib_feature code because it
was just repeating the found_feature code. Originally it
was intended to allow for gate-test lines for
lib features, but apparently nobody missed it.