-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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 #126950
Closed
Closed
Rollup of 7 pull requests #126950
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
While at it, order the list of architectures alphabetically.
While at it, order the list of architectures alphabetically.
While at it, order the list of architectures alphabetically.
The previously -mv8plus parameter is supported by GCC only, so let's use something that the SPARC backend in LLVM supports as well.
It was somewhat confusing that the old constructor would create a `FlatPat` in a (possibly) non-simplified state, and then simplify its contents in-place. So instead we now create its fields as local variables, perform simplification, and then create the struct afterwards. This doesn't affect correctness, but is less confusing.
Currently rustdoc breaks the build cache (due to having different rustflags) when building rustdoc before building another tool (e.g., `x test miri && x test rustdoc && x test miri`). This change fixes that by moving `on-broken-pipe` into `prepare_cargo_tool` so it is set for all tools. Signed-off-by: onur-ozkan <work@onurozkan.dev>
Eliminate the distinction between PREC_POSTFIX and PREC_PAREN precedence level I have been tangling with precedence as part of porting some pretty-printer improvements from syn back to rustc (related to parenthesization of closures, returns, and breaks by the AST pretty-printer). As far as I have been able to tell, there is no difference between the 2 different precedence levels that rustc identifies as `PREC_POSTFIX` (field access, square bracket index, question mark, method call) and `PREC_PAREN` (loops, if, paths, literals). There are a bunch of places that look at either `prec < PREC_POSTFIX` or `prec >= PREC_POSTFIX`. But there is nothing that needs to distinguish PREC_POSTFIX and PREC_PAREN from one another. https://github.com/rust-lang/rust/blob/d49994b060684af423339b55769439b2f444a7b9/compiler/rustc_ast/src/util/parser.rs#L236-L237 https://github.com/rust-lang/rust/blob/d49994b060684af423339b55769439b2f444a7b9/compiler/rustc_hir_typeck/src/fn_ctxt/suggestions.rs#L2829 https://github.com/rust-lang/rust/blob/d49994b060684af423339b55769439b2f444a7b9/compiler/rustc_hir_typeck/src/fn_ctxt/suggestions.rs#L1290 In the interest of eliminating a distinction without a difference, this PR collapses these 2 levels down to 1. There is exactly 1 case where an expression with PREC_POSTFIX precedence needs to be parenthesized in a location that an expression with PREC_PAREN would not, and that's when the receiver of ExprKind::MethodCall is ExprKind::Field. `x.f()` means a different thing than `(x.f)()`. But this does not justify having separate precedence levels because this special case in the grammar is not governed by precedence. Field access does not have "lower precedence than" method call syntax — you can tell because if it did, then `x.f[0].f()` wouldn't be able to have its unparenthesized field access in the receiver of a method call. Because this Field/MethodCall special case is not governed by precedence, it already requires special handling and is not affected by eliminating the PREC_POSTFIX precedence level. https://github.com/rust-lang/rust/blob/d49994b060684af423339b55769439b2f444a7b9/compiler/rustc_ast_pretty/src/pprust/state/expr.rs#L217-L221
Fixes for 32-bit SPARC on Linux This PR fixes a number of issues which previously prevented `rustc` from being built successfully for 32-bit SPARC using the `sparc-unknown-linux-gnu` triplet. In particular, it adds linking against `libatomic` where necessary, uses portable `AtomicU64` for `rustc_data_structures` and rewrites the spec for `sparc_unknown_linux_gnu` to use `TargetOptions` and replaces the previously used `-mv8plus` with the more portable `-mcpu=v9 -m32`. To make `rustc` build successfully, support for 32-bit SPARC needs to be added to the `object` crate as well as the `nix` crate which I will be sending out later as well. r? nagisa
Tweak `FlatPat::new` to avoid a temporarily-invalid state It was somewhat confusing that the old constructor would create a `FlatPat` in a (possibly) non-simplified state, and then simplify its contents in-place. So instead we now create its fields as local variables, perform simplification, and then create the struct afterwards. This doesn't affect correctness, but is less confusing. --- I've also included some semi-related comments that I made while trying to navigate this code.
…obzol fix broken build cache caused by rustdoc builds Currently rustdoc breaks the build cache (due to having different rustflags) when building rustdoc before building another tool (e.g., `x test miri && x test rustdoc && x test miri`). This change fixes that by moving `on-broken-pipe` into `prepare_cargo_tool` so it is set for all tools. cc `@RalfJung` Fixes rust-lang#123177
De-duplicate all consecutive native libs regardless of their options Address rust-lang#126913 (comment) by no longer de-duplicating based on the "options" but by only looking at the generated link args, as to avoid consecutive libs that originated from different native-lib with different options (like `raw-dylib` on Windows) but isn't relevant for `--print=native-static-libs`. r? `@petrochenkov`
Add missing slash in `const_eval_select` doc comment In the middle of the doc comment, one line has only two slashes instead of three and isn't included in the [rendered documentation](https://doc.rust-lang.org/std/intrinsics/fn.const_eval_select.html#stability-concerns). This PR adds the missing slash.
…ctoring, r=petrochenkov Delegation: ast lowering refactor refactoring changes for rust-lang#126699 r? `@petrochenkov`
@bors r+ rollup=never p=7 |
rustbot
added
S-waiting-on-review
Status: Awaiting review from the assignee but also interested parties.
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.
rollup
A PR which is a rollup
labels
Jun 25, 2024
bors
added
S-waiting-on-bors
Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
and removed
S-waiting-on-review
Status: Awaiting review from the assignee but also interested parties.
labels
Jun 25, 2024
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Jun 25, 2024
…mpiler-errors Rollup of 7 pull requests Successful merges: - rust-lang#126893 (Eliminate the distinction between PREC_POSTFIX and PREC_PAREN precedence level) - rust-lang#126907 (Fixes for 32-bit SPARC on Linux) - rust-lang#126932 (Tweak `FlatPat::new` to avoid a temporarily-invalid state) - rust-lang#126934 (fix broken build cache caused by rustdoc builds) - rust-lang#126943 (De-duplicate all consecutive native libs regardless of their options) - rust-lang#126946 (Add missing slash in `const_eval_select` doc comment) - rust-lang#126947 (Delegation: ast lowering refactor) r? `@ghost` `@rustbot` modify labels: rollup
💔 Test failed - checks-actions |
bors
added
S-waiting-on-review
Status: Awaiting review from the assignee but also interested parties.
and removed
S-waiting-on-bors
Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
labels
Jun 25, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
A-run-make
Area: port run-make Makefiles to rmake.rs
rollup
A PR which is a rollup
S-waiting-on-review
Status: Awaiting review from the assignee but also interested parties.
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:
FlatPat::new
to avoid a temporarily-invalid state #126932 (TweakFlatPat::new
to avoid a temporarily-invalid state)const_eval_select
doc comment #126946 (Add missing slash inconst_eval_select
doc comment)r? @ghost
@rustbot modify labels: rollup
Create a similar rollup