This commit changes the lock file format of this repository to an
experimental format that isn't rolled out by default in Cargo but is
intended to eventually become the default. The new format moves
information around and compresses the lock file a bit. The intention of
the new format is to reduce the amount of git merge conflicts that
happen in a repository, with rust-lang/rust being a prime candidate for
testing this.
The new format wille ventually become the default but for now it is
off-by-default in Cargo, but Cargo will preserve the format if it sees
it. Since we always build with a beta version of Cargo for the
rust-lang/rust repository it should be safe to go ahead and change the
lock file format here and everyone building this repository will
automatically pick it up.
It's intended that we'll evaluate this lock file format in the
rust-lang/rust repository to see if it reduces the number of perceived
merge conflicts for changes that touch the lock file. This will in turn
help inform the development of the feature in Cargo and whether we
choose to stabilize this and turn it on by default.
Note that this commit does not actually change the contents of the lock
file in terms of a resolution graph, it simply reencodes the lock file
with a new format.
This commit updates the `backtrace` crate from 0.3.34 to 0.3.35. The
[included set of changes][changes] for this update mostly includes some
gimli-related improvements (not relevant for the standard library) but
critically includes a fix for rust-lang/backtrace-rs#230. The standard
library will not aqcuire a session-local lock whenever a backtrace is
generated on Windows to allow external synchronization with the
`backtrace` crate itself, allowing `backtrace` to be safely used while
other threads may be panicking.
[changes]: https://github.com/rust-lang/backtrace-rs/compare/0.3.34...0.3.35
This drops the parking_lot dependency; the ReentrantMutex type appeared
to be unused (at least, no compilation failures occurred).
This is technically a possible change in behavior of its users, as
lock() would wait on other threads releasing their guards, but since we
didn't actually remove any threading or such in this code, it appears
that we never used that behavior (the behavior change is only noticeable
if the type previously was used in two threads, in a single thread
ReentrantMutex is useless).
bump rand in libcore/liballoc test suites
This pulls in the fix for https://github.com/rust-random/rand/issues/779, which trips Miri when running these test suites.
`SmallRng` (formerly used by libcore) is no longer built by default, it needs a feature gate. I opted to switch to `StdRng` instead. Or should I enable the feature gate?
Deduplicate rustc_demangle in librustc_codegen_llvm
This commit removes the crates.io dependency of `rustc-demangle` from
`rustc_codegen_llvm`. This crate is actually already pulled in to part
of the `librustc_driver` build and with the upcoming pipelining
implementation in Cargo it causes build issues if `rustc-demangle` is
left to its own devices.
This is not currently required, but once pipelining is enabled for
rustc's own build it will be required to build correctly.
This commit removes the crates.io dependency of `rustc-demangle` from
`rustc_codegen_llvm`. This crate is actually already pulled in to part
of the `librustc_driver` build and with the upcoming pipelining
implementation in Cargo it causes build issues if `rustc-demangle` is
left to its own devices.
This is not currently required, but once pipelining is enabled for
rustc's own build it will be required to build correctly.
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.
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.
bump crossbeam-epoch dependency
The new crossbeam-epoch release depends on a memoffset with a whole bunch of soundness holes fixed.
The old memoffset is still indirectly depended on (at least) by rustc-rayon, though -- a crate that looks rather unmaintained (no change in more than a year).
The idea here is to make a reusable library out of the existing
rust-lexer, by separating out pure lexing and rustc-specific concerns,
like spans, error reporting an interning.
So, rustc_lexer operates directly on `&str`, produces simple tokens
which are a pair of type-tag and a bit of original text, and does not
report errors, instead storing them as flags on the token.
This commit updates some of our assorted Azure/CI configuration to
prepare for some 4-core machines coming online. We're still in the
process of performance testing them to get final numbers, but some
changes are worth landing ahead of this. The updates here are:
* Use `C:/` instead of `D:/` for submodule checkout since it should have
plenty of space and the 4-core machines won't have `D:/`
* Update `lzma-sys` to 0.1.14 which has support for VS2019, where 0.1.10
doesn't.
* Update `src/ci/docker/run.sh` to work when it itself is running inside
of a docker container (see the comment in the file for more info)
* Print step timings on the `try` branch in addition to the `auto`
branch in. The logs there should be seen by similarly many humans (not
many) and can be useful for performance analysis after a `try` build
runs.
* Install the WIX and InnoSetup tools manually on Windows instead of
relying on pre-installed copies on the VM. This gives us more control
over what's being used on the Azure cloud right now (we control the
version) and in the 4-core machines these won't be pre-installed. Note
that on AppVeyor we actually already were installing InnoSetup, we
just didn't carry that over on Azure!
