Rollup of 11 pull requests #54068
Closed
Rollup of 11 pull requests #54068
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
* When encountering EOF, point at the last opening brace that does not have the same indentation level as its close delimiter. * When encountering the wrong type of close delimiter, point at the likely correct open delimiter to give a better idea of what went wrong.
This is useful in debugging when and where errors are emitted in logs.
By introducing a new map that tracks the errors reported and the `Place`s that spawned those errors against the move out that the error was referring to, we are able to silence duplicate errors by emitting only the error which corresponds to the most specific `Place` (that which other `Place`s which reported errors are prefixes of). This generally is an improvement, however there is a case - `liveness-move-in-while` - where the output regresses.
I was dabbling recently seeing what it would take to compile `rustfmt` to the `wasm32-unknown-unknown` target and it turns out not much effort is needed! Currently `rustfmt` depends on a few rustc crates published to crates.io, so this commit touches up those crates to compile for wasm themselves. Notably: * The `rustc_data_structures` crate's `flock` implementation is stubbed out to unconditionally return errors on unsupported platforms. * The `rustc_errors` crate is extended to not do any locking for all non-windows platforms. In both of these cases if we port the compiler to new platforms the functionality isn't critical but will be discovered over time as it comes up, so this hopefully doesn't make it too too hard to compile to new platforms!
unless `#[rustc_promotable]` is added to the function
Limit the promotion of const fns to the libstd and the `rustc_promotable` attribute There are so many questions around promoting const fn calls... it seems saner to try to limit automatic promotion to const fns which were explicitly opted in for promotion. I added the attribute to all public stable const fns that were already promotable (e.g. not Cell::new) in order to not cause any breakage r? @eddyb cc @nikomatsakis
…akis Improve messages for un-closed delimiter errors
Fix incorrect outer function type parameter message Fix rust-lang#51303.
rustc_resolve: only prepend CrateRoot to a non-keyword segment. Fixes rust-lang#53770 by treating `use` paths as absolute in a finer-grained manner, specifically: ```rust use {a, crate::b, self::c, super::d}; ``` Used to be interpreted as if it were (when `uniform_paths` is not enabled): ```rust use ::{a, crate::b, self::c, super::d}; ``` With this PR, the `CrateRoot` pseudo-keyword indicating an absolute path is only inserted when the first path segment is found (if it's not a keyword), i.e. the example behaves like: ```rust use {::a, crate::b, self::c, super::d}; ``` This should (finally) make `use {path};` fully equivalent to `use path;`. r? @petrochenkov cc @cramertj @joshtriplett @nikomatsakis
Too many errors for incorrect move in loop with NLL enabled Fixes rust-lang#53807. r? @nikomatsakis
rustc_codegen_llvm: don't assume offsets are always aligned. Fixes rust-lang#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 rust-lang#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.
Allow named lifetimes in async functions. - Fixes rust-lang#53174 Code by @eddyb; @cramertj suggested I lift it off another change so we can fix rust-lang#53174. r? @cramertj
…rochenkov rustc_resolve: inject `uniform_paths` canary always on Rust 2018. **NOTE**: this PR is based on rust-lang#53988, only the second commit is new. This PR is an attempt at future-proofing "anchored paths" by emitting the same ambiguity errors that `#![feature(uniform_paths)]` would, with slightly changed phrasing (see added UI tests). r? @petrochenkov cc @aturon @Centril @joshtriplett
…rochenkov Fix compiling some rustc crates to wasm I was dabbling recently seeing what it would take to compile `rustfmt` to the `wasm32-unknown-unknown` target and it turns out not much effort is needed! Currently `rustfmt` depends on a few rustc crates published to crates.io, so this commit touches up those crates to compile for wasm themselves. Notably: * The `rustc_data_structures` crate's `flock` implementation is stubbed out to unconditionally return errors on unsupported platforms. * The `rustc_errors` crate is extended to not do any locking for all non-windows platforms. In both of these cases if we port the compiler to new platforms the functionality isn't critical but will be discovered over time as it comes up, so this hopefully doesn't make it too too hard to compile to new platforms!
…-clippy, r=alexcrichton Stabilize edition 2018; also updates Clippy and RLS Supersedes rust-lang#53999 Clippy build was failing there because crate_visibility_modifier feature was taken out of edition 2018 and clippy used it. The clippy update enables the corresponding feature explicitly. r? @Mark-Simulacrum
`&CStr`, not `CStr`, is the counterpart of `&str`
|
@bors r+ p=10 |
|
📌 Commit b93b944 has been approved by |
bors
added
the
S-waiting-on-bors
|
⌛ Testing commit b93b944 with merge 42b242ac1f0fb71a8a71d760ca93559cc37493e7... |
|
💔 Test failed - status-appveyor |
bors
added
S-waiting-on-review
|
☔ The latest upstream changes (presumably #53988) made this pull request unmergeable. Please resolve the merge conflicts. |
|
Unstable NLL error order, legit. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Successful merges:
rustc_promotableattribute #53851 (Limit the promotion of const fns to the libstd and therustc_promotableattribute)uniform_pathscanaries regardless of the feature-gate, on Rust 2018. #54011 (rustc_resolve: injectuniform_pathscanary always on Rust 2018.)&CStr, notCStr, is the counterpart of&str#54064 (&CStr, notCStr, is the counterpart of&str)Failed merges:
r? @ghost