Pass a test directory to rustfmt
Another attempt to fix the rustfmt tests. `RUSTFMT_TEST_DIR` is consumed by Rustfmt in the latext commit (thus the Rustfmt update) because we need a place to create temp files that won't be read-only.
r? @alexcrichton
Issue 49938: Reference tagged unions discr(iminant) as tag
Here the changes reference the Tagged type _discriminant_ as _tag_ instead. This is the correct terminology when referencing how tagged unions are represented in memory.
Fix ICE in assertion macro
Fixes#50471. Needs beta-backport (stable-to-beta/nightly regression).
* `panic` with single argument does not need escaping `{` and `}`
* Instead of unescaping `\u{...}` manually, just use `escape_debug` in pprust
The Option is always Some until drop, where it becomes None. Make
this more explicit and avoid unwraps by using ManuallyDrop.
This change should be performance-neutral as LLVM already optimizes
the unwraps away in the inlined code.
rustbuild: Allow quick testing of libstd and libcore at stage0
This PR implemented two features:
1. Added a `--no-doc` flag to allow testing a crate *without* doc tests. In this mode, we don't need to build rustdoc, and thus we can skip building the stage2 compiler. (Ideally stage0 test should use the bootstrap rustdoc, but I don't want to mess up the core builder logic here)
2. Moved all libcore tests externally and added a tidy test to ensure we don't accidentally add `#[test]` into libcore.
After this PR, one could run `./x.py test --stage 0 --no-doc src/libstd` to test `libstd` without building the compiler, thus enables us to quickly test new library features.
proc_macro: Explicitly make everything !Send/Sync
This commit adds explicit imp blocks to ensure that all publicly exported types
(except simple enums) are not `Send` nor `Sync` in the `proc_macro` crate.
cc #38356
Refer https://github.com/rust-lang/rust/issues/49938
Previously tagged unions' tag was refered to as a discr(iminant).
Here the changes use tag instead which is the correct terminology
when refering to the memory representation of tagged unions.
Add a CI job that makes sure rustc builds with parallel queries enabled.
This shouldn't take up too much CI time `:)`
cc https://github.com/rust-lang/rust/issues/48607
cc @Zoxc
r? @alexcrichton
Misc tweaks
This:
- ~~Add explicit dependencies on `getops`~~
- Fixes the libtest-json test when `RUST_BACKTRACE=1` is set
- ~~Sets `opt-level` to `3`~~
- Removes the use of `staged_api` from `rustc_plugin`
- ~~Enables the Windows Error Reporting dialog when running rustc during bootstrapping~~
- Disables Windows Error Reporting dialog when running compiletest tests
- Enables backtraces when running rustc during bootstrapping
- ~~Removes the `librustc` dependency on `libtest`~~
- Triggers JIT debugging on Windows if rustc panics during bootstrapping
r? @alexcrichton
All other tests of libcore reside in the tests/ directory,
too. Apparently the tests of `time.rs` weren't run before, at
least not by `x.py test src/libcore`.
Suggest more helpful formatting string
Based on [user feedback](https://users.rust-lang.org/t/ux-feedback-from-a-rust-newbie/17220) the minimal suggestion of `:?` is unclear.
Also `{:#?}` is much more readable than the standard debug, so this PR suggests it to help surface this nice feature.
In particular, type annotations given by the user must hold at all
points in the program. This doesn't affect current analysis but
will affect fact generation later.
Avoid many `cmt` allocations.
`cmt` is a ref-counted wrapper around `cmt_` The use of refcounting
keeps `cmt` handling simple, but a lot of `cmt` instances are very
short-lived, and heap-allocating the short-lived ones takes up time.
This patch changes things in the following ways.
- Most of the functions that produced `cmt` instances now produce `cmt_`
instances. The `Rc::new` calls that occurred within those functions
now occur at their call sites (but only when necessary, which isn't
that often).
- Many of the functions that took `cmt` arguments now take `&cmt_`
arguments. This includes all the methods in the `Delegate` trait.
As a result, the vast majority of the heap allocations are avoided. In
an extreme case, the number of calls to malloc in tuple-stress drops
from 9.9M to 7.9M, a drop of 20%. And the compile times for many runs of
coercions, deep-vector, and tuple-stress drop by 1--2%.
Add armv5te-unknown-linux-musl target
This PR adds the armv5te-unknown-linux-musl target. The following steps should let you produce a fully statically linked binary now:
1. Running `./src/ci/docker/run.sh dist-armv5te-linux-musl`
2. Changing the run.sh script to start bash instead of the build process and running the container
3.
```sh
export USER=root
export PATH=/checkout/obj/build/x86_64-unknown-linux-gnu/stage2/bin:/checkout/obj/build/x86_64-unknown-linux-gnu/stage0/bin:$PATH
```
4. Configuring Cargo
```yaml
[target.armv5te-unknown-linux-musl]
linker = "arm-linux-gnueabi-gcc"
```
5. Building a project
```sh
cargo new --bin hello
cd hello
cargo build --target=armv5te-unknown-linux-musl --release
```
rustdoc: Resolve nested `impl Trait`s
Fixes#50358.
Populates `cx.impl_trait_bounds` incrementally while `clean`ing generic params, so that a synthetic type-parameter can refer to previous ones.
cc #50366
First step towards rustfix compiletest mode
This is the first small step towards testing auto-fixable compiler
suggestions using compiletest. Currently, it only checks if next to a
UI test there also happens to a `*.rs.fixed` file, and then uses rustfix
(added as external crate) on the original file, and asserts that it
produces the fixed version.
To show that this works, I've included one such test. I picked this test
case at random (and because it was simple) -- It is not relevant to the
2018 edition. Indeed, in the near future, we want to be able to restrict
rustfix to edition-lints, so this test cast might go away soon.
In case you still think this is somewhat feature-complete, here's a
quick list of things currently missing that I want to add before telling
people they can use this:
- [x] Make this an actual compiletest mode, with `test [fix] …` output
and everything
- [x] Assert that fixed files still compile
- [x] Assert that fixed files produce no (or a known set of) diagnostics
output
- [x] Update `update-references.sh` to support rustfix
- [x] Use a published version of rustfix (i.e.: publish a new version
rustfix that exposes a useful API for this)
This commit adds a dedicated mode to compiletest for running rustfix tests,
adding a new `src/test/rustfix` directory which will execute all tests as a
"rustfix" test, namely requiring that a `*.fixed` is next to the main file which
is the result of the rustfix project's application of fixes.
The `rustfix` crate is pulled in to actually perform the fixing, and the rustfix
compiletest mode will assert a few properties about the fixing:
* The expected fixed output must be the same as rustc's output suggestions
applied to the original code.
* The fixed code must compile successfully
* The fixed code must have no further diagnostics emitted about it
This is the first small step towards testing auto-fixable compiler
suggestions using compiletest. Currently, it only checks if next to a
UI test there also happens to a `*.rs.fixed` file, and then uses rustfix
(added as external crate) on the original file, and asserts that it
produces the fixed version.
To show that this works, I've included one such test. I picked this test
case at random (and because it was simple) -- It is not relevant to the
2018 edition. Indeed, in the near future, we want to be able to restrict
rustfix to edition-lints, so this test cast might go away soon.
In case you still think this is somewhat feature-complete, here's a
quick list of things currently missing that I want to add before telling
people they can use this:
- [ ] Make this an actual compiletest mode, with `test [fix] …` output
and everything
- [ ] Assert that fixed files still compile
- [ ] Assert that fixed files produce no (or a known set of) diagnostics
output
- [ ] Update `update-references.sh` to support rustfix
- [ ] Use a published version of rustfix (i.e.: publish a new version
rustfix that exposes a useful API for this)
