Josh rustup #8
Open
Josh rustup #8
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
flip1995
force-pushed
the
josh-automation
branch
5 times, most recently
from
3f6693b to
3957dad
Compare
flip1995
force-pushed
the
josh-rustup
branch
2 times, most recently
from
8c23274 to
13f01a7
Compare
flip1995
force-pushed
the
josh-automation
branch
2 times, most recently
from
fd562d8 to
01904b0
Compare
…-stmts, r=lcnr Don't recompute `tail` in `lower_stmts` Does not really matter, but this is slightly nicer. `@bors` rollup
Rollup of 4 pull requests Successful merges: - #125635 (Rename HIR `TypeBinding` to `AssocItemConstraint` and related cleanup) - #125774 (Avoid unwrap diag.code directly in note_and_explain_type_err) - #125786 (Fold item bounds before proving them in `check_type_bounds` in new solver) - #125790 (Don't recompute `tail` in `lower_stmts`) r? `@ghost` `@rustbot` modify labels: rollup
Do not ICE when suggesting dereferencing closure arg Account for `for` lifetimes when constructing closure to see if dereferencing the return value would be valid. Fix #125634, fix #124563.
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
Don't suggest awaiting in closure patterns
Fixes #126903.
For
```rust
async fn do_async() {}
fn main() {
Some(do_async()).map(|()| {});
}
```
the error is now
```rust
error[E0308]: mismatched types
--> src/main.rs:4:27
|
4 | Some(do_async()).map(|()| {});
| ^^
| |
| expected future, found `()`
| expected due to this
|
= note: expected opaque type `impl Future<Output = ()>`
found unit type `()`
```
Ideally, if `main` were to be `async`, it should be
```rs
error[E0308]: mismatched types
--> src/main.rs:4:27
|
4 | Some(do_async()).map(|()| {});
| ^^
| |
| expected future, found `()`
| expected due to this
|
= note: expected opaque type `impl Future<Output = ()>`
found unit type `()`
help: consider `await`ing on the `Future`
|
4 | Some(do_async().await).map(|()| {});
| ++++++
```
However, this would mean `FnCtx::check_pat_top` would have to be called with an `origin_expr` in `rustc_hir_typeck::check::check_fn`, and that expr would have to be somehow plumbed through `FnCtxt::check_expr_closure` and closure signature deduction. I'm willing to work on the plumbing but unsure how to start.
De-duplicate all consecutive native libs regardless of their options Address rust-lang/rust#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``
Rollup of 7 pull requests Successful merges: - #126618 (Mark assoc tys live only if the corresponding trait is live) - #126746 (Deny `use<>` for RPITITs) - #126868 (not use offset when there is not ends with brace) - #126884 (Do not ICE when suggesting dereferencing closure arg) - #126893 (Eliminate the distinction between PREC_POSTFIX and PREC_PAREN precedence level) - #126915 (Don't suggest awaiting in closure patterns) - #126943 (De-duplicate all consecutive native libs regardless of their options) r? `@ghost` `@rustbot` modify labels: rollup
Update cargo 10 commits in bc89bffa5987d4af8f71011c7557119b39e44a65..4ed7bee47f7dd4416b36fada1909e9a62c546246 2024-06-22 00:36:36 +0000 to 2024-06-25 16:28:22 +0000 - test: omit target-dir name (rust-lang/cargo#14142) - test: migrate offline, open_namespaces and owner to snapbox (rust-lang/cargo#14138) - docs: remove stray comment (rust-lang/cargo#14133) - Change tests to support `rustc` wording changes (rust-lang/cargo#14135) - deps: dont use tracing-attributes for workspace, use for cargo only (rust-lang/cargo#14122) - Include vcs_info even if workspace is dirty (rust-lang/cargo#13960) - test: migrate profile* to snapbox (rust-lang/cargo#14128) - test: migrate path and paths to snapbox (rust-lang/cargo#14109) - test: migrate rustflags, rustup and script to snapbox (rust-lang/cargo#14126) - test: migrate rename_deps, replace, required_features and run to snapbox (rust-lang/cargo#14127)
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 #123177
Add more constants, functions, and tests for `f16` and `f128` This adds everything that was in some way blocked on const eval, since rust-lang/rust#126429 landed. There is a lot of `cfg(bootstrap)` since that is a fairly recent change. `f128` tests are disabled on everything except x86_64 and Linux aarch64, which are two platforms I know have "good" support for these types - meaning basic math symbols are available and LLVM doesn't hit selection crashes. `f16` tests are enabled on almost everything except for known LLVM crashes. Doctests are only enabled on x86_64. Tracking issue: rust-lang/rust#116909
Remove more `PtrToPtr` casts in GVN This addresses two things I noticed in MIR: 1. `NonNull::<T>::eq` does `(a as *mut T) == (b as *mut T)`, but it could just compare the `*const T`s, so this removes `PtrToPtr` casts that are on both sides of a pointer comparison, so long as they're not fat-to-thin casts. 2. `NonNull::<T>::addr` does `transmute::<_, usize>(p as *const ())`, but so long as `T: Thin` that cast doesn't do anything, and thus we can directly transmute the `*const T` instead. r? mir-opt
…u,blyxyas Let's `#[expect]` some lints: Stabilize `lint_reasons` (RFC 2383) Let's give this another try! The [previous stabilization attempt](rust-lang/rust#99063) was stalled by some unresolved questions. These have been discussed in a [lang team](rust-lang/lang-team#191) meeting. The last open question, regarding the semantics of the `#[expect]` attribute was decided on in rust-lang/rust#115980 I've just updated the [stabilization report](rust-lang/rust#54503 (comment)) with the discussed questions and decisions. Luckily, the decision is inline with the current implementation. This hopefully covers everything. Let's hope that the CI will be green like the spring. fixes #115980 fixes #54503 --- r? `@wesleywiser` Tacking Issue: rust-lang/rust#54503 Stabilization Report: rust-lang/rust#54503 (comment) Documentation Update: rust-lang/reference#1237 <!-- For Clippy: changelog: [`allow_attributes`]: Is now available on stable, since the `lint_reasons` feature was stabilized changelog: [`allow_attributes_without_reason`]: Is now available on stable, since the `lint_reasons` feature was stabilized --> --- Roses are red, Violets are blue, Let's expect lints, With reason clues
Use `clang-format` in `tidy` to check the C++ code style under `llvm-wrapper` Fixes #123510. Based on the discussion at https://rust-lang.zulipchat.com/#narrow/stream/233931-t-compiler.2Fmajor-changes/topic/Enable.20.60clang-format.60.20for.20.60rustc.60.20compiler-team.23756/near/443562800, we can use clang-format from pip to achieve the code formatting. r? `@Kobzol`
patch `rust-lld` and `ld.lld` on NixOS When `rustc` uses its self-contained lld, we also need to patch `rust-lld` and `ld.lld`. The `rpath` for `rust-lld` is `$ORIGIN/../../../:$ORIGIN/../lib`, so I use `--add-rpath` instead of `--set-rpath`, which should be easier to maintain. I also changed `src/bootstrap/src/core/download.rs`, even this doesn't fix any known issues. For the `lld-wrapper.sh` of lld, refer to: rust-lang/rustc-dev-guide#1999.
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
rustdoc: use current stage if download-rustc enabled When using download-rustc, using stage 1 rustdoc results in the wrong librustc_driver being used. ```sh $ ./build/host/stage1/bin/rustdoc --version ./build/host/stage1/bin/rustdoc: error while loading shared libraries: librustc_driver-7ff02ed05016d515.so: cannot open shared object file: No such file or directory ``` This change fixes that by not cutting the stage if download-rustc is enabled.
ast: Standardize visiting order Order: ID, attributes, inner nodes in source order if possible, tokens, span. Also always use exhaustive matching in visiting infra, and visit some discovered missing nodes. Unlike rust-lang/rust#125741 this shouldn't affect anything serious like `macro_rules` scopes.
Clippy subtree update r? `@Manishearth`
There was some dependence between the different subcommands of clippy_dev. And this dependence will increased with the introduction of the sync and release subcommands. This moves the common functions to a `utils` module, to decouple the other modules.
flip1995
force-pushed
the
josh-automation
branch
from
852fc21 to
7808dbc
Compare
Now that JOSH is used to sync, it is much easier to script the sync process. This introduces the two commands `sync pull` and `sync push`. The first one will pull changes from the Rust repo, the second one will push the changes to the Rust repo. For details, see the documentation in the book.
This is a QoL improvement for doing releases. The `release bump_version` subcommand increments the version in all relevant `Cargo.toml` files. The `release commit` command will only work with the new Josh syncs. Until then the old way, using `git log` has to be used.
flip1995
force-pushed
the
josh-automation
branch
from
7808dbc to
9a8881f
Compare
flip1995
force-pushed
the
josh-automation
branch
from
9a8881f to
fc1b821
Compare
flip1995
force-pushed
the
josh-automation
branch
from
fc1b821 to
3ec2859
Compare
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.
changelog: none