Test UI tests for pass=check
I'm going to just compare the builder times since I wasn't able to get this working nicely locally (hit some obscure linker error).
Fixes part of #69823
Rollup of 17 pull requests
Successful merges:
- #72071 (Added detailed error code explanation for issue E0687 in Rust compiler.)
- #72369 (Bring net/parser.rs up to modern up to date with modern rust patterns)
- #72445 (Stabilize `#[track_caller]`.)
- #73466 (impl From<char> for String)
- #73548 (remove rustdoc warnings)
- #73649 (Fix sentence structure)
- #73678 (Update Box::from_raw example to generalize better)
- #73705 (stop taking references in Relate)
- #73716 (Document the static keyword)
- #73752 (Remap Windows ERROR_INVALID_PARAMETER to ErrorKind::InvalidInput from Other)
- #73776 (Move terminator to new module)
- #73778 (Make `likely` and `unlikely` const, gated by feature `const_unlikely`)
- #73805 (Document the type keyword)
- #73806 (Use an 'approximate' universal upper bound when reporting region errors)
- #73828 (Fix wording for anonymous parameter name help)
- #73846 (Fix comma in debug_assert! docs)
- #73847 (Edit cursor.prev() method docs in lexer)
Failed merges:
r? @ghost
Fix wording for anonymous parameter name help
```
--> exercises/functions/functions2.rs:8:15
|
8 | fn call_me(num) {
| ^ expected one of `:`, `@`, or `|`
|
= note: anonymous parameters are removed in the 2018 edition (see RFC 1685)
help: if this is a `self` type, give it a parameter name
|
8 | fn call_me(self: num) {
| ^^^^^^^^^
help: if this was a parameter name, give it a type
|
8 | fn call_me(num: TypeName) {
| ^^^^^^^^^^^^^
help: if this is a type, explicitly ignore the parameter name
|
8 | fn call_me(_: num) {
|
```
This commit changes "if this was a parameter name" to "if this is a parameter name" to match the wording of similar errors.
Use an 'approximate' universal upper bound when reporting region errors
Fixes#67765
When reporting errors during MIR region inference, we sometimes use
`universal_upper_bound` to obtain a named universal region that we
can display to the user. However, this is not always possible - in a
case like `fn foo<'a, 'b>() { .. }`, the only upper bound for a region
containing `'a` and `'b` is `'static`. When displaying diagnostics, it's
usually better to display *some* named region (even if there are
multiple involved) rather than fall back to a generic error involving
`'static`.
This commit adds a new `approx_universal_upper_bound` method, which
uses the lowest-numbered universal region if the only alternative is to
return `'static`.
Document the type keyword
Partial fix of #34601.
Two small examples, one clarifying that `type` only defines an alias, not a completely new type, the other explaining the use in traits.
@rustbot modify labels: T-doc,C-enhancement
Make `likely` and `unlikely` const, gated by feature `const_unlikely`
This PR also contains a fix to allow `#[allow_internal_unstable]` to work properly with `#[rustc_const_unstable]`.
cc @RalfJung @nagisa
r? @oli-obk
Remap Windows ERROR_INVALID_PARAMETER to ErrorKind::InvalidInput from Other
I don't know if this is acceptable or how likely it is to break existing code, but it seem to me ERROR_INVALID_PARAMETER "The parameter is incorrect" should map to ErrorKind::InvalidInput "A parameter was incorrect". Previously this value fell through to ErrorKind::Other.
I can't speak for anyone but myself, but I instinctively thought it would be InvalidInput.
Document the static keyword
Partial fix of #34601.
This documents the `static` keyword. It's basically a simplified version of the reference with more examples.
@rustbot modify labels: T-doc,C-enhancement
stop taking references in Relate
Adds a `Copy` bound to `Relate` and changes the type signatures to `T` from `&T`. While the `Copy` bound is not strictly necessary (i.e. the `Clone` bound of `TypeRelation` would be good enough), we don't need non `Copy` types and it simplifies the implementation.
Removes the afaict unused impls for `Vec<ty::PolyExistentialProjection<'tcx>>`, `Rc<T>` and `Box<T>`. If they end up being relevant again the bound of `Relate` can be reduced to `T: Clone`.
This also changes signature of `Binder::skip_binder` to `fn skip_binder(self) -> T`.
`TypeError::ProjectionBoundsLength` was never used and is also removed in this PR.
r? @nikomatsakis maybe 🤔 feel free to reassign
Update Box::from_raw example to generalize better
I know very little about rust, so I saw the example here
```
use std::alloc::{alloc, Layout};
unsafe {
let ptr = alloc(Layout:🆕:<i32>()) as *mut i32;
*ptr = 5;
let x = Box::from_raw(ptr);
}
```
and tried to generalize it by writing,
```
let layout = Layout:🆕:<T>();
let new_obj = unsafe {
let ptr = alloc(layout) as *mut T;
*ptr = obj;
Box::from_raw(ptr)
};
```
for some more complicated `T`, which ended up crashing with SIGSEGV,
because it tried to `drop_in_place` the previous object in `ptr` which is
of course garbage. I think that changing this example to use `.write` instead
would be a good idea to suggest the correct generalization. It is also more
consistent with other documentation items in this file, which use `.write`.
I also added a comment to explain it, but I'm not too attached to that,
and can see it being too verbose in this place.
Bring net/parser.rs up to modern up to date with modern rust patterns
The current implementation of IP address parsing is very unidiomatic; it's full of `if` / `return` / `is_some` / `is_none` instead of `?`, `loop` with manual index tracking; etc. Went through and did and cleanup to try to bring it in line with modern sensibilities.
The obvious concern with making changes like this is "make sure you understand why it's written that way before changing it". Looking through the commit history for this file, there are several much smaller commits that make similar changes (For instance, 3024c1434a, 4f3ab4986e, 79f876495b), and there don't seem to be any commits in the history that indicate that this lack of idiomaticity is related to specific performance needs (ie, there aren't any commits that replace a `for` loop with a `loop` and a manual index count). In fact, the basic shape of the file is essentially unchanged from its initial commit back in 2015.
Made the following changes throughout the IP address parser:
- Replaced all uses of `is_some()` / `is_none()` with `?`.
- "Upgraded" loops wherever possible; ie, replace `while` with `for`, etc.
- Removed all cases of manual index tracking / incrementing.
- Renamed several single-character variables with more expressive names.
- Replaced several manual control flow segments with equivalent adapters (such as `Option::filter`).
- Removed `read_seq_3`; replaced with simple sequences of `?`.
- Parser now reslices its state when consuming, rather than carrying a separate state and index variable.
- `read_digit` now uses `char::to_digit`.
- Added comments throughout, especially in the complex IPv6 parsing logic.
- Added comprehensive local unit tests for the parser to validate these changes.
Added detailed error code explanation for issue E0687 in Rust compiler.
Added proper error explanation for issue E0687 in the Rust compiler.
Error Code E0687
Sub Part of Issue #61137
r? @GuillaumeGomez
We do not test cross-compilation here as the PR builder lacks a sufficiently
recent LLVM to cross-compile to 32-bit linux. Once we bump the minimum LLVM
version to LLVM 9, this can use normal 32-bit linux.
Revert "ci: allow gating gha on everything but macOS"
The macOS issue on GHA's side seems to be fixed, so this is not needed anymore.
r? @Mark-Simulacrum
Serialize all foreign `SourceFile`s into proc-macro crate metadata
Normally, we encode a `Span` that references a foreign `SourceFile` by
encoding information about the foreign crate. When we decode this
`Span`, we lookup the foreign crate in order to decode the `SourceFile`.
However, this approach does not work for proc-macro crates. When we load
a proc-macro crate, we do not deserialzie any of its dependencies (since
a proc-macro crate can only export proc-macros). This means that we
cannot serialize a reference to an upstream crate, since the associated
metadata will not be available when we try to deserialize it.
This commit modifies foreign span handling so that we treat all foreign
`SourceFile`s as local `SourceFile`s when serializing a proc-macro.
All `SourceFile`s will be stored into the metadata of a proc-macro
crate, allowing us to cotinue to deserialize a proc-macro crate without
needing to load any of its dependencies.
Since the number of foreign `SourceFile`s that we load during a
compilation session may be very large, we only serialize a `SourceFile`
if we have also serialized a `Span` which requires it.
Made the following changes throughout the IP address parser:
- Replaced all uses of `is_some()` / `is_none()` with `?`.
- "Upgraded" loops wherever possible; ie, replace `while` with `for`, etc.
- Removed all cases of manual index tracking / incrementing.
- Renamed several single-character variables with more expressive names.
- Replaced several manual control flow segments with equivalent adapters (such as `Option::filter`).
- Removed `read_seq_3`; replaced with simple sequences of `?`.
- Parser now reslices its state when consuming, rather than carrying a separate state and index variable.
- `read_digit` now uses `char::to_digit`.
- Removed unnecessary casts back and forth between u8 and u32
- Added comments throughout, especially in the complex IPv6 parsing logic.
- Added comprehensive local unit tests for the parser to validate these changes.
bootstrap: Configurable musl libdir
Make it possible to customize the location of musl libdir using
musl-libdir in config.toml, e.g., to use lib64 instead of lib.
[AVR] Update the rust-lang/llvm-project submodule to include AVR fixes recently merged
This PR updates rustc's LLVM submodule to include new AVR-specific
fixes recently merged on the Rust LLVM 'rustc/10.0-2020-05-05' branch.
All of these cherry-picked commits exist in upstream LLVM and were
cherry-picked into Rust's LLVM fork in commit 6c040dd86ed.
Relates to https://github.com/rust-lang/llvm-project/pull/66
```
|- 6c040dd86ed Merge pull request #66 from dylanmckay/avr-pick-upstream-llvm-fixes
|- 12dfdd3aed7 [AVR] Rewrite the function calling convention.
|- 118ac53f12b [AVR] Don't adjust for instruction size
|- bc27c282e13 [AVR] Fix miscompilation of zext + add
|- cfbe205a7e8 [AVR] Remove faulty stack pushing behavior
|- 143e1469e96 [AVR] Fix stack size in functions with a frame pointer
|- 6b2445d841e [LLVM][AVR] Support for R_AVR_6 fixup
|- 93ee4da19cf [AVR] Fix I/O instructions on XMEGA
|- 962c2415ffb [AVR] Do not place functions in .progmem.data
|- 65b8b170aef [AVR] Do not use divmod calls for bigger integers
|- 93a3b595d1c [AVR] Generalize the previous interrupt bugfix to signal
|- handlers too
|- cc4286349b4 [AVR] Respect the 'interrupt' function attribute
|- 954d0a92205 [AVR] Fix reads of uninitialized variables from constructor of AVRSubtarget
|- 1c0ddae73c9 [AVR] Fix read of uninitialized variable AVRSubtarget:::ELFArch
|- 0ed0823fe60 [AVR] Fix incorrect register state for LDRdPtr
|- 96075fc433d [AVR] Don't adjust addresses by 2 for absolute values
|- 6dfc55ba53b [AVR] Use correct register class for mul instructions
```
These changes include both correctness fixes and LLVM assertion error
fixes. Once all of these commits have been cherry-picked, all of the
LLVM plumbing for rust-lang/master to compile the AVR blink program will
be in place. Once this commit is merged, only PR rust-lang/rust#73270 will
be blocking successful compilation and emission of the AVR LED blink program.
The number of symbols we allocate (even early on) seems to be platform
dependent. We only care about hygiene for the purposes of this test,
so just set all of the symbol ids to zero
Normally, we encode a `Span` that references a foreign `SourceFile` by
encoding information about the foreign crate. When we decode this
`Span`, we lookup the foreign crate in order to decode the `SourceFile`.
However, this approach does not work for proc-macro crates. When we load
a proc-macro crate, we do not deserialzie any of its dependencies (since
a proc-macro crate can only export proc-macros). This means that we
cannot serialize a reference to an upstream crate, since the associated
metadata will not be available when we try to deserialize it.
This commit modifies foreign span handling so that we treat all foreign
`SourceFile`s as local `SourceFile`s when serializing a proc-macro.
All `SourceFile`s will be stored into the metadata of a proc-macro
crate, allowing us to cotinue to deserialize a proc-macro crate without
needing to load any of its dependencies.
Since the number of foreign `SourceFile`s that we load during a
compilation session may be very large, we only serialize a `SourceFile`
if we have also serialized a `Span` which requires it.
rustbuild: Move compiler-builtins build logic to manifest
This commit moves the compiler-builtins-specific build logic from
`src/bootstrap/bin/rustc.rs` into the workspace `Cargo.toml`'s
`[profile]` configuration. Now that rust-lang/cargo#7253 is fixed we can
ensure that Cargo knows about debug assertions settings, and it can also
be configured to specifically disable debug assertions unconditionally
for compiler-builtins. This should improve rebuild logic when
debug-assertions settings change and also improve build-std integration
where Cargo externally now has an avenue to learn how to build
compiler-builtins as well.
This commit moves the compiler-builtins-specific build logic from
`src/bootstrap/bin/rustc.rs` into the workspace `Cargo.toml`'s
`[profile]` configuration. Now that rust-lang/cargo#7253 is fixed we can
ensure that Cargo knows about debug assertions settings, and it can also
be configured to specifically disable debug assertions unconditionally
for compiler-builtins. This should improve rebuild logic when
debug-assertions settings change and also improve build-std integration
where Cargo externally now has an avenue to learn how to build
compiler-builtins as well.
stabilize leading_trailing_ones
This PR stabilizes the `leading_trailing_ones` feature. It's been available on nightly since the start of the year, and hasn't had any issues since. It seems unlikely we'll want to change this, so following up on @djc's suggestion in https://github.com/rust-lang/rust/issues/57969#issuecomment-638405264 I'd like to put forward this PR to stabilize the feature and make it part of `1.46.0`. Thanks!
cc/ @djc @rust-lang/libs
Stabilize `#![feature(const_if_match)]`
Quoting from the [stabilization report](https://github.com/rust-lang/rust/issues/49146#issuecomment-616301045):
> `if` and `match` expressions as well as the short-circuiting logic operators `&&` and `||` will become legal in all [const contexts](https://doc.rust-lang.org/reference/const_eval.html#const-context). A const context is any of the following:
>
> - The initializer of a `const`, `static`, `static mut` or enum discriminant.
> - The body of a `const fn`.
> - The value of a const generic (nightly only).
> - The length of an array type (`[u8; 3]`) or an array repeat expression (`[0u8; 3]`).
>
> Furthermore, the short-circuiting logic operators will no longer be lowered to their bitwise equivalents (`&` and `|` respectively) in `const` and `static` initializers (see #57175). As a result, `let` bindings can be used alongside short-circuiting logic in those initializers.
Resolves#49146.
Ideally, we would resolve 🐳#66753 before this lands on stable, so it might be worth pushing this back a release. Also, this means we should get the process started for #52000, otherwise people will have no recourse except recursion for iterative `const fn`.
r? @oli-obk
