| Age | Commit message (Collapse) | Author | Lines |
|
compare-mode=nll.
|
|
with clean stderr again.
Most were added mechanically.
|
|
Fix #54047
|
|
`impl trait` in bindings (feature: impl-trait-existential-types)
This PR enables `impl Trait` syntax (opaque types) to be used in bindings, e.g.
* `let foo: impl Clone = 1;`
* `static foo: impl Clone = 2;`
* `const foo: impl Clone = 3;`
This is part of [RFC 2071](https://github.com/rust-lang/rfcs/blob/master/text/2071-impl-trait-existential-types.md) ([tracking issue](https://github.com/rust-lang/rust/issues/34511)), but exists behind the separate feature gate `impl_trait_in_bindings`.
CC @cramertj @oli-obk @eddyb @Centril @varkor
|
|
Support an explicit annotation for marker traits
From the tracking issue for rust-lang/rfcs#1268:
> It seems obvious that we should make a `#[marker]` annotation. ~ https://github.com/rust-lang/rust/issues/29864#issuecomment-368959441
This PR allows you to put `#[marker]` on a trait, at which point:
- [x] The trait must not have any items ~~All of the trait's items must have defaults~~
- [x] Any impl of the trait must be empty (not override any items)
- [x] But impls of the trait are allowed to overlap
r? @nikomatsakis
|
|
|
|
Remove spawning from task::Context
r? @aturon
cc https://github.com/rust-lang-nursery/wg-net/issues/56
|
|
|
|
|
|
|
|
|
|
|
|
|
|
targets...
|
|
Fix #53764.
|
|
|
|
|
|
linker flag.
|
|
|
|
|
|
|
|
Update to a new pinning API.
~~Blocked on #53843 because of method resolution problems with new pin type.~~
@r? @cramertj
cc @RalfJung @pythonesque anyone interested in #49150
|
|
|
|
|
|
Allow named lifetimes in async functions.
- Fixes #53174
Code by @eddyb; @cramertj suggested I lift it off another change so we can fix #53174.
r? @cramertj
|
|
the same crate.
|
|
rustc_codegen_llvm: don't assume offsets are always aligned.
Fixes #53728 by taking into account not just overall type alignment and the field's alignment when determining whether a field is aligned or not ("packed"), but also the field's offset within the type.
Previously, rustc assumed that the offset was always at least as aligned as `min(struct.align, field.align)`. However, there's no real reason to have that assumption, and it obviously can't always be true after we implement `#[repr(align(N), pack(K))]`. There's also a case today where that assumption is not true, involving niche discriminants in enums:
Suppose that we have the code in #53728:
```Rust
#[repr(u16)]
enum DeviceKind {
Nil = 0,
}
#[repr(packed)]
struct DeviceInfo {
endianness: u8,
device_kind: DeviceKind,
}
struct Wrapper {
device_info: DeviceInfo,
data: u32
}
```
Observe the layout of `Option<Wrapper>`. It has an alignment of 4 because of the `u32`. `device_info.device_kind` is a good niche field to use, which means the enum ends up with this layout:
```
size = 8
align = 4
fields = [
{ offset=1, type=u16 } // discriminant, .<Some>.device_info.device_kind
]
```
And here we have an discriminant with alignment 2 (`u16`) but offset 1.
|
|
rustc_resolve: don't record uniform_paths canaries as reexports.
Fixes #53691, fixes #53484.
|
|
r=alexcrichton
migrate run-pass/*/ to ui/run-pass
I think this is all that remains of #53764
|
|
pnkfelix:issue-53764-migrate-run-pass-borrowck-to-ui, r=nikomatsakis
migrate run-pass/borrowck to ui/run-pass
Part of #53764
|
|
r=nikomatsakis
Migrate (some) of run-pass/ to ui
This is a step towards addressing #53764. Much still remains.
I went through a large portion of the `*.rs` files that were directly stored into `src/test/run-pass/` and moved them into various subdirectories of a newly created `src/test/ui/run-pass/`.
(yes, it would have perhaps been nice to meld it more directly with directories already in `src/test/ui/`; but the sad truth is that opens up the reality of filename collisions, and one of my short term goals for resolving #53764 is to keep the *filenames* invariant, even as their parents directories and contents are mildly revised...)
|
|
|
|
|
|
- Fixes #53174
|
|
|
|
`src/test/ui/run-pass/`.
|
|
|
|
Just shuffling files here; the needed updates to content come later.
|
|
|
|
|
|
fix `is_non_exhaustive` confusion between structs and enums
Structs and enums can both be non-exhaustive, with a very different
meaning. This PR splits `is_non_exhaustive` to 2 separate functions - 1
for structs, and another for enums, and fixes the places that got the
usage confused.
Fixes #53549.
r? @eddyb
|
|
Add more const int ops
r? @oli-obk
Tracking Issue: #53718
list of `const fn`s in this PR:
- `feature = const_int_rotate`
- `rotate_left`
- `rotate_right`
- `feature = const_int_wrapping`
- `wrapping_add`
- `wrapping_sub`
- `wrapping_mul`
- `wrapping_shl`
- `wrapping_shr`
- `feature = const_int_overflowing`
- `overflowing_add`
- `overflowing_sub`
- `overflowing_mul`
- `overflowing_shl`
- `overflowing_shr`
- `feature = const_int_sign`
- `is_positive`
- `is_negative`
- `feature = const_int_conversion`
- `reverse_bits`
- `to_le_bytes`
- `to_ne_bytes`
- `from_be_bytes`
- `from_le_bytes`
- `from_ne_bytes`
- `reverse_bits`
|
|
|
|
|
|
|
|
|
|
Implement the `min_const_fn` feature gate
cc @RalfJung @eddyb
r? @Centril
implements the feature gate for #53555
I added a hack so the `const_fn` feature gate also enables the `min_const_fn` feature gate. This ensures that nightly users of `const_fn` don't have to touch their code at all.
The `min_const_fn` checks are run first, and if they succeeded, the `const_fn` checks are run additionally to ensure we didn't miss anything.
|
|
fix u32 steps_between for 16-bit systems
This fixes #48006.
|
|
|
|
|