This commit updates the version of the `rustc-std-workspace-*` crates
in-tree which are used in `[patch]`. This will guarantee that Cargo will
select these versions even if minor updates are published to crates.io
because otherwise a newer version on crates.io would be preferred which
misses the point of `[patch]`!
Not doing this leads to building two copies of e.g. num_cpus in the
sysroot and _llvm deps, leading to conflicts between the two when
compiling librustc_codegen_llvm. It's not entirely clear why this is the
case after the changes in this PR but likely has something to do with a
subtle difference in ordering or similar.
Rollup of 11 pull requests
Successful merges:
- #62848 (Use unicode-xid crate instead of libcore)
- #63774 (Fix `window.hashchange is not a function`)
- #63930 (Account for doc comments coming from proc macros without spans)
- #64003 (place: Passing `align` = `layout.align.abi`, when also passing `layout`)
- #64030 (Fix unlock ordering in SGX synchronization primitives)
- #64041 (use TokenStream rather than &[TokenTree] for built-in macros)
- #64051 (Add x86_64-linux-kernel target)
- #64063 (Fix const_err with `-(-0.0)`)
- #64083 (Point at appropriate arm on type error on if/else/match with one non-! arm)
- #64100 (Fix const eval bug breaking run-pass tests in Miri)
- #64157 (Opaque type locations in error message for clarity.)
Failed merges:
r? @ghost
They are only used by rustc_lexer, and are not needed elsewhere.
So we move the relevant definitions into rustc_lexer (while the actual
unicode data comes from the unicode-xid crate) and make the rest of
the compiler use it.
Since its inception rustbuild has always worked in three stages: one for
libstd, one for libtest, and one for rustc. These three stages were
architected around crates.io dependencies, where rustc wants to depend
on crates.io crates but said crates don't explicitly depend on libstd,
requiring a sysroot assembly step in the middle. This same logic was
applied for libtest where libtest wants to depend on crates.io crates
(`getopts`) but `getopts` didn't say that it depended on std, so it
needed `std` built ahead of time.
Lots of time has passed since the inception of rustbuild, however,
and we've since gotten to the point where even `std` itself is depending
on crates.io crates (albeit with some wonky configuration). This
commit applies the same logic to the two dependencies that the `test`
crate pulls in from crates.io, `getopts` and `unicode-width`. Over the
many years since rustbuild's inception `unicode-width` was the only
dependency picked up by the `test` crate, so the extra configuration
necessary to get crates building in this crate graph is unlikely to be
too much of a burden on developers.
After this patch it means that there are now only two build phasese of
rustbuild, one for libstd and one for rustc. The libtest/libproc_macro
build phase is all lumped into one now with `std`.
This was originally motivated by rust-lang/cargo#7216 where Cargo was
having to deal with synthesizing dependency edges but this commit makes
them explicit in this repository.
Update rustfmt to 1.4.5
This update includes a bug fix that fixes generating invalid code when formatting an impl block with const generics inside a where clause.
**Changes**
0462008de8...1de58ce46d
Do not emit JSON dumps of diagnostic codes
This decouples the error index generator from libsyntax for the most part (though it still depends on librustdoc for the markdown parsing and generation).
Fixes#34588
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!
Update linked OpenSSL version
This bumps our linked OpenSSL version from 1.1.1a to 1.1.1c, picking up
some various bug fixes and minor security issue fixes.
This pulls in a commit which uses parallel xz encoding which should
hopefully help shave some time off the dist builders which spend an
inordinate amount of time compressing this data.
std: Remove internal definitions of `cfg_if!` macro
This is duplicated in a few locations throughout the sysroot to work
around issues with not exporting a macro in libstd but still wanting it
available to sysroot crates to define blocks. Nowadays though we can
simply depend on the `cfg-if` crate on crates.io, allowing us to use it
from there!
Use Symbol, Span in libfmt_macros
I'm not super happy with this, personally, but I think it might be a decent start -- happy to take suggestions as to how to expand this or change things further.
r? @estebank
Fixes#60795
This is duplicated in a few locations throughout the sysroot to work
around issues with not exporting a macro in libstd but still wanting it
available to sysroot crates to define blocks. Nowadays though we can
simply depend on the `cfg-if` crate on crates.io, allowing us to use it
from there!
Discovered in #61416 an accidental regression in libstd's backtrace
behavior is that it previously attempted to consult libbacktrace and
would then fall back to `dladdr` if libbacktrace didn't report anything.
The `backtrace` crate, however, did not do this, so that's now been
fixed!
Changes: https://github.com/rust-lang/backtrace-rs/compare/0.3.25...0.3.27Closes#61416
This adds a new diagnostic writer `AnnotateRsEmitterWriter` that uses
the [`annotate-snippet`][as] library to print out the human readable
diagnostics.
The goal is to eventually switch over to using the library instead of
maintaining our own diagnostics output.
This commit does *not* add all the required features to the new
diagnostics writer. It is only meant as a starting point so that other
people can contribute as well.
[as]: https://github.com/rust-lang/annotate-snippets-rs
strip synstructure consts from compiler docs
Fixes#60150.
Unfortunately this PR depends on the use of the deprecated `--passes` flag in bootstrap to keep the `--strip-hidden` pass while still documenting private items. I've opened #60884 to track stabilization of a new flag that encapsulates this behavior.
r? @QuietMisdreavus
This commit removes all in-tree support for generating backtraces in
favor of depending on the `backtrace` crate on crates.io. This resolves
a very longstanding piece of duplication where the standard library has
long contained the ability to generate a backtrace on panics, but the
code was later extracted and duplicated on crates.io with the
`backtrace` crate. Since that fork each implementation has seen various
improvements one way or another, but typically `backtrace`-the-crate has
lagged behind libstd in one way or another.
The goal here is to remove this duplication of a fairly critical piece
of code and ensure that there's only one source of truth for generating
backtraces between the standard library and the crate on crates.io.
Recently I've been working to bring the `backtrace` crate on crates.io
up to speed with the support in the standard library which includes:
* Support for `StackWalkEx` on MSVC to recover inline frames with
debuginfo.
* Using `libbacktrace` by default on MinGW targets.
* Supporting `libbacktrace` on OSX as an option.
* Ensuring all the requisite support in `backtrace`-the-crate compiles
with `#![no_std]`.
* Updating the `libbacktrace` implementation in `backtrace`-the-crate to
initialize the global state with the correct filename where necessary.
After reviewing the code in libstd the `backtrace` crate should be at
exact feature parity with libstd today. The backtraces generated should
have the same symbols and same number of frames in general, and there's
not known divergence from libstd currently.
Note that one major difference between libstd's backtrace support and
the `backtrace` crate is that on OSX the crates.io crate enables the
`coresymbolication` feature by default. This feature, however, uses
private internal APIs that aren't published for OSX. While they provide
more accurate backtraces this isn't appropriate for libstd distributed
as a binary, so libstd's dependency on the `backtrace` crate explicitly
disables this feature and forces OSX to use `libbacktrace` as a
symbolication strategy.
The long-term goal of this refactoring is to eventually move us towards
a world where we can drop `libbacktrace` entirely and simply use Gimli
and the surrounding crates for backtrace support. That's still aways off
but hopefully will much more easily enabled by having the source of
truth for backtraces live in crates.io!
Procedurally if we go forward with this I'd like to transfer the
`backtrace-rs` crate to the rust-lang GitHub organization as well, but I
figured I'd hold off on that until we get closer to merging.
This commit bumps the `compiler-builtins` dependency to 0.1.15 which
expects to have the source for `compiler-rt` provided externally if the
`c` feature is enabled. This then plumbs through the necessary support
in the build system to ensure that if the `llvm-project` directory is
checked out and present that we enable the `c` feature of
`compiler-builtins` and compile in all the C intrinsics.
This updates to 0.1.13 for `compiler_builtins`, published to fix a few
issues. The feature changes here are updated because `compiler_builtins`
no longer enables the `c` feature by default but we want to do so
through our build still.
Closes#60747Closes#60782
`find_attr_val(&line, "since")` returns `Some(", issue = ")` when
`line` is set to the following line:
```
[unstable(feature = "checked_duration_since", issue = "58402")]
```
Make `find_attr_val` use regex that is a little bit more
precise (requires `=` after key name).
It still does not handle all cases (e.g., extra leading chars in key
name, or escaped quotes in value), but is good enough for now.
The commit moves metadata writing from `link_binary` to
`encode_metadata` (and renames the latter as
`encode_and_write_metadata`). This is at the very start of code
generation.
Fix index-page generation
Fixes#60096.
The minifier was minifying crates name in `searchIndex` key position, which was a bit problematic for multiple reasons.
r? @rust-lang/rustdoc
Changes:
````
Rustup for https://github.com/rust-lang/rust/pull/59042
Update pulldown_cmark to 0.5
Only run AppVeyor on r+, try and the master branch
Remove approx_constant known problems
Suppress let_and_return if let has attributes
Add test for or_fun_call macro suggestion
UI test cleanup: Extract needless_range_loop tests
Change "if types change" to "if you later change the type"
````
This also bumps RLS version to 1.36.
The updated rls-* packages use serde but *not* serde_derive thanks to
manual proc macro expansion. This is a hack, since rustc cannot handle
crates.io proc macros (duplicated in tools) when cross-compiling, so
that's the best we can do in order to support serde_json in save-analysis.
Changes:
````
Update compiletest_rs
Typo
Fix dogfood error
Add lint PathBufPushOverwrite
Update *.stderr file
Remove code duplication
Format code
Add test for debug_assert!(false)
Don't lint debug_assert!(false)
Add run-rustfix for option_map_or_none lint
Move two cast_lossless tests to their correct files
Change naive_bytecount applicability MaybeIncorrect
Add tests for declare_lint_pass and impl_lint_pass
Use lint pass macros
Document `declare_lint_pass!`
Fix lint_without_lint_pass internal lint
Use {get,match}_def_path from LateContext
Remove uplifted functions {get,match}_def_path from Clippy
Add run-rustfix for len_zero lint
Add run-rustfix for bool_comparison lint
Add run-rustfix for deref_addrof lint
while_let_loop uses placeholders in suggestions
Remove rust-toolchain file from clippy_dev
Update adding_lints.md
Update PULL_REQUEST_TEMPLATE
Add new lint checklist
Create PULL_REQUEST_TEMPLATE
Only suggest .copied() for Option right now
Also suggest .copied() when .clone() is called on a Copy type
Suggest .copied() instead of .cloned() in map_clone when dealing with references
Deny rustc internal lints
Remove clippy::default_hash_types internal lint
Enable -Zunstable-options in .cargo/config
````
update polonius-engine
This updates polonius-engine to [version 0.7.0](https://github.com/rust-lang/polonius/blob/master/RELEASES.md#v070), which adds a hybrid algorithm that starts off with performing a cheaper, location-insensitive analysis before proceeding with the full analysis.
r? @nikomatsakis
Turns out we needed to exclude a number of math functions on the
`wasm32-unknown-wasi` target, and this was fixed in 0.1.9 of
compiler-builtins and this is pulling in the fix to libstd's own build.
This commit adds a new wasm32-based target distributed through rustup,
supported in the standard library, and implemented in the compiler. The
`wasm32-unknown-wasi` target is intended to be a WebAssembly target
which matches the [WASI proposal recently announced.][LINK]. In summary
the WASI target is an effort to define a standard set of syscalls for
WebAssembly modules, allowing WebAssembly modules to not only be
portable across architectures but also be portable across environments
implementing this standard set of system calls.
The wasi target in libstd is still somewhat bare bones. This PR does not
fill out the filesystem, networking, threads, etc. Instead it only
provides the most basic of integration with the wasi syscalls, enabling
features like:
* `Instant::now` and `SystemTime::now` work
* `env::args` is hooked up
* `env::vars` will look up environment variables
* `println!` will print to standard out
* `process::{exit, abort}` should be hooked up appropriately
None of these APIs can work natively on the `wasm32-unknown-unknown`
target, but with the assumption of the WASI set of syscalls we're able
to provide implementations of these syscalls that engines can implement.
Currently the primary engine implementing wasi is [wasmtime], but more
will surely emerge!
In terms of future development of libstd, I think this is something
we'll probably want to discuss. The purpose of the WASI target is to
provide a standardized set of syscalls, but it's *also* to provide a
standard C sysroot for compiling C/C++ programs. This means it's
intended that functions like `read` and `write` are implemented for this
target with a relatively standard definition and implementation. It's
unclear, therefore, how we want to expose file descriptors and how we'll
want to implement system primitives. For example should `std::fs::File`
have a libc-based file descriptor underneath it? The raw wasi file
descriptor? We'll see! Currently these details are all intentionally
hidden and things we can change over time.
A `WasiFd` sample struct was added to the standard library as part of
this commit, but it's not currently used. It shows how all the wasi
syscalls could be ergonomically bound in Rust, and they offer a possible
implementation of primitives like `std::fs::File` if we bind wasi file
descriptors exactly.
Apart from the standard library, there's also the matter of how this
target is integrated with respect to its C standard library. The
reference sysroot, for example, provides managment of standard unix file
descriptors and also standard APIs like `open` (as opposed to the
relative `openat` inspiration for the wasi ssycalls). Currently the
standard library relies on the C sysroot symbols for operations such as
environment management, process exit, and `read`/`write` of stdio fds.
We want these operations in Rust to be interoperable with C if they're
used in the same process. Put another way, if Rust and C are linked into
the same WebAssembly binary they should work together, but that requires
that the same C standard library is used.
We also, however, want the `wasm32-unknown-wasi` target to be
usable-by-default with the Rust compiler without requiring a separate
toolchain to get downloaded and configured. With that in mind, there's
two modes of operation for the `wasm32-unknown-wasi` target:
1. By default the C standard library is statically provided inside of
`liblibc.rlib` distributed as part of the sysroot. This means that
you can `rustc foo.wasm --target wasm32-unknown-unknown` and you're
good to go, a fully workable wasi binary pops out. This is
incompatible with linking in C code, however, which may be compiled
against a different sysroot than the Rust code was previously
compiled against. In this mode the default of `rust-lld` is used to
link binaries.
2. For linking with C code, the `-C target-feature=-crt-static` flag
needs to be passed. This takes inspiration from the musl target for
this flag, but the idea is that you're no longer using the provided
static C runtime, but rather one will be provided externally. This
flag is intended to also get coupled with an external `clang`
compiler configured with its own sysroot. Therefore you'll typically
use this flag with `-C linker=/path/to/clang-script-wrapper`. Using
this mode the Rust code will continue to reference standard C
symbols, but the definition will be pulled in by the linker configured.
Alright so that's all the current state of this PR. I suspect we'll
definitely want to discuss this before landing of course! This PR is
coupled with libc changes as well which I'll be posting shortly.
[LINK]:
[wasmtime]:
Update rustfmt to 1.2.0
This release includes bug fixes and performance improvements from 1.1.0. Also it adds a new rustfmt tool attribute `#[rustfmt::skip::macros]`, which lets you skip formatting macro calls of your choice.
cc @nrc @Centril @Xanewok
