| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
|
|
|
|
This copies and adjusts the existing coherence tests to ensure that
they continue to work using the new implementation.
|
|
|
|
This is the pattern we no longer accept.
|
|
|
|
|
|
|
|
This allows to verify that we handle
different types as return types,
and that we call the expected functions.
|
|
|
|
Those tests are directly taken from the comments on the bug reports.
|
|
This commit adds support for respecting user type annotations with
associated constants in patterns.
|
|
Implement RFC 2338, "Type alias enum variants"
This PR implements [RFC 2338](https://github.com/rust-lang/rfcs/pull/2338), allowing one to write code like the following.
```rust
#![feature(type_alias_enum_variants)]
enum Foo {
Bar(i32),
Baz { i: i32 },
}
type Alias = Foo;
fn main() {
let t = Alias::Bar(0);
let t = Alias::Baz { i: 0 };
match t {
Alias::Bar(_i) => {}
Alias::Baz { i: _i } => {}
}
}
```
Since `Self` can be considered a type alias in this context, it also enables using `Self::Variant` as both a constructor and pattern.
Fixes issues #56199 and #56611.
N.B., after discussing the syntax for type arguments on enum variants with @petrochenkov and @eddyb (there are also a few comments on the [tracking issue](https://github.com/rust-lang/rust/issues/49683)), the consensus seems to be treat the syntax as follows, which ought to be backwards-compatible.
```rust
Option::<u8>::None; // OK
Option::None::<u8>; // OK, but lint in near future (hard error next edition?)
Alias::<u8>::None; // OK
Alias::None::<u8>; // Error
```
I do not know if this will need an FCP, but let's start one if so.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
address some FIXME whose associated issues were marked as closed
part of #44366
|
|
Pin stabilization
This implements the changes suggested in https://github.com/rust-lang/rust/issues/55766#issue-378417538 and stabilizes the `pin` feature. @alexcrichton also listed several "blockers" in that issue, but then in [this comment](https://github.com/rust-lang/rust/issues/55766#issuecomment-445074980) mentioned that they're more "TODO items":
> In that vein I think it's fine for a stabilization PR to be posted at any time now with FCP lapsed for a week or so now. The final points about self/pin/pinned can be briefly discussed there (if even necessary, they could be left as the proposal above).
Let's settle these last bits here and get this thing stabilized! :)
r? @alexcrichton
cc @withoutboats
|
|
Rollup of 25 pull requests
Successful merges:
- #56802 (Add DoubleEndedIterator::nth_back)
- #56909 (static eval: Do not ICE on layout size overflow)
- #56914 (Ignore ui/target-feature-gate on sparc, sparc64, powerpc, powerpc64 and powerpc64le)
- #56919 (Remove a wrong multiplier on relocation offset computation)
- #56933 (Add --progress to git submodule commands in x.py)
- #56936 (rename div_euc -> div_euclid, and mod_euc -> rem_euclid)
- #56941 (deny intra-doc link resolution failures in libstd)
- #56945 (Fix rustdoc-js tests)
- #56967 (Replace current crate's searchIndex when regenerating)
- #56970 (Mem uninit doc ptr drop)
- #56973 (make basic CTFE tracing available on release builds)
- #56979 (Adding unwinding support for x86_64_fortanix_unknown_sgx target.)
- #56981 (miri: allocation is infallible)
- #56984 (A few tweaks to dropck_outlives)
- #56989 (Fix compiletest `trim` deprecation warnings)
- #56992 (suggest similar lint names for unknown lints)
- #57002 (Stabilize Vec(Deque)::resize_with)
- #57011 (rustdoc: add new CLI flag to load static files from a different location)
- #57027 (Optimize away a move)
- #57034 (Inline tweaks)
- #57039 (Update migrate warning wording.)
- #57040 (Fix feature gate to point to 1.32.0 for `path_from_str`)
- #57049 (Stabilize #[repr(packed(N))])
- #57050 (Fixed typo in HashMap documentation)
- #57052 (Fix stabilization version numbers (exhaustive_integer_patterns + macro_literal_matcher))
|
|
Disable field reordering for repr(int).
This fixes the problem that the test in #56619 uncovers.
Closes #56619.
|
|
Stabilize #[repr(packed(N))]
Fixes https://github.com/rust-lang/rust/issues/33158
|
|
|
|
|
|
Stabilize `Rc`, `Arc` and `Pin` as method receivers
Replaces #55880
Closes #55786
r? @nikomatsakis
cc @withoutboats @cramertj
This lets you write methods using `self: Rc<Self>`, `self: Arc<Self>`, `self: Pin<&mut Self>`, `self: Pin<Box<Self>`, and other combinations involving `Pin` and another stdlib receiver type, without needing the `arbitrary_self_types`. Other user-created receiver types can be used, but they still require the feature flag to use.
This is implemented by introducing a new trait, `Receiver`, which the method receiver's type must implement if the `arbitrary_self_types` feature is not enabled. To keep composed receiver types such as `&Arc<Self>` unstable, the receiver type is also required to implement `Deref<Target=Self>` when the feature flag is not enabled.
This lets you use `self: Rc<Self>` and `self: Arc<Self>` in stable Rust, which was not allowed previously. It was agreed that they would be stabilized in #55786. `self: Pin<&Self>` and other pinned receiver types do not require the `arbitrary_self_types` feature, but they cannot be used on stable because `Pin` still requires the `pin` feature.
|
|
|
|
r=nikomatsakis
Less conservative uninhabitedness check
Extends the uninhabitedness check to structs, non-empty enums, tuples and arrays.
Pulled out of #47291 and #50262.
Fixes https://github.com/rust-lang/rust/issues/54586.
r? @nikomatsakis
|
|
This lets you write methods using `self: Rc<Self>`, `self: Arc<Self>`, `self: Pin<&mut Self>`, `self: Pin<Box<Self>`, and other combinations involving `Pin` and another stdlib receiver type, without needing the `arbitrary_self_types`. Other user-created receiver types can be used, but they still require the feature flag to use.
This is implemented by introducing a new trait, `Receiver`, which the method receiver's type must implement if the `arbitrary_self_types` feature is not enabled. To keep composed receiver types such as `&Arc<Self>` unstable, the receiver type is also required to implement `Deref<Target=Self>` when the feature flag is not enabled.
This lets you use `self: Rc<Self>` and `self: Arc<Self>` in stable Rust, which was not allowed previously. It was agreed that they would be stabilized in #55786. `self: Pin<&Self>` and other pinned receiver types do not require the `arbitrary_self_types` feature, but they cannot be used on stable because `Pin` still requires the `pin` feature.
|
|
process nested obligations in autoderef
Fixes #53843.
r? @nikomatsakis
|
|
pnkfelix:issue-54153-linkage-sometimes-requires-optimizations, r=nikic
fix issue 54153 by not testing issue-18804 on Windows nor OS X.
Fix #54153
|
|
|
|
hr_lifetime_in_assoc_type warning
|
|
i.e. `Box`, instead it now uses `Vec`
|
|
|
|
Fix various aspects around `let` bindings inside const functions
* forbid `let` bindings in const contexts that use short circuiting operators
* harden analysis code against derefs of mutable references
Initially this PR was about stabilizing `let` bindings, but too many flaws were exposed that need some more testing on nightly
|
|
add coherence future-compat warnings for marker-only trait objects
The future-compat warnings break code that assumes that `dyn Send + Sync !=
dyn Sync + Send`, and are the first step in making them equal. cc #33140.
Note: this lint should be made to default-warn before we merge. It is deny only for the crater run.
r? @nikomatsakis / @scalexm . cc @Centril & @alexreg.
|
|
Improve MIR match generation for ranges
Improves MIR match generation to rule out ranges/values distinct from the range that has been tested. e.g., for this code:
```rust
match x {
0..=5 if b => 0,
6..=10 => 1,
_ => 2,
}
```
MIR (before):
```rust
bb0: { ...; _4 = Le(const 0i32, _1); switchInt(move _4) -> [false: bb6, otherwise: bb5]; }
bb1: { _3 = const 0i32; goto -> bb8; }
bb2: { _6 = _2; switchInt(move _6) -> [false: bb6, otherwise: bb1]; } // If `!b`, jumps to test if `6 <= x <= 10`.
bb3: { _3 = const 1i32; goto -> bb8; }
bb4: { _3 = const 2i32; goto -> bb8; }
bb5: { _5 = Le(_1, const 5i32); switchInt(move _5) -> [false: bb6, otherwise: bb2]; }
bb6: { _7 = Le(const 6i32, _1); switchInt(move _7) -> [false: bb4, otherwise: bb7]; }
bb7: { _8 = Le(_1, const 10i32); switchInt(move _8) -> [false: bb4, otherwise: bb3]; }
```
MIR (after):
```rust
bb0: { ...; _4 = Le(const 0i32, _1); switchInt(move _4) -> [false: bb5, otherwise: bb6]; }
bb1: { _3 = const 0i32; goto -> bb8; }
bb2: { _6 = _2; switchInt(move _6) -> [false: bb4, otherwise: bb1]; } // If `!b`, jumps to `_ =>` arm.
bb3: { _3 = const 1i32; goto -> bb8; }
bb4: { _3 = const 2i32; goto -> bb8; }
bb5: { _7 = Le(const 6i32, _1); switchInt(move _7) -> [false: bb4, otherwise: bb7]; }
bb6: { _5 = Le(_1, const 5i32); switchInt(move _5) -> [false: bb5, otherwise: bb2]; }
bb7: { _8 = Le(_1, const 10i32); switchInt(move _8) -> [false: bb4, otherwise: bb3]; }
```
cc #29623
|
|
|
|
Bump minimum required LLVM version to 6.0
Based on the discussion in #55842, while the overall position of Rust wrt LLVM continues to be contentious, there does seem to be a consensus that there is no need for continued support of LLVM 5. This PR bumps our version requirement to LLVM 6.0 and makes Travis run against that.
I hope that this is going to unblock #52694. If I understand correctly, while this issue still exists in LLVM 6, Ubuntu has backported the relevant patch.
r? @alexcrichton
|
|
RFC #2195 specifies that a repr(int) enum such as:
#[repr(u8)]
enum MyEnum {
B { x: u8, y: i16, z: u8 },
}
has a layout that is equivalent to:
#[repr(C)]
enum MyEnumVariantB { tag: u8, x: u8, y: i16, z: u8 },
However this isn't actually implemented, with the actual layout being
roughly equivalent to:
union MyEnumPayload {
B { x: u8, y: i16, z: u8 },
}
#[repr(packed)]
struct MyEnum {
tag: u8,
payload: MyEnumPayload,
}
Thus the variant payload is *not* subject to repr(C) ordering rules, and
gets re-ordered as `{ x: u8, z: u8, z: i16 }`
The existing tests added in pull-req #45688 fail to catch this as the
repr(C) ordering just happens to match the current Rust ordering in this
case; adding a third field reveals the problem.
|
|
Don't depend on `Allocation` sizes for pattern length
And generally be more explicit about shortcomings of the implementation
cc @RalfJung
|
|
Makes testing a range rule out ranges/constant
covered by the range that is being tested
|
|
The future-compat warnings break code that assumes that `dyn Send + Sync !=
dyn Sync + Send`, and are the first step in making them equal. cc #33140.
It should be possible to revert this commit when we're done with the
warnings.
|
|
This is a hack-fix to #53843, but I am worried it might break things
because it makes the "inference pollution" problem worse.
Fixes #53843 (but introduces a bug that someone might notice).
|
|
rustc: Add an unstable `simd_select_bitmask` intrinsic
This is going to be required for binding a number of AVX-512 intrinsics
in the `stdsimd` repository, and this intrinsic is the same as
`simd_select` except that it takes a bitmask as the first argument
instead of a SIMD vector. This bitmask is then transmuted into a `<NN x
i8>` argument, depending on how many bits it is.
cc rust-lang-nursery/stdsimd#310
|
