Add `implement_via_object` to `rustc_deny_explicit_impl` to control object candidate assembly
Some built-in traits are special, since they are used to prove facts about the program that are important for later phases of compilation such as codegen and CTFE. For example, the `Unsize` trait is used to assert to the compiler that we are able to unsize a type into another type. It doesn't have any methods because it doesn't actually *instruct* the compiler how to do this unsizing, but this is later used (alongside an exhaustive match of combinations of unsizeable types) during codegen to generate unsize coercion code.
Due to this, these built-in traits are incompatible with the type erasure provided by object types. For example, the existence of `dyn Unsize<T>` does not mean that the compiler is able to unsize `Box<dyn Unsize<T>>` into `Box<T>`, since `Unsize` is a *witness* to the fact that a type can be unsized, and it doesn't actually encode that unsizing operation in its vtable as mentioned above.
The old trait solver gets around this fact by having complex control flow that never considers object bounds for certain built-in traits:
2f896da247/compiler/rustc_trait_selection/src/traits/select/candidate_assembly.rs (L61-L132)
However, candidate assembly in the new solver is much more lovely, and I'd hate to add this list of opt-out cases into the new solver. Instead of maintaining this complex and hard-coded control flow, instead we can make this a property of the trait via a built-in attribute. We already have such a build attribute that's applied to every single trait that we care about: `rustc_deny_explicit_impl`. This PR adds `implement_via_object` as a meta-item to that attribute that allows us to opt a trait out of object-bound candidate assembly as well.
r? `@lcnr`
Rollup of 8 pull requests
Successful merges:
- #112232 (Better error for non const `PartialEq` call generated by `match`)
- #112499 (Fix python linting errors)
- #112596 (Suggest correct signature on missing fn returning RPITIT/AFIT)
- #112606 (Alter `Display` for `Ipv6Addr` for IPv4-compatible addresses)
- #112781 (Don't consider TAIT normalizable to hidden ty if it would result in impossible item bounds)
- #112787 (Add gha problem matcher)
- #112799 (Clean up "doc(hidden)" check)
- #112803 (Format the examples directory of cg_clif)
r? `@ghost`
`@rustbot` modify labels: rollup
Add `alloc::rc::UniqueRc`
This PR implements `UniqueRc` as described in https://github.com/rust-lang/libs-team/issues/90.
I've tried to stick to the API proposed there, incorporating the feedback from the ACP review. For now I've just implemented `UniqueRc`, but we'll want `UniqueArc` as well. I wanted to get feedback on this implementation first since the `UniqueArc` version should be mostly a copy/paste/rename job.
This is an `Rc` that is guaranteed to only have one strong reference.
Because it is uniquely owned, it can safely implement `DerefMut`, which
allows programs to have an initialization phase where structures inside
the `Rc` can be mutated.
The `UniqueRc` can then be converted to a regular `Rc`, allowing sharing
and but read-only access.
During the "initialization phase," weak references can be created, but
attempting to upgrade these will fail until the `UniqueRc` has been
converted to a regular `Rc`. This feature can be useful to create
cyclic data structures.
This API is an implementation based on the feedback provided to the ACP
at https://github.com/rust-lang/libs-team/issues/90.
Use BorrowFlag instead of explicit isize
The integer type tracking borrow count has a typedef called `BorrowFlag`. This type should be used instead of explicit `isize`.
[doc] `poll_fn`: explain how to `pin` captured state safely
Usage of `Pin::new_unchecked(&mut …)` is dangerous with `poll_fn`, even though the `!Unpin`-infectiousness has made things smoother. Nonetheless, there are easy ways to avoid the need for any `unsafe` altogether, be it through `Box::pin`ning, or the `pin!` macro. Since the latter only works within an `async` context, showing an example artificially introducing one ought to help people navigate this subtlety with safety and confidence.
## Preview
https://user-images.githubusercontent.com/9920355/230092494-da22fdcb-0b8f-4ff4-a2ac-aa7d9ead077a.mov
```@rustbot``` label +A-docs
[libs] Simplify `unchecked_{shl,shr}`
There's no need for the `const_eval_select` dance here. And while I originally wrote the `.try_into().unwrap_unchecked()` implementation here, it's kinda a mess in MIR -- this new one is substantially simpler, as shown by the old one being above the inlining threshold but the new one being below it in the `mir-opt/inline/unchecked_shifts` tests.
We don't need `u32::checked_shl` doing a dance through both `Result` *and* `Option` 🙃
Usage of `Pin::new_unchecked(&mut …)` is dangerous with `poll_fn`, even
though the `!Unpin`-infectiousness has made things smoother.
Nonetheless, there are easy ways to avoid the need for any `unsafe`
altogether, be it through `Box::pin`ning, or the `pin!` macro. Since the
latter only works within an `async` context, showing an example
artifically introducing one ought to help people navigate this subtlety
with safety and confidence.
std: only depend on dlmalloc for wasm*-unknown
It was already filtered out for emscripten, but wasi doesn't need dlmalloc
either since it reuses `unix/alloc.rs`.
io: soften ‘at most one write attempt’ requirement in io::Write::write
At the moment, documentation of std::io::Write::write indicates that
call to it ‘represents at most one attempt to write to any wrapped
object’. It seems that such wording was put there to contrast it with
pre-1.0 interface which attempted to write all the data (it has since
been changed in [RFC 517]).
However, the requirement puts unnecessary constraints and may
complicate adaptors which perform non-trivial transformations on the
data. For example, they may maintain an internal buffer which needs
to be written out before the write method accepts more data. It might
be natural to code the method such that it flushes the buffer and then
grabs another chunk of user data. With the current wording in the
documentation, the adaptor would be forced to return Ok(0).
This commit softens the wording such that implementations can choose
code structure which makes most sense for their particular use case.
While at it, elaborate on the meaning of `Ok(0)` return pointing out
that the write_all methods interprets it as an error.
[RFC 517]: https://rust-lang.github.io/rfcs/0517-io-os-reform.html
Launch a non-unwinding panic for misaligned pointer deref
This panic already never unwinds, but that's only because it always hits the unwind guard that's created by our `UnwindAction::Terminate`. Hitting the unwind guard generates a huge double-panic backtrace. Now we generate a normal-looking panic message when this check is hit.
r? `@thomcc`
fix: get the l4re target working again
This is based on work from https://github.com/rust-lang/rust/pull/103966, addressing the review comment by `@m-ou-se` at the time and "fixing" the (probably newly) missing read_buf.
Remove `box_free` lang item
This PR removes the `box_free` lang item, replacing it with `Box`'s `Drop` impl. Box dropping is still slightly magic because the contained value is still dropped by the compiler.
Rollup of 6 pull requests
Successful merges:
- #112352 (Fix documentation build on FreeBSD)
- #112644 (Correct types in method descriptions of `NonZero*` types)
- #112683 (fix ICE on specific malformed asm clobber_abi)
- #112707 ([rustdoc] Fix invalid handling of "going back in history" when "go to only search result" setting is enabled)
- #112719 (Replace fvdl with ffx, allow test without install)
- #112728 (Add `<meta charset="utf-8">` to `-Zdump-mir-spanview` output)
r? `@ghost`
`@rustbot` modify labels: rollup
Correct types in method descriptions of `NonZero*` types
- `$Int`: e.g. i32, usize
- `$Ty`: e.g. NonZeroI32, NonZeroUsize
|method|current description|after my changes|
|-|-|-|
|`saturating_add`|...Return `$Int`::MAX on overflow.|...Return `$Ty`::MAX on overflow.|
|`checked_abs`|...returns None if self == `$Int`::MIN.|...returns None if self == `$Ty`::MIN.|
|`checked_neg`|...returning None if self == i32::MIN.|...returning None if self == `$Ty`::MIN.|
|`saturating_neg`|...returning MAX if self == i32::MIN...|...returning `$Ty`::MAX if self == `$Ty`::MIN...|
|`saturating_mul`|...Return `$Int`::MAX...|...Return `$Ty`::MAX...|
|`saturating_pow`|...Return `$Int`::MIN or `$Int`::MAX...|...Return `$Ty`::MIN or `$Ty`::MAX...|
---
For example:
```rust
pub const fn saturating_neg(self) -> NonZeroI128
```
- current
- Saturating negation. Computes `-self`, returning `MAX` if `self == i32::MIN` instead of overflowing.
- after my changes
- Saturating negation. Computes `-self`, returning `NonZeroI128::MAX` if `self == NonZeroI128::MIN` instead of overflowing.
Fix documentation build on FreeBSD
After the socket ancillary data implementation was introduced, the documentation build was broken on FreeBSD hosts, add the same workaround as for the existing implementations.
Fixes the doc build after #91793
previously it was only able to use BufWriter. This was due to a limitation in the
BufReader generics that prevented specialization. This change works around the issue
by using `where Self: Read` instead of `where I: Read`. This limits our options, e.g.
we can't access BufRead methods, but it happens to work out if we rely on some
implementation details.
There's no need for the `const_eval_select` dance here. And while I originally wrote the `.try_into().unwrap_unchecked()` implementation here, it's kinda a mess in MIR -- this new one is substantially simpler, as shown by the old one being above the inlining threshold but the new one being below it.
`#[lang_item]` for `core::ptr::Unique`
Tree Borrows is about to introduce experimental special handling of `core::ptr::Unique` in Miri to give it a semantics.
As of now there does not seem to be a clean way (i.e. other than `&format!("{adt:?}") == "std::ptr::Unique"`) to check if an `AdtDef` represents a `Unique`.
r? `@RalfJung`
Draft: making a lang item
Fix building libstd documentation on FreeBSD.
It fixes the following error:
```
error[E0412]: cannot find type `sockcred2` in module `libc`
--> library/std/src/os/unix/net/ancillary.rs:211:29
|
211 | pub struct SocketCred(libc::sockcred2);
| ^^^^^^^^^ not found in `libc`
```
Extend `unused_must_use` to cover block exprs
Given code like
```rust
#[must_use]
fn foo() -> i32 {
42
}
fn warns() {
{
foo();
}
}
fn does_not_warn() {
{
foo()
};
}
fn main() {
warns();
does_not_warn();
}
```
### Before This PR
```
warning: unused return value of `foo` that must be used
--> test.rs:8:9
|
8 | foo();
| ^^^^^
|
= note: `#[warn(unused_must_use)]` on by default
help: use `let _ = ...` to ignore the resulting value
|
8 | let _ = foo();
| +++++++
warning: 1 warning emitted
```
### After This PR
```
warning: unused return value of `foo` that must be used
--> test.rs:8:9
|
8 | foo();
| ^^^^^
|
= note: `#[warn(unused_must_use)]` on by default
help: use `let _ = ...` to ignore the resulting value
|
8 | let _ = foo();
| +++++++
warning: unused return value of `foo` that must be used
--> test.rs:14:9
|
14 | foo()
| ^^^^^
|
help: use `let _ = ...` to ignore the resulting value
|
14 | let _ = foo();
| +++++++ +
warning: 2 warnings emitted
```
Fixes#104253.
This commit reverts a change made in #111425.
It was believed that this change was necessary for implementing type privacy lints, but #111801 showed that it was not necessary.
Quite opposite, the revert fixes some issues.
Mention `env!` in `option_env!`'s docs
`env!` mentions that there is an alternative that returns an `Option<...>` instead of emitting a compile error.
Now `option_env!` also mentions that there is an alternative that emits a compile error instead of returning an `Option<...>`.
Update runtime guarantee for `select_nth_unstable`
#106933 changed the runtime guarantee for `select_nth_unstable` from O(n) to O(n log n), since the old guarantee wasn't actually met by the implementation at the time. Now with #107522, `select_nth_unstable` should be truly linear in runtime, so we can revert its runtime guarantee to O(n). Since #106933 was considered a bug fix, this will probably need an FCP because it counts as a new API guarantee.
r? `@Amanieu`
Stabilize String::leak
Stabilizes the following API:
```Rust
impl String {
pub fn leak(self) -> &'static mut str;
}
```
closes#102929
blocked by having an FCP for stabilization.
Implement `TryFrom<&OsStr>` for `&str`
Recently when trying to work with `&OsStr` I was surprised to find this `impl` missing.
Since the `to_str` method already existed the actual implementation is fairly non-controversial, except for maybe the choice of the error type. I chose an opaque error here instead of something like `std::str::Utf8Error`, since that would already make a number of assumption about the underlying implementation of `OsStr`.
As this is a trait implementation, it is insta-stable, if I'm not mistaken?
Either way this will need an FCP.
I chose "1.64.0" as the version, since this is unlikely to land before the beta cut-off.
`@rustbot` modify labels: +T-libs-api
API Change Proposal: rust-lang/rust#99031 (accepted)
Add support for targets without unwinding in `mir-opt`, and improve `--bless` for it
The main goal of this PR is to add support for targets without unwinding support in the `mir-opt` test suite, by adding the `EMIT_MIR_FOR_EACH_PANIC_STRATEGY` comment. Similarly to 32bit vs 64bit, when that comment is present, blessed output files will have the `.panic-unwind` or `.panic-abort` suffix, and the right one will be chosen depending on the target's panic strategy.
The `EMIT_MIR_FOR_EACH_PANIC_STRATEGY` comment replaced all the `ignore-wasm32` comments in the `mir-opt` test suite, as those comments were added due to `wasm32` being a target without unwinding support. The comment was also added on other tests that were only executed on x86 but were still panic strategy dependent.
The `mir-opt` suite was then blessed, which caused a ton of churn as most of the existing output files had to be renamed and (mostly) duplicated with the abort strategy.
---
After [asking on Zulip](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/mir-opt.20tests.20and.20panic.3Dabort), the main concern about this change is it'd make blessing the `mir-opt` suite even harder, as you'd need to both bless it with an unwinding target and an aborting target. This exacerbated the current situation, where you'd need to bless it with a 32bit and a 64bit target already.
Because of that, this PR also makes significant enhancements to `--bless` for the `mir-opt` suite, where it will automatically bless the suite four times with different targets, while requiring minimal cross-compilation.
To handle the 32bit vs 64bit blessing, there is now an hardcoded list of target mapping between 32bit and 64bit. The goal of the list is to find a related target that will *probably* work without requiring additional cross-compilation toolchains on the system. If a mapping is found, bootstrap will bless the suite with both targets, otherwise just with the current target.
To handle the panic strategy blessing (abort vs unwind), I had to resort to what I call "synthetic targets". For each of the target we're blessing (so either the current one, or a 32bit and a 64bit depending on the previous paragraph), bootstrap will extract the JSON spec of the target and change it to include `"panic-strategy": "abort"`. It will then build the standard library with this synthetic target, and bless the `mir-opt` suite with it.
As a result of these changes, blessing the `mir-opt` suite will actually bless it two or four times with different targets, ensuring all possible variants are actually blessed.
---
This PR is best reviewed commit-by-commit.
r? `@jyn514`
cc `@saethlin` `@oli-obk`
Ignore `core`, `alloc` and `test` tests that require unwinding on `-C panic=abort`
Some of the tests for `core` and `alloc` require unwinding through their use of `catch_unwind`. These tests fail when testing using `-C panic=abort` (in my case through a target without unwinding support, and `-Z panic-abort-tests`), while they should be ignored as they don't indicate a failure.
This PR marks all of these tests with this attribute:
```rust
#[cfg_attr(not(panic = "unwind"), ignore = "test requires unwinding support")]
```
I'm not aware of a way to test this on rust-lang/rust's CI, as we don't test any target with `-C panic=abort`, but I tested this locally on a Ferrocene target and it does indeed make the test suite pass.
It fixes the following error:
error[E0412]: cannot find type `sockcred2` in module `libc`
--> library/std/src/os/unix/net/ancillary.rs:211:29
|
211 | pub struct SocketCred(libc::sockcred2);
| ^^^^^^^^^ not found in `libc`
Make BinaryHeap parametric over Allocator
Tracking issue: #32838
Related: https://github.com/rust-lang/wg-allocators/issues/7
This parametrizes `BinaryHeap` with `A`, similarly to how other collections are parametrized.
A couple things I left out:
```
BinaryHeap::append
Currently requires both structures to have the same allocator type. Could
change, but depends on Vec::append, which has the same constraints.
impl<T: Ord> Default for BinaryHeap<T>
Not parametrized, because there's nowhere to conjure the allocator from.
impl<T: Ord> FromIterator<T> for BinaryHeap<T>
Not parametrized, because there's nowhere to conjure the allocator from.
impl<T: Ord, const N: usize> From<[T; N]> for BinaryHeap<T>
Not parametrized, because there's nowhere to conjure the allocator from.
unsafe impl<I> AsVecIntoIter for IntoIter<I>
AsVecIntoIter is not allocator aware, and I didn't dare change it without guidance. Is this something important?
```
I've seen very few tests for allocator_api in general, but I'd like to at least test this on some usage code in my projects before moving forward.
EDIT: Updated the list of impls and functions that are not affected by this. `BinaryHeap` no longer has a `SpecExtend` impl, and prior work made implementing `Extend` possible.
It might happen that a synthetic target name does not match one of the
hardcoded ones in std's build script, causing std to fail to build. This
commit changes the std build script avoid including the restricted-std
feature unconditionally when a synthetic target is being built.
Fix ntdll linkage issues on Windows UWP platforms
See discussion: https://github.com/rust-lang/rust/issues/112265#issuecomment-1575479683
Static loading `ntdll` functions does not work for UWP programs, which will end up link errors complaining about missing symbols, or failure to pass the WACK tests. The breakage was introduced in #108262.
This PR basically reverts part of the changes in #108262 for UWP only, and fixes some lint suggestions.
