Rollup of 10 pull requests
Successful merges:
- #60492 (Add custom nth_back for Chain)
- #61780 (Finalize the error type for `try_reserve`)
- #63495 ( Remove redundant `ty` fields from `mir::Constant` and `hair::pattern::PatternRange`.)
- #63525 (Make sure that all file loading happens via SourceMap)
- #63595 (add sparc64-unknown-openbsd target)
- #63604 (Some update for vxWorks)
- #63613 (Hygienize use of built-in macros in the standard library)
- #63632 (A couple of comment fixes.)
- #63634 (ci: properly set the job name in CPU stats)
- #63636 (ci: move linkcheck from mingw-2 to mingw-1)
Failed merges:
r? @ghost
ci: move linkcheck from mingw-2 to mingw-1
Running UI tests now takes a huge amount of time on mingw builders
(between 40 and 50 minutes), with mingw-1 builders taking even an hour
less to finish than mingw-2. This PR moves linkcheck from mingw-2 to
mingw-1, removing between 10 and 20 minutes of runtime on the -2
builders.
r? @alexcrichton
A couple of comment fixes.
This change fixes a couple of comments in the compiler code.
The first change was discussed with @eddyb. This one confused me because I thought only *public* defs were in the table (not so).
The second was a typo I noticed yesterday.
OK to go in?
Some update for vxWorks
1. support crt-static
2. change armv7_wrs_vxworks to armv7_wrs_vxworks_eabihf.
3. change vx-cxx to wr-c++, vx-ar to wr-ar and vx-run to wr-run.
4. code cleanup
r? @alexcrichton
add sparc64-unknown-openbsd target
on OpenBSD, some architectures relies on libc++ (from LLVM) and some
others on libestdc++ (particular version of libstdc++ from GCC).
sparc64-unknown-openbsd needs libestdc++ and libgcc (as x86_64 some
years ago). Reintroduce the support of them for openbsd, only for
sparc64 arch. Some others architectures on OpenBSD could use them too.
Make sure that all file loading happens via SourceMap
That way, callers don't need to repeat "let's add this to sm manually
for tracking dependencies" trick.
It should make it easier to switch to using `FileLoader` for binary
files in the future as well
cc #62948
r? @petrochenkov
Remove redundant `ty` fields from `mir::Constant` and `hair::pattern::PatternRange`.
Fixes#56137.
As a side-effect, associated const literals have the correct type now, which should make things easier for #61041.
r? @oli-obk / @matthewjasper cc @davidtwco @varkor
Finalize the error type for `try_reserve`
See tracking issue comments from https://github.com/rust-lang/rust/issues/48043#issuecomment-500828346.
It is now:
```rust
/// The error type for `try_reserve` methods.
#[derive(Clone, PartialEq, Eq, Debug)]
#[unstable(feature = "try_reserve", reason = "new API", issue="48043")]
pub enum TryReserveError {
/// Error due to the computed capacity exceeding the collection's maximum
/// (usually `isize::MAX` bytes).
CapacityOverflow,
/// The memory allocator returned an error
AllocError {
/// The layout of allocation request that failed
layout: Layout,
#[doc(hidden)]
#[unstable(feature = "container_error_extra", issue = "0", reason = "\
Enable exposing the allocator’s custom error value \
if an associated type is added in the future: \
https://github.com/rust-lang/wg-allocators/issues/23")]
non_exhaustive: (),
},
}
#[unstable(feature = "try_reserve", reason = "new API", issue="48043")]
impl From<LayoutErr> for TryReserveError {
#[inline]
fn from(_: LayoutErr) -> Self {
TryReserveError::CapacityOverflow
}
}
```
Changes:
* A `Layout` is included. Firefox wants to log the size of failed allocations. If this were not part of the return value of e.g. `HashMap::try_reserve`, users would only be able to estimate based on `HashMap::capacity` and assumptions about the allocation strategy of `HashMap`.
* There’s a dummy field that can stay unstable when `try_reserve` and the rest of this enum are stabilized. This forces non-exhaustive matching ~(https://github.com/rust-lang/rust/issues/44109 is not implemented yet for variants)~ and allows adding another field in the future if we want to expose custom error values from the allocator. See https://github.com/rust-lang/wg-allocators/issues/23.
- If the `Alloc` trait is stabilized without an associated error type and with a zero-size `AllocErr` type, we can simply remove this dummy field.
- If an associated type is added, we can add a default type parameter to `ContainerError` and a generic field to the `AllocError` variant.
* ~Moved from the `collections` module to the `alloc` module, and replaced `Collection` in the enum name with `Container`. The wold collection implies a multiplicity of items which is not relevant to this type. For example we may want to use this error type in a future `Box::try_new` method.~
- Renamed to `TryReserveError`, after the methods that involve this type: https://github.com/rust-lang/rust/pull/61780#issuecomment-501392487
* Replaced `Err` with `Error` in the enum and variant names. There is more precedent for this in https://doc.rust-lang.org/std/error/trait.Error.html#implementors, `AllocErr` and `LayoutErr` are the odd ones.
* ~Dropped `Alloc` in the enum name. `ContainerAllocError` with a mouthful, and being in the `alloc` module already provides the same indication.~
… and add a separately-unstable field to force non-exhaustive matching
(`#[non_exhaustive]` is no implemented yet on enum variants)
so that we have the option to later expose the allocator’s error value.
CC https://github.com/rust-lang/wg-allocators/issues/23
Running UI tests now takes a huge amount of time on mingw builders
(between 40 and 50 minutes), with mingw-1 builders taking even an hour
less to finish than mingw-2. This PR moves linkcheck from mingw-2 to
mingw-1, removing between 10 and 20 minutes of runtime on the -2
builders.
Utilize -Zbinary-dep-depinfo in rustbuild
We no longer utilize stamp-file mtimes at all inside rustbuild, and a future PR may be able to entirely eliminate them by eagerly copying to the appropriate sysroot. The only mtime-based dependency tracking left is for documentation because we lie to Cargo about the rustdoc binary, so Cargo does not track changes to the real binary, and codegen-backends because binary-dep-depinfo does not emit that information into the depfiles.
Both of these are fixable in the longer term but this existing patch gives us the following benefits:
* We no longer delete Cargo target directories manually within a stage. Cross-stage, changes to codegen backends will still clear out target directories. This means that incremental state persists across individual steps (e.g., rebuilding libstd does not clear out librustc incremental state). Fixes#54712.
* Dependency tracking across steps within a given stage is now fully precise. We will not clear out all codegen backend dependencies due to changes in librustc_driver, for example, only deleting the final librustc_codegen_llvm crate. Fixes#54008, fixes#50481.
* We properly track codegen backends as a dependency (equivalent to rustc) across changes. Fixes#53284, and fixes#52719.
* Cross-stage dependency tracking of crates is also much more accurate and reliable. Most likely fixes#49979 (but no reproduction steps in that issue). Fixes#59105.
cc #63012
Rollup of 7 pull requests
Successful merges:
- #62593 (Group all ABI tests.)
- #63173 (Use libunwind from llvm-project submodule for musl targets)
- #63535 (Continue refactoring resolve and hygiene)
- #63539 (Suggest Rust 2018 on `<expr>.await` with no such field)
- #63584 (libcore: more cleanups using `#![feature(associated_type_bounds)]`)
- #63612 (Do not suggest `try_into` for base types inside of macro expansions)
- #63615 (Fix typo in DoubleEndedIterator::nth_back doc)
Failed merges:
r? @ghost
Suggest Rust 2018 on `<expr>.await` with no such field
When type checking a field projection (`fn check_field`) to `<expr>.await` where `<expr>: τ` and `τ` is not a primitive type, suggest switching to Rust 2018. E.g.
```
error[E0609]: no field `await` on type `std::pin::Pin<&mut dyn std::future::Future<Output = ()>>`
--> $DIR/suggest-switching-edition-on-await.rs:31:7
|
LL | x.await;
| ^^^^^ unknown field
|
= note: to `.await` a `Future`, switch to Rust 2018
= help: set `edition = "2018"` in `Cargo.toml`
= note: for more on editions, read https://doc.rust-lang.org/edition-guide
```
Fixes https://github.com/rust-lang/rust/issues/63533
This PR also performs some preparatory cleanups in `fn check_field`; the last 2 commits are where the suggestion is introduced and tested respectively.
r? @varkor
Continue refactoring resolve and hygiene
The general goal is addressing FIXMEs from the previous PRs.
Merging similar data structures (+ prerequisites for such merging), accounting for the fact that all `ExpnId`s have associated data in `HygieneData` now (less `Option`s).
Also, some renaming.
This should be the last renaming session in this area, I think.
r? @matthewjasper
