Some fixes for i686-msvc and Windows have landed on the `backtrace`
crate but hadn't made their way here yet. Let's update that and see if
it passes CI.
rustc: Compile the `fmt_macros` crate as an rlib
I think this was left out by accident from the "convert everything to
rlibs" commit, there's no need for this to be a dylib just as everything
else doesn't need to be a dylib!
submodules: update clippy from dc69a5c0 to c3e91365
Changes:
````
Fix breakage due to rust-lang/rust#61856
Fix dogfood test
Hash discriminant of lifetime.name
Hash discriminant of Lifetime::Name
Updated tests.
Respond to review comments
Updated test stderr
Added doc comment fixed type printout
Respond to comments and improve printout
Responded to comments and fixed compile bug
Fixed more compile errors
Fix some of the compile errors
Changed Ty to ty, added lifetime 'tcx
Lint for type repetition in trait bounds.
````
r? @Manishearth
`const fn`-ify `std::any::type_name` as laid out in #63084
A test, based on the one I added when I implemented support for the underlying `core::intrinsics::type_name` being allowed in `const fn` contexts, is included.
Turn `INCOMPLETE_FEATURES` into lint
We do this because it is annoying to see the warning when building rustc and because this is better from a "separation of concerns" POV.
The drawback to this change is that this will respect `--cap-lints`.
Also note that this is not a buffered lint so if there are fatal parser errors then the lint will not trigger.
r? @varkor
Unsupport the `await!(future)` macro
Unsupport the `await!(future)` "macro" and recognize it in error recovery instead.
The `future.await` syntax has been on nightly since 2019-05-08.
This was 55 days ago which is 1.31 releases ago.
Closes https://github.com/rust-lang/rust/issues/60610.
r? @cramertj
Last two commits bumped rustc-ap-* crates which also transitively
updated rustc_data_structures. That crate enables the "nightly"
whereas Cargo's dep does not hence why we need to unify the features
to deduplicate the artifacts.
Changes:
````
Fix breakage due to rust-lang/rust#61856
Fix dogfood test
Hash discriminant of lifetime.name
Hash discriminant of Lifetime::Name
Updated tests.
Respond to review comments
Updated test stderr
Added doc comment fixed type printout
Respond to comments and improve printout
Responded to comments and fixed compile bug
Fixed more compile errors
Fix some of the compile errors
Changed Ty to ty, added lifetime 'tcx
Lint for type repetition in trait bounds.
````
rustc: Stabilize options for pipelined compilation
This commit stabilizes options in the compiler necessary for Cargo to
enable "pipelined compilation" by default. The concept of pipelined
compilation, how it's implemented, and what it means for rustc are
documented in #60988. This PR is coupled with a PR against Cargo
(rust-lang/cargo#7143) which updates Cargo's support for pipelined
compliation to rustc, and also enables support by default in Cargo.
(note that the Cargo PR cannot land until this one against rustc lands).
The technical changes performed here were to stabilize the functionality
proposed in #60419 and #60987, the underlying pieces to enable pipelined
compilation support in Cargo. The issues have had some discussion during
stabilization, but the newly stabilized surface area here is:
* A new `--json` flag was added to the compiler.
* The `--json` flag can be passed multiple times.
* The value of the `--json` flag is a comma-separated list of
directives.
* The `--json` flag cannot be combined with `--color`
* The `--json` flag must be combined with `--error-format=json`
* The acceptable list of directives to `--json` are:
* `diagnostic-short` - the `rendered` field of diagnostics will have a
"short" rendering matching `--error-format=short`
* `diagnostic-rendered-ansi` - the `rendered` field of diagnostics
will be colorized with ansi color codes embedded in the string field
* `artifacts` - JSON blobs will be emitted for artifacts being emitted
by the compiler
The unstable `-Z emit-artifact-notifications` and `--json-rendered`
flags have also been removed during this commit as well.
Closes#60419Closes#60987Closes#60988
std: Fix a failing `fs` test on Windows
In testing 4-core machines on Azure the `realpath_works_tricky` test in
the standard library is failing with "The directory name is invalid". In
attempting to debug this test I was able to reproduce the failure
locally on my machine, and after inspecing the test it I believe is
exploiting Unix-specific behavior that seems to only sometimes work on
Windows. Specifically the test basically executes:
mkdir -p a/b
mkdir -p a/d
touch a/f
ln -s a/b/c ../d/e
ln -s a/d/e ../f
and then asserts that `canonicalize("a/b/c")` and
`canonicalize("a/d/e")` are equivalent to `a/f`. On Windows however the
first symlink is a "directory symlink" and the second is a file symlink.
In both cases, though, they're pointing to files. This means that for
whatever reason locally and on the 4-core environment the call to
`canonicalize` is failing. On Azure today it seems to be passing, and
I'm not entirely sure why. I'm sort of presuming that there's some sort
of internals going on here where there's some global Windows setting
which makes symlinks behavior more unix-like and ignore the directory
hint.
In any case this should keep the test working and also fixes the test
locally for me. It's also worth pointing out that this test was made Windows compatible in https://github.com/rust-lang/rust/pull/31360, a pretty ancient PR at this point.
