-
Notifications
You must be signed in to change notification settings - Fork 13.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Rollup of 7 pull requests #137236
Closed
Closed
Rollup of 7 pull requests #137236
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
Const-stabilizes `slice::as_flattened{,_mut}`: ```rust // core::slice impl<T, const N: usize> [[T; N]] { pub const fn as_flattened(&self) -> &[T]; pub const fn as_flattened_mut(&mut self) -> &mut [T]; } ``` Tracking issue: rust-lang#95629 Requires separate libs-api FCP, as per rust-lang#95629 (comment). Closes rust-lang#95629.
When `Foo.field` or `Foo.method()` exprs are encountered, suggest `Foo::field` or `Foo::method()` when Foo is a type alias, not just a struct, trait, or module. Also rename test for this suggestion from issue-22692.rs to something more meaningful.
Suggest replacing `.` with `::` when encountering "expected value, found enum": - in a method-call expression and the method has the same name as a tuple variant - in a field-access expression and the field has the same name as a unit or tuple variant
…cro giving a type, make it also work when the rhs is a type alias, not just a struct.
…l` field in `LayoutData`. Also update comments that refered to BackendRepr::Uninhabited.
…PassMode::Ignore.
…turn ABI as wrapped type.
Add codegen test for uninhabited PassMode::Indirect return types.
* Order IDEs alphabetically so that manually searching for an IDE is easier, both when running `./x setup` and when editing the source code behind `./x setup` * Prepare for IDEs with spaces in their names * Allow explicitly typing 'none' for the IDE * Change capitalization of `Vscode` to the more standard `VsCode` * Make minor efficiency improvements * Add `'static` annotations where they apply
* Order items as the average of the two adaptors. Enables easier diffs. * Consistently apply #[inline]. * Implement FromInner<Vec<u8>> for bytes::Buf. * Implement Clone::clone_from for wtf8::Buf.
Co-authored-by: Jubilee <workingjubilee@gmail.com>
This was removed in rust-lang#114723
This was changed in rust-lang#132027
Added project-specific Zed IDE settings This repository currently has project-specific VS Code IDE settings in `.vscode` and `compiler/rustc_codegen_cranelift/.vscode`. Now there are equivalent project-specific Zed IDE settings alongside those. This fixes `rust-analyzer` not being able to properly handle this project. Note that: 1. The contents of `src/tools/rust-analyzer/.vscode` could not be translated to Zed, as they aren't basic IDE settings. 2. One of the VS Code settings in `.vscode` has no corresponding setting in Zed, and so this has been noted like this: ```json "_settings_only_in_vs_code_not_yet_in_zed": { "git.detectSubmodulesLimit": 20 }, ```
…nieu Impl TryFrom<Vec<u8>> for String I think this is useful enough to have :) As a general question, is there any policy around adding "missing" trait implementations? (like adding `AsRef<T> for T` for std types), I mostly stumble upon them when using a lot of "impl Trait in argument position" like (`foo: impl Into<String>`)
…en, r=Amanieu Stabilize const_slice_flatten Const-stabilizes `slice::as_flattened{,_mut}`: ```rust // core::slice impl<T, const N: usize> [[T; N]] { pub const fn as_flattened(&self) -> &[T]; pub const fn as_flattened_mut(&mut self) -> &mut [T]; } ``` Tracking issue: rust-lang#95629 Requires separate FCP, as per rust-lang#95629 (comment). Closes rust-lang#95629. ```@rustbot``` modify labels: +T-libs-api Happy new year!
…_3, r=davidtwco Suggest replacing `.` with `::` in more error diagnostics. First commit makes the existing "help: use the path separator to refer to an item" also work when the base is a type alias, not just a trait/module/struct. The existing unconditional `DefKind::Mod | DefKind::Trait` match arm is changed to a conditional `DefKind::Mod | DefKind::Trait | DefKind::TyAlias` arm that only matches if the `path_sep` suggestion-adding closure succeeds, so as not to stop the later `DefKind::TyAlias`-specific suggestions if the path-sep suggestion does not apply. This shouldn't change behavior for `Mod` or `Trait` (due to the default arm's `return false` etc). This commit also updates `tests/ui/resolve/issue-22692.rs` to reflect this, and also renames it to something more meaningful. This commit also makes the `bad_struct_syntax_suggestion` closure take `err` as a parameter instead of capturing it, since otherwise caused borrowing errors due to the change to using `path_sep` in a pattern guard. <details> <summary> Type alias diagnostic example </summary> ```rust type S = String; fn main() { let _ = S.new; } ``` ```diff error[E0423]: expected value, found type alias `S` --> diag7.rs:4:13 | 4 | let _ = S.new; | ^ | - = note: can't use a type alias as a constructor + help: use the path separator to refer to an item + | +4 | let _ = S::new; + | ~~ ``` </details> Second commit adds some cases for `enum`s, where if there is a field/method expression where the field/method has the name of a unit/tuple variant, we assume the user intended to create that variant[^1] and suggest replacing the `.` from the field/method suggestion with a `::` path separator. If no such variant is found (or if the error is not a field/method expression), we give the existing suggestion that suggests adding `::TupleVariant(/* fields */)` after the enum. <details> <summary> Enum diagnostic example </summary> ```rust enum Foo { A(u32), B, C { x: u32 }, } fn main() { let _ = Foo.A(42); // changed let _ = Foo.B; // changed let _ = Foo.D(42); // no change let _ = Foo.D; // no change let _ = Foo(42); // no change } ``` ```diff error[E0423]: expected value, found enum `Foo` --> diag8.rs:8:13 | 8 | let _ = Foo.A(42); // changed | ^^^ | note: the enum is defined here --> diag8.rs:1:1 | 1 | / enum Foo { 2 | | A(u32), 3 | | B, 4 | | C { x: u32 }, 5 | | } | |_^ -help: you might have meant to use the following enum variant - | -8 | let _ = Foo::B.A(42); // changed - | ~~~~~~ -help: alternatively, the following enum variant is available +help: use the path separator to refer to a variant | -8 | let _ = (Foo::A(/* fields */)).A(42); // changed - | ~~~~~~~~~~~~~~~~~~~~~~ +8 | let _ = Foo::A(42); // changed + | ~~ error[E0423]: expected value, found enum `Foo` --> diag8.rs:9:13 | 9 | let _ = Foo.B; // changed | ^^^ | note: the enum is defined here --> diag8.rs:1:1 | 1 | / enum Foo { 2 | | A(u32), 3 | | B, 4 | | C { x: u32 }, 5 | | } | |_^ -help: you might have meant to use the following enum variant - | -9 | let _ = Foo::B.B; // changed - | ~~~~~~ -help: alternatively, the following enum variant is available +help: use the path separator to refer to a variant | -9 | let _ = (Foo::A(/* fields */)).B; // changed - | ~~~~~~~~~~~~~~~~~~~~~~ +9 | let _ = Foo::B; // changed + | ~~ error[E0423]: expected value, found enum `Foo` --> diag8.rs:10:13 | 10 | let _ = Foo.D(42); // no change | ^^^ | note: the enum is defined here --> diag8.rs:1:1 | 1 | / enum Foo { 2 | | A(u32), 3 | | B, 4 | | C { x: u32 }, 5 | | } | |_^ help: you might have meant to use the following enum variant | 10 | let _ = Foo::B.D(42); // no change | ~~~~~~ help: alternatively, the following enum variant is available | 10 | let _ = (Foo::A(/* fields */)).D(42); // no change | ~~~~~~~~~~~~~~~~~~~~~~ error[E0423]: expected value, found enum `Foo` --> diag8.rs:11:13 | 11 | let _ = Foo.D; // no change | ^^^ | note: the enum is defined here --> diag8.rs:1:1 | 1 | / enum Foo { 2 | | A(u32), 3 | | B, 4 | | C { x: u32 }, 5 | | } | |_^ help: you might have meant to use the following enum variant | 11 | let _ = Foo::B.D; // no change | ~~~~~~ help: alternatively, the following enum variant is available | 11 | let _ = (Foo::A(/* fields */)).D; // no change | ~~~~~~~~~~~~~~~~~~~~~~ error[E0423]: expected function, tuple struct or tuple variant, found enum `Foo` --> diag8.rs:12:13 | 12 | let _ = Foo(42); // no change | ^^^ help: try to construct one of the enum's variants: `Foo::A` | = help: you might have meant to construct the enum's non-tuple variant note: the enum is defined here --> diag8.rs:1:1 | 1 | / enum Foo { 2 | | A(u32), 3 | | B, 4 | | C { x: u32 }, 5 | | } | |_^ error: aborting due to 5 previous errors ``` </details> [^1]: or if it's a field expression and a tuple variant, that they meant to refer the variant constructor.
…bited, r=workingjubilee Do not ignore uninhabited types for function-call ABI purposes. (Remove BackendRepr::Uninhabited) Accepted MCP: rust-lang/compiler-team#832 Fixes rust-lang#135802 Do not consider the inhabitedness of a type for function call ABI purposes. * Remove the [`rustc_abi::BackendRepr::Uninhabited`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_abi/enum.BackendRepr.html) variant * Instead calculate the `BackendRepr` of uninhabited types "normally" (as though they were not uninhabited "at the top level", but still considering inhabitedness of variants to determine enum layout, etc) * Add an `uninhabited: bool` field to [`rustc_abi::LayoutData`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_abi/struct.LayoutData.html) so inhabitedness of a `LayoutData` can still be queried when necessary (e.g. when determining if an enum variant needs a tag value allocated to it). This should not affect type layouts (size/align/field offset); this should only affect function call ABI, and only of uninhabited types. cc `@RalfJung`
…Denton Organize `OsString`/`OsStr` shims Synchronize the `bytes.rs` and `wtf8.rs` shims for `OsString`/`OsStr` so they're easier to diff between each other. This is mostly ordering items the same between the two. I tried to minimize moves and went for the average locations between the files. With them in the same order, it is clear that `FromInner<_>` is not implemented for `bytes::Buf` and `Clone::clone_from` is not implemented for `wtf8::Buf`, but they are for the other. Fix that. I added #[inline] to all inherent methods of the `OsString`/`OsStr` shims, because it seemed that was already the rough pattern. `bytes.rs` has more inlining than `wtf8.rs`, so I added the corresponding ones to `wtf8.rs`. Then, the common missing ones have no discernible pattern to me. They're not divided by non-allocating/allocating. Perhaps the pattern is that UTF-8 validation isn't inlined? Since these types are merely the inner values in `OsStr`/`OsString`, I put inline on all methods and let those public types dictate inlining. I have not inspected codegen or run benchmarks. Also, touch up some (private) documentation comments. r? ```@ChrisDenton```
…er-errors docs(dev): Update the feature-gate instructions `features_untracked` was removed in rust-lang#114723 features are now functions as of rust-lang#132027
@bors r+ rollup=never p=5 |
The job Click to see the possible cause of the failure (guessed by this bot)
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
A-rustc-dev-guide
Area: rustc-dev-guide
A-tidy
Area: The tidy tool
rollup
A PR which is a rollup
S-waiting-on-author
Status: This is awaiting some action (such as code changes or more information) from the author.
T-bootstrap
Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap)
T-compiler
Relevant to the compiler team, which will review and decide on the PR/issue.
T-libs
Relevant to the library team, which will review and decide on the PR/issue.
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:
.
with::
in more error diagnostics. #136344 (Suggest replacing.
with::
in more error diagnostics.)OsString
/OsStr
shims #137155 (OrganizeOsString
/OsStr
shims)r? @ghost
@rustbot modify labels: rollup
Create a similar rollup