| Age | Commit message (Collapse) | Author | Lines |
|---|
|
[beta] back out #53793 - stabilize outlives requirements
Fixes #54467 for beta, looks like a less risky fix than #54701
|
|
|
|
|
|
|
|
This will be re-enabled sooner or later depending on results of further
investigation.
Fixes #54462
|
|
|
|
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.
|
|
|
|
|
|
Replace usages of 'bad_style' with 'nonstandard_style'.
`bad_style` is being deprecated in favor of `nonstandard_style`:
- https://github.com/rust-lang/rust/issues/41646
|
|
Add partialeq implementation for TryFromIntError type
Fixes #53458.
|
|
|
|
|
|
`bad_style` is being deprecated in favor of `nonstandard_style`:
- https://github.com/rust-lang/rust/issues/41646
|
|
Miri engine cleanup
* Unify the two maps in memory to store the allocation and its kind together.
* Share the handling of statics between CTFE and miri: The miri engine always
uses "lazy" `AllocType::Static` when encountering a static. Acessing that
static invokes CTFE (no matter the machine). The machine only has any
influence when writing to a static, which CTFE outright rejects (but miri
makes a copy-on-write).
* Add an `AllocId` to by-ref consts so miri can use them as operands without
making copies.
* Move responsibilities around for the `eval_fn_call` machine hook: The hook
just has to find the MIR (or entirely take care of everything); pushing the
new stack frame is taken care of by the miri engine.
* Expose the intrinsics and lang items implemented by CTFE so miri does not
have to reimplement them.
* Allow Machine to hook into foreign statics (used by miri to get rid of some other hacks).
* Clean up function calling.
* Switch const sanity check to work on operands, not mplaces.
* Move const_eval out of rustc_mir::interpret, to make sure that it does not access private implementation details.
In particular, we can finally make `eval_operand` take `&self`. :-)
Should be merged after https://github.com/rust-lang/rust/pull/53609, across which I will rebase.
|
|
|
|
unary '-' overflowing
|
|
move the Pin API into its own module for centralized documentation
This implements the change proposed by @withoutboats in #49150, as suggested by @RalfJung in the review of #53104,
along with the documentation that was originally in it, that was deemed more appropriate in module-level documentation.
r? @RalfJung
|
|
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.
|
|
Also update Cargo's dependencies while we're at it
|
|
Rollup of 16 pull requests
Successful merges:
- #53311 (Window Mutex: Document that we properly initialize the SRWLock)
- #53503 (Discourage overuse of mem::forget)
- #53545 (Fix #50865: ICE on impl-trait returning functions reaching private items)
- #53559 (add macro check for lint)
- #53562 (Lament the invincibility of the Turbofish)
- #53563 (use String::new() instead of String::from(""), "".to_string(), "".to_owned() or "".into())
- #53592 (docs: minor stylistic changes to str/string docs)
- #53594 (Update RELEASES.md to include clippy-preview)
- #53600 (Fix a grammatical mistake in "expected generic arguments" errors)
- #53614 (update nomicon and book)
- #53617 (tidy: Stop requiring a license header)
- #53618 (Add missing fmt examples)
- #53636 (Prefer `.nth(n)` over `.skip(n).next()`.)
- #53644 (Use SmallVec for SmallCStr)
- #53664 (Remove unnecessary closure in rustc_mir/build/mod.rs)
- #53666 (Added rustc_codegen_llvm to compiler documentation.)
|
|
Fix #50865: ICE on impl-trait returning functions reaching private items
Adds a test case as suggested in #50865, and implements @petrochenkov's suggestion. Fixes #50865.
Impl-trait-returning functions are marked under a new (low) access level, which they propagate rather than `AccessLevels::Reachable`. `AccessLevels::is_reachable` returns false for such items (leaving stability analysis unaffected), these items may still be visible to the lints phase however.
|
|
Prefer `.nth(n)` over `.skip(n).next()`.
Found by clippy.
|
|
|
|
Found by clippy.
|
|
Implement try block expressions
I noticed that `try` wasn't a keyword yet in Rust 2018, so...
~~Fixes https://github.com/rust-lang/rust/issues/52604~~ That was fixed by PR https://github.com/rust-lang/rust/pull/53135
cc https://github.com/rust-lang/rust/issues/31436 https://github.com/rust-lang/rust/issues/50412
|
|
|
