rustc_target: treat enum variants like union members, in call ABIs.
Fixes#68190, by handling non-C-like `enum`s as-if they were an `union` of `struct`s, in call ABIs.
Tests were provided by @sw17ch, from theirs and @bitwalker's original examples.
cc @nagisa @rkruppe
Remove some unsound specializations
This removes the unsound and exploitable specializations in the standard library
* The `PartialEq` and `Hash` implementations for `RangeInclusive` are changed to avoid specialization.
* The `PartialOrd` specialization for slices now specializes on a limited set of concrete types.
* Added some tests for the soundness problems.
replace the leak check with universes, take 2
This PR is an attempt to revive the "universe-based region check", which is an important step towards lazy normalization. Unlike before, we also modify the definition of `'empty` so that it is indexed by a universe. This sidesteps some of the surprising effects we saw before -- at the core, we no longer think that `exists<'a> { forall<'b> { 'b: 'a } }` is solveable. The new region lattice looks like this:
```
static ----------+-----...------+ (greatest)
| | |
early-bound and | |
free regions | |
| | |
scope regions | |
| | |
empty(root) placeholder(U1) |
| / |
| / placeholder(Un)
empty(U1) -- /
| /
... /
| /
empty(Un) -------- (smallest)
```
This PR has three effects:
* It changes a fair number of error messages, I think for the better.
* It fixes a number of bugs. The old algorithm was too conservative and caused us to reject legal subtypings.
* It also causes two regressions (things that used to compile, but now do not).
* `coherence-subtyping.rs` gets an additional error. This is expected.
* `issue-57639.rs` regresses as before, for the reasons covered in #57639.
Both of the regressions stem from the same underlying property: without the leak check, the instantaneous "subtype" check is not able to tell whether higher-ranked subtyping will succeed or not. In both cases, we might be able to fix the problem by doing a 'leak-check like change' at some later point (e.g., as part of coherence).
This is a draft PR because:
* I didn't finish ripping out the leak-check completely.
* We might want to consider a crater run before landing this.
* We might want some kind of design meeting to cover the overall strategy.
* I just remembered I never finished 100% integrating this into the canonicalization code.
* I should also review what happens in NLL region checking -- it probably still has a notion of bottom (empty set).
r? @matthewjasper
Selectively disable sanitizer instrumentation
Add `no_sanitize` attribute that allows to opt out from sanitizer
instrumentation in an annotated function.
stop using BytePos for computing spans in librustc_parse/parser/mod.rs
Computing spans using logic such as `self.token.span.lo() + BytePos(1)` can cause internal compiler errors like #68730 when non-ascii characters are given as input.
#68735 partially addressed this problem, but only for one case. Moreover, its usage of `next_point()` does not actually align with what `bump_with()` expects. For example, given the token `>>=`, we should pass the span consisting of the final two characters `>=`, but `next_point()` advances the span beyond the end of the `=`.
This pull request instead computes the start of the new span by doing `start_point(self.token.span).hi()`. This matches `self.token.span.lo() + BytePos(1)` in the common case where the characters are ascii, and it gracefully handles multibyte characters.
Fixes#68783.
Towards unified `fn` grammar
Part of https://github.com/rust-lang/rust/pull/68728.
- Syntactically, `fn` items in `extern { ... }` blocks can now have bodies (`fn foo() { ... }` as opposed to `fn foo();`). As above, we use semantic restrictions instead.
- Syntactically, `fn` items in free contexts (directly in a file or a module) can now be without bodies (`fn foo();` as opposed to `fn foo() { ... }`. As above, we use semantic restrictions instead, including for non-ident parameter patterns.
- We move towards unifying the `fn` front matter; this is fully realized in https://github.com/rust-lang/rust/pull/68728.
r? @petrochenkov
Account for HR lifetimes when suggesting introduction of named lifetime
```
error[E0106]: missing lifetime specifier
--> src/test/ui/suggestions/fn-missing-lifetime-in-item.rs:2:32
|
2 | struct S2<F: Fn(&i32, &i32) -> &i32>(F);
| ---- ---- ^ expected named lifetime parameter
|
= help: this function's return type contains a borrowed value, but the signature does not say whether it is borrowed from argument 1 or argument 2
= note: for more information on higher-ranked polymorphism, visit https://doc.rust-lang.org/nomicon/hrtb.html
help: consider making the bound lifetime-generic with a new `'a` lifetime
|
2 | struct S2<F: for<'a> Fn(&'a i32, &'a i32) -> &'a i32>(F);
| ^^^^^^^ ^^^^^^^ ^^^^^^^ ^^^
help: consider introducing a named lifetime parameter
|
2 | struct S2<'a, F: Fn(&'a i32, &'a i32) -> &'a i32>(F);=
| ^^^ ^^^^^^^ ^^^^^^^ ^^^
```
Follow up to #68267. Addresses the diagnostics part of #49287.
Make more arithmetic functions unstably const
This is a smaller version of #66884 (thanks @9999years) that constifies many of the arithmetic functions on integer primitives from #53718 that were blocked on #49146.
This makes the following things unstably const.
- `feature = const_int_unchecked_arith`
- `intrinsics::unchecked_add`
- `intrinsics::unchecked_sub`
- `intrinsics::unchecked_mul`
- `intrinsics::unchecked_div`
- `intrinsics::unchecked_rem`
- `feature = const_checked_int_methods`
- `checked_add`
- `checked_sub`
- `checked_mul`
- `checked_div` (Uses `intrinsics::unchecked_div` internally)
- `checked_rem` (Uses `intrinsics::unchecked_rem` internally)
- `checked_neg`
- `checked_shl`
- `checked_shr`
- `checked_abs`
- `feature = const_saturating_int_methods`
- `saturating_mul`
- `saturating_neg` (Uses `intrinsics::unchecked_sub` internally)
- `saturating_abs` (Uses `intrinsics::unchecked_sub` internally)
- `feature = const_wrapping_int_methods`
- `wrapping_div`
- `wrapping_rem`
- `feature = const_overflowing_int_methods`
- `overflowing_div`
- `overflowing_rem`
- `feature = const_euclidean_int_methods`
- `checked_div_euclid`
- `checked_rem_euclid`
- `wrapping_div_euclid`
- `wrapping_rem_euclid`
- `overflowing_div_euclid`
- `overflowing_rem_euclid`
Exponentiation and operations on the `NonZero` types are left to a later PR.
r? @oli-obk
cc @rust-lang/wg-const-eval @rust-lang/libs
Remove the `overlapping_marker_traits` feature
See #29864
This has been replaced by `#[feature(marker_trait_attr)]`
A few notes:
* Due to PR #68057 not yet being in the bootstrap compiler, it's
necessary to continue using `#![feature(overlapping_marker_traits)]`
under `#[cfg(bootstrap)]` to work around type inference issues.
* I've updated tests that used `overlapping_marker_traits` to now use
`marker_trait_attr` where applicable
The test `src/test/ui/overlap-marker-trait.rs` doesn't make any sense
now that `overlapping_marker_traits`, so I removed it.
The test `src/test/ui/traits/overlap-permitted-for-marker-traits-neg.rs`
now fails, since it's no longer possible to have multiple overlapping
negative impls of `Send`. I believe that this is the behavior we want
(assuming that `Send` is not going to become a `#[marker]` trait, so I
renamed the test to `overlap-permitted-for-marker-traits-neg`
