bors [Wed, 30 Mar 2022 12:28:50 +0000 (12:28 +0000)]
Auto merge of #94963 - lcnr:inherent-impls-std, r=oli-obk,m-ou-se
allow arbitrary inherent impls for builtin types in core
Part of https://github.com/rust-lang/compiler-team/issues/487. Slightly adjusted after some talks with `@m-ou-se` about the requirements of `t-libs-api`.
This adds a crate attribute `#![rustc_coherence_is_core]` which allows arbitrary impls for builtin types in core.
For other library crates impls for builtin types should be avoided if possible. We do have to allow the existing stable impls however. To prevent us from accidentally adding more of these in the future, there is a second attribute `#[rustc_allow_incoherent_impl]` which has to be added to **all impl items**. This only supports impls for builtin types but can easily be extended to additional types in a future PR.
This implementation does not check for overlaps in these impls. Perfectly checking that requires us to check the coherence of these incoherent impls in every crate, as two distinct dependencies may add overlapping methods. It should be easy enough to detect if it goes wrong and the attribute is only intended for use inside of std.
The first two commits are mostly unrelated cleanups.
bors [Wed, 30 Mar 2022 10:09:10 +0000 (10:09 +0000)]
Auto merge of #95241 - Gankra:cleaned-provenance, r=workingjubilee
Strict Provenance MVP
This patch series examines the question: how bad would it be if we adopted
an extremely strict pointer provenance model that completely banished all
int<->ptr casts.
The key insight to making this approach even *vaguely* pallatable is the
ptr.with_addr(addr) -> ptr
function, which takes a pointer and an address and creates a new pointer
with that address and the provenance of the input pointer. In this way
the "chain of custody" is completely and dynamically restored, making the
model suitable even for dynamic checkers like CHERI and Miri.
This is not a formal model, but lots of the docs discussing the model
have been updated to try to the *concept* of this design in the hopes
that it can be iterated on.
bors [Wed, 30 Mar 2022 07:45:42 +0000 (07:45 +0000)]
Auto merge of #95466 - Dylan-DPC:rollup-g7ddr8y, r=Dylan-DPC
Rollup of 5 pull requests
Successful merges:
- #95294 (Document Linux kernel handoff in std::io::copy and std::fs::copy)
- #95443 (Clarify how `src/tools/x` searches for python)
- #95452 (fix since field version for termination stabilization)
- #95460 (Spellchecking compiler code)
- #95461 (Spellchecking some comments)
bors [Wed, 30 Mar 2022 05:04:45 +0000 (05:04 +0000)]
Auto merge of #94081 - oli-obk:lazy_tait_take_two, r=nikomatsakis
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 #93893
Aria Beingessner [Tue, 22 Mar 2022 05:27:28 +0000 (01:27 -0400)]
Introduce experimental APIs for conforming to "strict provenance".
This patch series examines the question: how bad would it be if we adopted
an extremely strict pointer provenance model that completely banished all
int<->ptr casts.
The key insight to making this approach even *vaguely* pallatable is the
ptr.with_addr(addr) -> ptr
function, which takes a pointer and an address and creates a new pointer
with that address and the provenance of the input pointer. In this way
the "chain of custody" is completely and dynamically restored, making the
model suitable even for dynamic checkers like CHERI and Miri.
This is not a formal model, but lots of the docs discussing the model
have been updated to try to the *concept* of this design in the hopes
that it can be iterated on.
Currently, matches within a sequence are recorded in a new empty
`matches` vector. Then when the sequence finishes the matches are merged
into the `matches` vector of the parent.
This commit changes things so that a sequence mp inherits the matches
made so far. This means that additional matches from the sequence don't
need to be merged into the parent. `push_match` becomes more
complicated, and the current sequence depth needs to be tracked. But
it's a sizeable performance win because it avoids one or more
`push_match` calls on every iteration of a sequence.
The commit also removes `match_hi`, which is no longer necessary.
Dylan DPC [Tue, 29 Mar 2022 20:46:34 +0000 (22:46 +0200)]
Rollup merge of #95386 - compiler-errors:try-wrapping, r=oli-obk
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):
- 07776c111f07b887cd46b752870cd3fd76b2ba7c: 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)
Dylan DPC [Tue, 29 Mar 2022 20:46:31 +0000 (22:46 +0200)]
Rollup merge of #93840 - yaahc:termination-stabilization-celebration-station, r=joshtriplett
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:
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.
bors [Tue, 29 Mar 2022 17:48:40 +0000 (17:48 +0000)]
Auto merge of #95433 - Dylan-DPC:rollup-xdfit9h, r=Dylan-DPC
Rollup of 4 pull requests
Successful merges:
- #94566 (Show ignore message in console and json output)
- #95415 (diagnostics: regression test for HashMap iter_mut suggestion)
- #95422 (Refactor: Use `format-args-capture` and remove an unnecessary nested block)
- #95424 (:arrow_up: rust-analyzer)
This is another take on https://github.com/rust-lang/rust/issues/89673 (compared to https://github.com/rust-lang/rust/pull/91217) but very different on the approach: I moved the header call in one place but still require to have the `clean::Item` so I can use the `DefId` to get what is missing.
cc `@jyn514` (you reviewed the original so maybe you want to take a look?)
r? `@camelid`
bors [Tue, 29 Mar 2022 07:27:14 +0000 (07:27 +0000)]
Auto merge of #95257 - compiler-errors:fn-borrow, r=lcnr
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.
bors [Tue, 29 Mar 2022 05:15:58 +0000 (05:15 +0000)]
Auto merge of #95423 - ehuss:update-books, r=ehuss
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)
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. Fixes rust-lang/book#2716.
- Fancy quotes
- Fix incorrectly worded sentence. Fixes rust-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. Fixes rust-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.
bors [Tue, 29 Mar 2022 01:09:22 +0000 (01:09 +0000)]
Auto merge of #95417 - ehuss:doc-no_std-error, r=Dylan-DPC
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`](https://github.com/rust-lang/rust/blob/600ec284838c52d1f6657c2cf0097b58970b133b/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.
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.
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
```
Dylan DPC [Mon, 28 Mar 2022 18:41:52 +0000 (20:41 +0200)]
Rollup merge of #95397 - dtolnay:disclaimer, r=m-ou-se
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.
Separate dependencies for `parallel_compiler` feature, so they will not be compiled if feature not selected, reducing number of compiled crates from 238 to 224.
projects / rust.git / log