[pull] master from rust-lang:master #1
Merged
Conversation
This file contains hidden or 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
![pull[bot]](https://avatars.githubusercontent.com/in/12910?s=80&v=4){kind=small}
Mark-Simulacrum
force-pushed
the
master
branch
from
47c0792 to
999ac5f
Compare
Pretty-print let-else with added parenthesization when needed
Rustc used to produce invalid syntax for the following code, which is problematic because it means we cannot apply rustfmt to the output of `-Zunpretty=expanded`.
```rust
macro_rules! expr {
($e:expr) => { $e };
}
fn main() {
let _ = expr!(loop {}) else { return; };
}
```
```console
$ rustc repro.rs -Zunpretty=expanded | rustfmt
error: `loop...else` loops are not supported
--> <stdin>:9:29
|
9 | fn main() { let _ = loop {} else { return; }; }
| ---- ^^^^^^^^^^^^^^^^
| |
| `else` is attached to this loop
|
= note: consider moving this `else` clause to a separate `if` statement and use a `bool` variable to control if it should run
```
The current way of stepping through each comment in `Comments` is a bit weird. There is a `Vec<Comments>` and a `current` index, which is fine. The `Comments::next` method clones the current comment but doesn't advance `current`; the advancing instead happens in `print_comment`, which is where each cloned comment is actually finally used (or not, in some cases, if the comment fails to satisfy a predicate). This commit makes things more iterator-like: - `Comments::next` now advances `current` instead of `print_comment`. - `Comments::peek` is added so you can inspect a comment and check a predicate without consuming it. - This requires splitting `PrintState::comments` into immutable and mutable versions. The commit also moves the ref inside the `Option` of the return type, to save callers from having to use `as_ref`/`as_mut`. - It also requires adding `PrintState::peek_comment` alongside the existing `PrintState::next_comment`. (The lifetimes in the signature of `peek_comment` ended up more complex than I expected.) We now have a neat separation between consuming (`next`) and non-consuming (`peek`) uses of each comment. As well as being clearer, this will facilitate the next commit that avoids unnecessary cloning.
…aethlin Remove `#[macro_use] extern crate rustc middle` from numerous crates Because explicit importing of macros via `use` items is nicer (more standard and readable) than implicit importing via `#[macro_use]`. This PR mops up some cases I didn't get to in #124511. r? `@saethlin`
This avoids the need for a clone, fixing a FIXME comment.
This span records the declaration of the metavariable in the LHS of the macro. It's used in a couple of error messages. Unfortunately, it gets in the way of the long-term goal of removing `TokenKind::Interpolated`. So this commit removes it, which degrades a couple of (obscure) error messages but makes things simpler and enables the next commit.
reorganised attrs removed OsStr impls added backticks
…for Arc<[T]>::default where alignof(T) <= 16.
Avoid clone in `Comments::next` `Comments::next`, in `rustc_ast_pretty`, has this comment: ``` // FIXME: This shouldn't probably clone lmao ``` The obvious thing to try is to return `Option<&Comment>` instead of `Option<Comment>`. But that leads to multiple borrows all over the place, because `Comments` must be borrowed from `PrintState` and then processed by `&mut self` methods within `PrintState`. This PR instead rearranges things so that comments are consumed as they are used, preserving the `Option<Comment>` return type without requiring any cloning. r? `@compiler-errors`
Modifying an environment variable would make the function unsafe to call.
Rewrite 3 very similar `run-make` alloc tests to rmake Part of #121876 #121918 attempted to port these 3 tests 2 months ago. However, since then, the structure of `run-make-support` has changed a bit and new helper functions were added. Since there has been no activity on the PR, they are good low-hanging fruit to knock down, using the new functions of the current library. There is also the removal of a useless import on a very similar test.
Signed-off-by: onur-ozkan <[email protected]>
Improve error message: missing `;` in macro_rules Fixes #124968
android: use posix_memalign for aligned allocations Our target page says > Rust will support the most recent Long Term Support (LTS) Android Native Development Kit (NDK). By default Rust will support all API levels supported by the NDK, but a higher minimum API level may be required if deemed necessary. According to [this](https://github.com/android/ndk/wiki/Changelog-r26), the minimum API level of the current LTS NDK is 21. According to [this](https://stackoverflow.com/questions/44852378/android-ndk-r15b-posix-memalign-undeclared-identifier), posix_memalign exists since API level 16. So I think we should be able to use it here?
Improve parser Fixes #124935. - Add a few more help diagnostics to incorrect semicolons - Overall improved that function - Addded a few comments - Renamed diff_marker fns to git_diff_marker
Temporarily revert to NonZeroUsize in rustc-abi to fix building on stable rust-analyzer uses an auto-published version of `rustc-abi`, but `NonZero` isn't yet stable. This prevents us from updating the RA subtree, which is quite old already. I can file a revert PR after the release.
…les-invalid-expr, r=jieyouxu Migrate `run-make/rustdoc-scrape-examples-invalid-expr` to `rmake.rs` Part of #121876. r? `@jieyouxu`
Rollup of 4 pull requests Successful merges: - #125117 (Improve parser) - #125184 (Fix ICE in non-operand `aggregate_raw_ptr` intrinsic codegen) - #125240 (Temporarily revert to NonZeroUsize in rustc-abi to fix building on stable) - #125248 (Migrate `run-make/rustdoc-scrape-examples-invalid-expr` to `rmake.rs`) r? `@ghost` `@rustbot` modify labels: rollup
Rename Unsafe to Safety Alternative to #124455, which is to just have one Safety enum to use everywhere, this opens the posibility of adding `ast::Safety::Safe` that's useful for unsafe extern blocks. This leaves us today with: ```rust enum ast::Safety { Unsafe(Span), Default, // Safe (going to be added for unsafe extern blocks) } enum hir::Safety { Unsafe, Safe, } ``` We would convert from `ast::Safety::Default` into the right Safety level according the context.
Only make GAT ambiguous in `match_projection_projections` considering shallow resolvability In #123537, I tweaked the hack from #93892 to use `resolve_vars_if_possible` instead of `shallow_resolve`. This considers more inference guidance ambiguous. This resulted in crater regressions in #125196. I've effectively reverted the change to the old behavior. That being said, I don't *like* this behavior, but I'd rather keep it for now since #123537 was not meant to make any behavioral changes. See the attached example. This also affects the new solver, for the record, which doesn't have any rules about not guiding inference from param-env candidates which may constrain GAT args as a side-effect. r? `@lcnr` or `@jackh726`
Add tests for `-Zunpretty=expanded` ported from stringify's tests This PR adds a new set of tests for the AST pretty-printer. Previously, pretty-printer edge cases were tested by way of `stringify!` in [tests/ui/macros/stringify.rs](https://github.com/rust-lang/rust/blob/1.78.0/tests/ui/macros/stringify.rs), such as the tests added by 419b269 and 527e2ea. Those tests will no longer provide effective coverage of the AST pretty-printer after #124141. `Nonterminal` and `TokenKind::Interpolated` are being removed, and a consequence is that `stringify!` will perform token stream pretty printing, instead of AST pretty printing, in all of the `stringify!` cases including $:expr and all other interpolations. This PR adds 2 new ui tests with `compile-flags: -Zunpretty=expanded`: - **tests/ui/unpretty/expanded-exhaustive.rs** — this test aims for exhaustive coverage of all the variants of `ExprKind`, `ItemKind`, `PatKind`, `StmtKind`, `TyKind`, and `VisibilityKind`. Some parts could use being fleshed out further, but the current state is roughly on par with what exists in the old stringify-based tests. - **tests/ui/unpretty/expanded-interpolation.rs** — this test covers tricky macro metavariable edge cases that require the AST pretty printer to synthesize parentheses in order for the printed code to be valid Rust syntax. r? `@nnethercote`
Clarify how String::leak and into_boxed_str differ
and make NestedGoals generic
I tried to rebase this down into the first commit but it is WAY too annoying x
Rollup of 3 pull requests Successful merges: - #125214 (Only make GAT ambiguous in `match_projection_projections` considering shallow resolvability) - #125236 (Add tests for `-Zunpretty=expanded` ported from stringify's tests) - #125251 (Clarify how String::leak and into_boxed_str differ ) r? `@ghost` `@rustbot` modify labels: rollup
Uplift more query stuff - Uplift various query input/response internals - Uplift the `ProofTree` structures and make the `ProofTreeBuilder` stuff (mostly) generic over `Interner` - Stop using `TyCtxt::def_kind` in favor of `AliasTerm::kind` r? lcnr
alloc: implement FromIterator for Box<str> `Box<[T]>` implements `FromIterator<T>` using `Vec<T>` + `into_boxed_slice()`. Add analogous `FromIterator` implementations for `Box<str>` matching the current implementations for `String`. Remove the `Global` allocator requirement for `FromIterator<Box<str>>` too. ACP: rust-lang/libs-team#196
…mulacrum lldb-formatters: Use StdSliceSyntheticProvider for &str &str has associated summary provider which correctly displays string values in debugger, but while working on #124458 I've noticed that a &str inside an enum displays a blob of memory until a 0 is reached (as a c-string) which makes a very bizarre experience when debugging However there is already StdSliceSyntheticProvider which we use for other slices. This PR enables the same synthetic provider to be used for &str, however the summary provider is still fixed to return the string value I've added a test `debuginfo/strings-and-strs.rs` which prior to this PR would output the following in LLDB: ``` * thread #1, name = 'a', stop reason = breakpoint 1.1 frame #0: 0x0000555555556383 a`strings_and_strs::main::h1d2b5f9227b8767d at strings-and-strs.rs:47:5 44 let plain_str = "Hello"; 45 let str_in_struct = Foo { inner: "Hello" }; 46 let str_in_tuple = ("Hello", "World"); -> 47 zzz(); // #break 48 } 49 50 fn zzz() { (lldb) frame var (alloc::string::String) plain_string = "Hello" { vec = size=5 { [0] = 'H' [1] = 'e' [2] = 'l' [3] = 'l' [4] = 'o' } } (&str) plain_str = "Hello" { data_ptr = 0x0000555555557263 "HelloWorld\U00000001gdb_load_rust_pretty_printers.py" length = 5 } (strings_and_strs::Foo) str_in_struct = { inner = "Hello" { data_ptr = 0x0000555555557263 "HelloWorld\U00000001gdb_load_rust_pretty_printers.py" length = 5 } } ((&str, &str)) str_in_tuple = { 0 = "Hello" { data_ptr = 0x0000555555557263 "HelloWorld\U00000001gdb_load_rust_pretty_printers.py" length = 5 } 1 = "World" { data_ptr = 0x0000555555557268 "World\U00000001gdb_load_rust_pretty_printers.py" length = 5 } } ``` After this PR it would look the following way: ``` * thread #1, name = 'a', stop reason = breakpoint 1.1 frame #0: 0x0000555555556383 a`strings_and_strs::main::h1d2b5f9227b8767d at strings-and-strs.rs:47:5 44 let plain_str = "Hello"; 45 let str_in_struct = Foo { inner: "Hello" }; 46 let str_in_tuple = ("Hello", "World"); -> 47 zzz(); // #break 48 } 49 50 fn zzz() { (lldb) frame var (alloc::string::String) plain_string = "Hello" { vec = size=5 { [0] = 'H' [1] = 'e' [2] = 'l' [3] = 'l' [4] = 'o' } } (&str) plain_str = "Hello" { [0] = 'H' [1] = 'e' [2] = 'l' [3] = 'l' [4] = 'o' } (strings_and_strs::Foo) str_in_struct = { inner = "Hello" { [0] = 'H' [1] = 'e' [2] = 'l' [3] = 'l' [4] = 'o' } } ((&str, &str)) str_in_tuple = { 0 = "Hello" { [0] = 'H' [1] = 'e' [2] = 'l' [3] = 'l' [4] = 'o' } 1 = "World" { [0] = 'W' [1] = 'o' [2] = 'r' [3] = 'l' [4] = 'd' } } ```
Fix #124275: Implemented Default for `Arc<str>` With added implementations. ``` GOOD Arc<CStr> BROKEN Arc<OsStr> // removed GOOD Rc<str> GOOD Rc<CStr> BROKEN Rc<OsStr> // removed GOOD Rc<[T]> GOOD Arc<[T]> ``` For discussion of #124367 (comment). Key pain points currently: > I've had a guess at the best locations/feature attrs for them but they might not be correct. > However I'm unclear how to get the OsStr impl to compile, which file should they go in to avoid the error below? Is it possible, perhaps with some special std rust lib magic?
keep the `STAGE0_MISSING_TARGETS` list updated Implements #124461 (comment). r? pietroalbini
CI: fix toolstate publishing Toolstate publishing after something broke was not working (discovered [here](#124050 (comment))). The toolstate env. vars should only be needed for the publishing step, so I moved them there. The toolstate script is also being checked in `mingw-check` on PR and auto CI, but it doesn't really seem to do anything, and it shouldn't require the token.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
49 participants
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.
See Commits and Changes for more details.
Created by
pull[bot]
Can you help keep this open source service alive? 💖 Please sponsor : )