Lazy type-alias-impl-trait take two
### user visible change 1: RPIT inference from recursive call sites
Lazy TAIT has an insta-stable change. The following snippet now compiles, because opaque types can now have their hidden type set from wherever the opaque type is mentioned.
```rust
fn bar(b: bool) -> impl std::fmt::Debug {
if b {
return 42
}
let x: u32 = bar(false); // this errors on stable
99
}
```
The return type of `bar` stays opaque, you can't do `bar(false) + 42`, you need to actually mention the hidden type.
### user visible change 2: divergence between RPIT and TAIT in return statements
Note that `return` statements and the trailing return expression are special with RPIT (but not TAIT). So
```rust
#![feature(type_alias_impl_trait)]
type Foo = impl std::fmt::Debug;
fn foo(b: bool) -> Foo {
if b {
return vec![42];
}
std::iter::empty().collect() //~ ERROR `Foo` cannot be built from an iterator
}
fn bar(b: bool) -> impl std::fmt::Debug {
if b {
return vec![42]
}
std::iter::empty().collect() // Works, magic (accidentally stabilized, not intended)
}
```
But when we are working with the return value of a recursive call, the behavior of RPIT and TAIT is the same:
```rust
type Foo = impl std::fmt::Debug;
fn foo(b: bool) -> Foo {
if b {
return vec![];
}
let mut x = foo(false);
x = std::iter::empty().collect(); //~ ERROR `Foo` cannot be built from an iterator
vec![]
}
fn bar(b: bool) -> impl std::fmt::Debug {
if b {
return vec![];
}
let mut x = bar(false);
x = std::iter::empty().collect(); //~ ERROR `impl Debug` cannot be built from an iterator
vec![]
}
```
### user visible change 3: TAIT does not merge types across branches
In contrast to RPIT, TAIT does not merge types across branches, so the following does not compile.
```rust
type Foo = impl std::fmt::Debug;
fn foo(b: bool) -> Foo {
if b {
vec![42_i32]
} else {
std::iter::empty().collect()
//~^ ERROR `Foo` cannot be built from an iterator over elements of type `_`
}
}
```
It is easy to support, but we should make an explicit decision to include the additional complexity in the implementation (it's not much, see a721052457cf513487fb4266e3ade65c29b272d2 which needs to be reverted to enable this).
### PR formalities
previous attempt: #92007
This PR also includes #92306 and #93783, as they were reverted along with #92007 in #93893fixes#93411fixes#88236fixes#89312fixes#87340fixes#86800fixes#86719fixes#84073fixes#83919fixes#82139fixes#77987fixes#74282fixes#67830fixes#62742fixes#54895
Suggest wrapping patterns in enum variants
Structured suggestion to wrap a pattern in a single-field enum or struct:
```diff
struct A;
enum B {
A(A),
}
fn main(b: B) {
match b {
- A => {}
+ B::A(A) => {}
}
}
```
Half of #94942, the other half I'm not exactly sure how to fix.
Also includes two drive-by changes (that I am open to splitting out into another PR, but thought they could be rolled up into this one):
- 07776c111f: Makes sure not to suggest wrapping if it doesn't have tuple field constructor (i.e. has named fields)
- 8f2bbb18fd53e5008bb488302dbd354577698ede: Also suggest wrapping expressions in a tuple struct (not just enum variants)
Ensure io::Error's bitpacked repr doesn't accidentally impl UnwindSafe
Sadly, I'm not sure how to easily test that we don't impl a trait, though (or can libstd use `where io::Error: !UnwindSafe` or something).
Fixes#95203
Stabilize Termination and ExitCode
From https://github.com/rust-lang/rust/issues/43301
This PR stabilizes the Termination trait and associated ExitCode type. It also adjusts the ExitCode feature flag to replace the placeholder flag with a more permanent name, as well as splitting off the `to_i32` method behind its own permanently unstable feature flag.
This PR stabilizes the termination trait with the following signature:
```rust
pub trait Termination {
fn report(self) -> ExitCode;
}
```
The existing impls of `Termination` are effectively already stable due to the prior stabilization of `?` in main.
This PR also stabilizes the following APIs on exit code
```rust
#[derive(Clone, Copy, Debug)]
pub struct ExitCode(_);
impl ExitCode {
pub const SUCCESS: ExitCode;
pub const FAILURE: ExitCode;
}
impl From<u8> for ExitCode { /* ... */ }
```
---
All of the previous blockers have been resolved. The main ones that were resolved recently are:
* The trait's name: We decided against changing this since none of the alternatives seemed particularly compelling. Instead we decided to end the bikeshedding and stick with the current name. ([link to the discussion](https://rust-lang.zulipchat.com/#narrow/stream/219381-t-libs/topic/Termination.2FExit.20Status.20Stabilization/near/269793887))
* Issues around platform specific representations: We resolved this issue by changing the return type of `report` from `i32` to the opaque type `ExitCode`. That way we can change the underlying representation without affecting the API, letting us offer full support for platform specific exit code APIs in the future.
* Custom exit codes: We resolved this by adding `From<u8> for ExitCode`. We choose to only support u8 initially because it is the least common denominator between the sets of exit codes supported by our current platforms. In the future we anticipate adding platform specific extension traits to ExitCode for constructors from larger or negative numbers, as needed.
Show ignore message in console and json output
- Provide ignore the message in console and JSON output
- Modify the ignore message style in the log file
related: #92714
Show ignore message in console and json output
- Provide ignore the message in console and JSON output
- Modify the ignore message style in the log file
related: #92714
Fix build on i686-apple-darwin systems
Replace `target_arch = "x86_64"` with `not(target_arch = "aarch64")` so that i686-apple-darwin systems dynamically choose implementation.
Add suggestion to borrow `Fn` and `FnMut` params/opaque/closures instead of move
I think that Closure/ParamTy/Opaque are all "opaque" enough that it's meaningful to suggest borrowing them instead of moving them at their usage sites when we see a move error. See the attached issue for example.
Is this suggestion too general? I could perhaps use the move site information to limit this to places like fn calls, but I don't know enough about mir borrowck to know if that's an easy change.
Fixes#90828
Update books
## nomicon
3 commits in f6d6126fc96ecf4a7f7d22da330df9506293b0d0..11f1165e8a2f5840467e748c8108dc53c948ee9a
2022-02-26 02:21:21 +0900 to 2022-03-19 16:02:00 -0400
- Make the Vec impl be slightly more careful with ZSTs and alignment.
- implement `IntoIterator` for `Vec` (rust-lang/nomicon#337)
- Add an explanation shared to exclusive transmute (rust-lang/nomicon#344)
## reference
2 commits in 0a2fe6651fbccc6416c5110fdf5b93fb3cb29247..c97d14fa6fed0baa9255432b8a93cb70614f80e3
2022-03-15 09:32:25 -0700 to 2022-03-19 18:18:10 -0700
- Fixed inconsistency in the usage of semicolon at end of scopes (rust-lang/reference#1182)
- Document ADX `target_feature` (rust-lang/reference#1172)
## book
23 commits in 036e88a4f135365de85358febe5324976a56030a..ea90bbaf53ba64ef4e2da9ac2352b298aec6bec8
2022-03-04 21:53:33 -0500 to 2022-03-28 21:59:34 -0400
- Fix nostarch snapshot
- Snapshot of chapter 7 for nostarch
- Add a forward reference to chapter 14, another example of pub use
- Clarify pub use example. Fixesrust-lang/book#2716.
- Fancy quotes
- Fix incorrectly worded sentence. Fixesrust-lang/book#3086.
- Reword description of how a listing came to be
- Call out binary+library crate practices
- Define binary and library crates more explicitly
- Clarify when a path is a crate name and when it should be literal crate
- Make it clearer the outer `mod` doesn't move to the file
- Don't wrap this example in main when copying. Fixesrust-lang/book#2930.
- Try to make clearer that `mod` is not an `import`
- Mention mod.rs file naming scheme
- Explain why submodule subdirectories are needed more
- Rename a separate example of serve_order to deliver_order
- Show an example that `use` only applies in its own scope
- quick modules guide
- Tweak a snippet of ch18-03
- Propagating edits to chapter 10 back
- Responses to nostarch questions of chapter 10
- Update src/ch04-01-what-is-ownership.md
- Add Danish translation link. Connects to rust-lang/book#3079.
## rust-by-example
2 commits in d504324f1e7dc7edb918ac39baae69f1f1513b8e..ec954f35eedf592cd173b21c05a7f80a65b61d8a
2022-03-07 09:26:32 -0300 to 2022-03-22 11:09:06 -0300
- PathBuf details and example (rust-lang/rust-by-example#1519)
- Move allow dead code attribute and add comment (rust-lang/rust-by-example#1518)
## rustc-dev-guide
1 commits in 0e4b961a9c708647bca231430ce1b199993e0196..155126b1d2e2cb01ddb1d7ba9489b90d7cd173ad
2022-03-14 08:40:37 -0700 to 2022-03-22 14:34:21 +0100
- update section for type system constants (rust-lang/rustc-dev-guide#1329)
## embedded-book
1 commits in d5fc1bce3f8eb398f9c25f1b15e0257d7537cd41..a6de8b6e3ea5d4f0de8b7b9a7e5c1405dc2c2ddb
2022-01-24 07:13:31 +0000 to 2022-03-17 21:21:39 +0000
- Update OpenOCD install instruction for rust-embedded/book#313 (rust-embedded/book#314)
bootstrap: better error message for no_std docs
Currently if one tries to build std documentation for a no_std target, you get a confusing error message:
`error: The argument '--package [<SPEC>...]' was provided more than once, but cannot be used multiple times`
This is because [`std_cargo`](600ec28483/src/bootstrap/compile.rs (L299-L305)) has a built-in `-p alloc` argument that conflicts with the `cargo rustdoc` command used in the Std doc step.
This just adds a better error message in this scenario. It may be possible to fix this correctly, but that would likely be a bit more of an invasive change that I don't have time for right now.
Refactor set_ptr_value as with_metadata_of
Replaces `set_ptr_value` (#75091) with methods of reversed argument order:
```rust
impl<T: ?Sized> *mut T {
pub fn with_metadata_of<U: ?Sized>(self, val: *mut U) -> *mut U;
}
impl<T: ?Sized> *const T {
pub fn with_metadata_of<U: ?Sized>(self, val: *const U) -> *const U;
}
```
By reversing the arguments we achieve several clarifications:
- The function closely resembles `cast` with an argument to
initialize the metadata. This is easier to teach and answers a long
outstanding question that had restricted cast to `Sized` pointee
targets. See multiples reviews of
<https://github.com/rust-lang/rust/pull/47631>
- The 'object identity', in the form of provenance, is now preserved
from the receiver argument to the result. This helps explain the method as
a builder-style, instead of some kind of setter that would modify
something in-place. Ensuring that the result has the identity of the
`self` argument is also beneficial for an intuition of effects.
- An outstanding concern, 'Correct argument type', is avoided by not
committing to any specific argument type. This is consistent with cast
which does not require its receiver to be a 'raw address'.
Hopefully the usage examples in `sync/rc.rs` serve as sufficient examples of the style to convince the reader of the readability improvements of this style, when compared to the previous order of arguments.
I want to take the opportunity to motivate inclusion of this method _separate_ from metadata API, separate from `feature(ptr_metadata)`. It does _not_ involve the `Pointee` trait in any form. This may be regarded as a very, very light form that does not commit to any details of the pointee trait, or its associated metadata. There are several use cases for which this is already sufficient and no further inspection of metadata is necessary.
- Storing the coercion of `*mut T` into `*mut dyn Trait` as a way to dynamically cast some an arbitrary instance of the same type to a dyn trait instance. In particular, one can have a field of type `Option<*mut dyn io::Seek>` to memorize if a particular writer is seekable. Then a method `fn(self: &T) -> Option<&dyn Seek>` can be provided, which does _not_ involve the static trait bound `T: Seek`. This makes it possible to create an API that is capable of utilizing seekable streams and non-seekable streams (instead of a possible less efficient manner such as more buffering) through the same entry-point.
- Enabling more generic forms of unsizing for no-`std` smart pointers. Using the stable APIs only few concrete cases are available. One can unsize arrays to `[T]` by `ptr::slice_from_raw_parts` but unsizing a custom smart pointer to, e.g., `dyn Iterator`, `dyn Future`, `dyn Debug`, can't easily be done generically. Exposing `with_metadata_of` would allow smart pointers to offer their own `unsafe` escape hatch with similar parameters where the caller provides the unsized metadata. This is particularly interesting for embedded where `dyn`-trait usage can drastically reduce code size.
Inline u8::is_utf8_char_boundary
Since Rust beta, Rust is incapable of inlining this function in the following example function.
```rust
pub fn safe_substr_to(s: &str, mut length: usize) -> &str {
loop {
if let Some(s) = s.get(..length) {
return s;
}
length -= 1;
}
}
```
When compiled with beta or nightly compiler on Godbolt with `-C opt-level=3` flag it prints the following assembly.
```asm
example::safe_substr_to:
push r15
push r14
push r12
push rbx
push rax
mov r14, rdi
test rdx, rdx
je .LBB0_8
mov rbx, rdx
mov r15, rsi
mov r12, qword ptr [rip + core::num::<impl u8>::is_utf8_char_boundary@GOTPCREL]
jmp .LBB0_4
.LBB0_2:
je .LBB0_9
.LBB0_3:
add rbx, -1
je .LBB0_8
.LBB0_4:
cmp rbx, r15
jae .LBB0_2
movzx edi, byte ptr [r14 + rbx]
call r12
test al, al
je .LBB0_3
mov r15, rbx
jmp .LBB0_9
.LBB0_8:
xor r15d, r15d
.LBB0_9:
mov rax, r14
mov rdx, r15
add rsp, 8
pop rbx
pop r12
pop r14
pop r15
ret
```
`qword ptr [rip + core::num::<impl u8>::is_utf8_char_boundary@GOTPCREL]` is not inlined. `-C remark=all` outputs the following message:
```
note: /rustc/7bccde19767082c7865a12902fa614ed4f8fed73/library/core/src/str/mod.rs:214:25: inline: _ZN4core3num20_$LT$impl$u20$u8$GT$21is_utf8_char_boundary17hace9f12f5ba07a7fE will not be inlined into _ZN4core3str21_$LT$impl$u20$str$GT$16is_char_boundary17hf2587e9a6b8c5e43E because its definition is unavailable
```
Stable compiler outputs more reasonable code:
```asm
example::safe_substr_to:
mov rcx, rdx
mov rax, rdi
test rdx, rdx
je .LBB0_9
mov rdx, rsi
jmp .LBB0_4
.LBB0_2:
cmp rdx, rcx
je .LBB0_7
.LBB0_3:
add rcx, -1
je .LBB0_9
.LBB0_4:
cmp rcx, rdx
jae .LBB0_2
cmp byte ptr [rax + rcx], -64
jl .LBB0_3
mov rdx, rcx
.LBB0_7:
ret
.LBB0_9:
xor edx, edx
ret
```
Link to std::io's platform-specific behavior disclaimer
This PR adds some links in standard library documentation to point to https://doc.rust-lang.org/std/io/index.html#platform-specific-behavior.
> ### Platform-specific behavior
>
> Many I/O functions throughout the standard library are documented to indicate what various library or syscalls they are delegated to. This is done to help applications both understand what’s happening under the hood as well as investigate any possibly unclear semantics. Note, however, that this is informative, not a binding contract. The implementation of many of these functions are subject to change over time and may call fewer or more syscalls/library functions.
Many of the `std::fs` APIs already link to this disclaimer when discussing system calls.
