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.
ci: Skip installing SWIG/xz on OSX
I'm relatively certain that SWIG was only needed for LLDB which is no
longer built, and I'm hoping we can remove the xz install to remove the
reliance on `brew` for our build (which is another point of failure for
flaky networks).
vxworks: Remove Linux-specific comments.
It looks like the VxWorks fork inadvertently left in some Linux-specific workaround comments in `libstd`, these can be removed. Came up when looking into #62516
CC: @BaoshanPang
Properly check the defining scope of existential types
Fixes#52632
Existential types (soon to be 'impl trait' aliases) can either be
delcared at a top-level crate/module scope, or within another item such
as an fn. Previously, we were handling the second case incorrectly when
recursively searching for defining usages - we would check children of
the item, but not the item itself. This lead to us missing closures
that consituted a defining use of the existential type, as their opaque
type instantiations are stored in the TypeckTables of their parent
function.
This commit ensures that we explicitly visit the defining item itself,
not just its children.
Make generic parameters always use modern hygiene
* E0263 (lifetime parameter declared twice in the same scope) now compares modernized identifiers.
* Const parameters are now resolved with modern hygiene.
Closes#58307Closes#60746Closes#61574Closes#62433
Remove mentions of removed `offset_to` method from `align_offset` docs
The `offset_to` method was deleted in https://github.com/rust-lang/rust/pull/52814.
The replacement for the removed method is `wrapping_offset_from`. However, neither method takes an `usize` as argument, so I don't think that it makes sense to mention them.
This is a modified version of the test I added previously. The difference is this version implements a wrapper around std::any::type_name versus core::intrinsics::type_name, in order to show that it works as desired / intended.
When positional width and precision formatting flags are present in a
formatting string that has an argument count mismatch, provide extra
information pointing at them making it easiser to understand where the
problem may lay:
```
error: 4 positional arguments in format string, but there are 3 arguments
--> $DIR/ifmt-bad-arg.rs:78:15
|
LL | println!("{} {:.*} {}", 1, 3.2, 4);
| ^^ ^^--^ ^^ --- this parameter corresponds to the precision flag
| |
| this precision flag adds an extra required argument at position 1, which is why there are 4 arguments expected
|
= note: positional arguments are zero-based
= note: for information about formatting flags, visit https://doc.rust-lang.org/std/fmt/index.html
error: 4 positional arguments in format string, but there are 3 arguments
--> $DIR/ifmt-bad-arg.rs:81:15
|
LL | println!("{} {:07$.*} {}", 1, 3.2, 4);
| ^^ ^^-----^ ^^ --- this parameter corresponds to the precision flag
| | |
| | this precision flag adds an extra required argument at position 1, which is why there are 4 arguments expected
| this width flag expects an `usize` argument at position 7, but there are 3 arguments
|
= note: positional arguments are zero-based
= note: for information about formatting flags, visit https://doc.rust-lang.org/std/fmt/index.html
error: 3 positional arguments in format string, but there are 3 arguments
--> $DIR/ifmt-bad-arg.rs:84:15
|
LL | println!("{} {:07$} {}", 1, 3.2, 4);
| ^^ ^^---^ ^^
| |
| this width flag expects an `usize` argument at position 7, but there are 3 arguments
|
= note: positional arguments are zero-based
= note: for information about formatting flags, visit https://doc.rust-lang.org/std/fmt/index.html
```
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.
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!
I'm relatively certain that SWIG was only needed for LLDB which is no
longer built, and I'm hoping we can remove the xz install to remove the
reliance on `brew` for our build (which is another point of failure for
flaky networks).
