Automatic Rustup #3252
Merged
Automatic Rustup #3252
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
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
Make closures carry their own ClosureKind Right now, we use the "`movability`" field of `hir::Closure` to distinguish a closure and a coroutine. This is paired together with the `CoroutineKind`, which is located not in the `hir::Closure`, but the `hir::Body`. This is strange and redundant. This PR introduces `ClosureKind` with two variants -- `Closure` and `Coroutine`, which is put into `hir::Closure`. The `CoroutineKind` is thus removed from `hir::Body`, and `Option<Movability>` no longer needs to be a stand-in for "is this a closure or a coroutine". r? eholk
Removed redundant bounds checking at Split's next and next_back methods Since these methods are using `Iterator::rposition`, which always returns a valid index, then there is no point in regular indexing with bounds checking
Miri subtree update r? `@ghost`
rework `-Zverbose` implements the changes described in rust-lang/compiler-team#706 the first commit is only a name change from `-Zverbose` to `-Zverbose-internals` and does not change behavior. the second commit changes diagnostics. possible follow up work: - `ty::pretty` could print more info with `--verbose` than it does currently. `-Z verbose-internals` shows too much info in a way that's not helpful to users. michael had ideas about this i didn't fully understand: https://rust-lang.zulipchat.com/#narrow/stream/233931-t-compiler.2Fmajor-changes/topic/uplift.20some.20-Zverbose.20calls.20and.20rename.20to.E2.80.A6.20compiler-team.23706/near/408984200 - `--verbose` should imply `-Z write-long-types-to-disk=no`. the code in `ty_string_with_limit` should take `--verbose` into account (apparently this affects `Ty::sort_string`, i'm not familiar with this code). writing a file to disk should suggest passing `--verbose`. r? `@compiler-errors` cc `@estebank`
Add `hint::assert_unchecked` Libs-API expressed interest, modulo bikeshedding, in rust-lang/libs-team#315 (comment) I think that means this is good for nightly, since we can always rename it before stabilization. Tracking issue: rust-lang/rust#119131
fallback `default` to `None` during ast-lowering for lifetime binder Fixes #118697 This is another attempt. It has a fallback, setting `default` to `None` and emit an error for non-lifetime binders during ast lowering. r? `@compiler-errors`
Emit better suggestions for `&T == T` and `T == &T` Fixes #40660 Fixes #44695
Support encoding spans with relative offsets The relative offset is often smaller than the absolute offset, and with the LEB128 encoding, this ends up cutting the overall metadata size considerably (~1.5 megabytes on libcore). We can support both relative and absolute encodings essentially for free since we already take a full byte to differentiate between direct and indirect encodings (so an extra variant is quite cheap).
Suggest `=>` --> `>=` in comparisons Fixes #117245
Fix parenthesization of subexprs containing statement boundary
This PR fixes a multitude of false negatives and false positives in the AST pretty printer's parenthesis insertion related to statement boundaries — statements which terminate unexpectedly early if there aren't parentheses.
Without this fix, the AST pretty printer (including both `stringify!` and `rustc -Zunpretty=expanded`) is prone to producing output which is not syntactically valid Rust. Invalid output is problematic because it means Rustfmt is unable to parse the output of `cargo expand`, for example, causing friction by forcing someone trying to debug a macro into reading poorly formatted code.
I believe the set of bugs fixed in this PR account for the most prevalent reason that `cargo expand` produces invalid output in real-world usage.
Fixes #98790.
## False negatives
The following is a correct program — `cargo check` succeeds.
```rust
macro_rules! m {
($e:expr) => {
match () { _ => $e }
};
}
fn main() {
m!({ 1 } - 1);
}
```
But `rustc -Zunpretty=expanded main.rs` produces output that is invalid Rust syntax, because parenthesization is needed and not being done by the pretty printer.
```rust
fn main() { match () { _ => { 1 } - 1, }; }
```
Piping this expanded code to rustfmt, it fails to parse.
```console
error: unexpected `,` in pattern
--> <stdin>:1:38
|
1 | fn main() { match () { _ => { 1 } - 1, }; }
| ^
|
help: try adding parentheses to match on a tuple...
|
1 | fn main() { match () { _ => { 1 } (- 1,) }; }
| + +
help: ...or a vertical bar to match on multiple alternatives
|
1 | fn main() { match () { _ => { 1 } - 1 | }; }
| ~~~~~
```
Fixed output after this PR:
```rust
fn main() { match () { _ => ({ 1 }) - 1, }; }
```
## False positives
Less problematic, but worth fixing (just like #118726).
```rust
fn main() {
let _ = match () { _ => 1 } - 1;
}
```
Output of `rustc -Zunpretty=expanded lib.rs` before this PR. There is no reason parentheses would need to be inserted there.
```rust
fn main() { let _ = (match () { _ => 1, }) - 1; }
```
After this PR:
```rust
fn main() { let _ = match () { _ => 1, } - 1; }
```
## Alternatives considered
In this PR I opted to parenthesize only the leading subexpression causing the statement boundary, rather than the entire statement. Example:
```rust
macro_rules! m {
($e:expr) => {
$e
};
}
fn main() {
m!(loop { break [1]; }[0] - 1);
}
```
This PR produces the following pretty-printed contents for fn main:
```rust
(loop { break [1]; })[0] - 1;
```
A different equally correct output would be:
```rust
(loop { break [1]; }[0] - 1);
```
I chose the one I did because it is the *only* approach used by handwritten code in the standard library and compiler. There are 4 places where parenthesization is being used to prevent a statement boundary, and in all 4, the developer has chosen to parenthesize the smallest subexpression rather than the whole statement:
https://github.com/rust-lang/rust/blob/b37d43efd9c5a7a3d76ed21c454dd0f40945d77d/compiler/rustc_codegen_cranelift/example/alloc_system.rs#L102
https://github.com/rust-lang/rust/blob/b37d43efd9c5a7a3d76ed21c454dd0f40945d77d/compiler/rustc_parse/src/errors.rs#L1021-L1029
https://github.com/rust-lang/rust/blob/b37d43efd9c5a7a3d76ed21c454dd0f40945d77d/library/core/src/future/poll_fn.rs#L151
https://github.com/rust-lang/rust/blob/b37d43efd9c5a7a3d76ed21c454dd0f40945d77d/library/core/src/ops/range.rs#L824-L828
utilize the unused `llvm-tools` option This field was not functioning as described in its comment in `config.example.toml`. Also, updated the default value to `true` to keep the bootstrapping behavior as it was before. cc `@Zalathar`
Only store StableCrateId once in DefPathTable. rust-lang/rust#119238 made me think of this. cc `@Mark-Simulacrum`
fix: correct the args for `disambiguate the associated function` diagnostic This is somehow silimar to rust-lang/rust#118502, we shouldn't take receiver as first arg all the cases. close rust-lang/rust#118819
Implement constant propagation on top of MIR SSA analysis This implements the idea I proposed in rust-lang/rust#110719 (comment) Based on rust-lang/rust#109597 The value numbering "GVN" pass formulates each rvalue that appears in MIR with an abstract form (the `Value` enum), and assigns an integer `VnIndex` to each. This abstract form can be used to deduplicate values, reusing an earlier local that holds the same value instead of recomputing. This part is proposed in #109597. From this abstract representation, we can perform more involved simplifications, for example in rust-lang/rust#111344. With the abstract representation `Value`, we can also attempt to evaluate each to a constant using the interpreter. This builds a `VnIndex -> OpTy` map. From this map, we can opportunistically replace an operand or a rvalue with a constant if their value has an associated `OpTy`. The most relevant commit is [Evaluated computed values to constants.](rust-lang/rust@2767c49)" r? `@oli-obk`
…r=cjgillot Change `rustc_codegen_ssa`'s `atomic_cmpxchg` interface to return a pair of values Doesn't change much, but a little nicer that way.
Don't drop a hir node after lowering Fixes rust-lang/rust#119271. It seems that all hir nodes that get allocated an id must be placed within the hir on pain of ICEs. In rust-lang/rust#118527 I dropped guards on never patterns since they're not useful, which caused the ICE.
…r=GuillaumeGomez rustdoc: clean up source sidebar hide button This is a redesign of the feature, with parts pulled from rust-lang/rust#119049 but with a button that looks more like a button and matches the one used on other sidebar pages. Preview: * http://notriddle.com/rustdoc-html-demo-8/source-sidebar-resize/src/std/lib.rs.html * http://notriddle.com/rustdoc-html-demo-8/source-sidebar-resize/std/index.html | | Before | After | |--|--|--| | Closed |  |  | Open |  |  | Mobile Closed |  |  | Mobile Open |  | 
std::net::bind using -1 for openbsd which in turn sets it to somaxconn. trusting platform's SOMAXCONN instead of hardcoding to 128 otherwise.
Make named_asm_labels lint not trigger on unicode and trigger on format args Someone showed me some cursed code that used format args to create named labels, and rustc wasn't linting on that. Additionally while fixing that, I noticed that Unicode alphabetic characters were being used as part of labels, when they are not actually permitted in labels. r? ```@Amanieu```
Promote `riscv32{im|imafc}` targets to tier 2
Pending the approval of [the MCP](rust-lang/compiler-team#701).
…twco Switch from using `//~ERROR` annotations with `--error-format` to `error-pattern` Fixes #118752 As noticed by ```@jyn514``` while working on a patch, tests failed due to `//~ERROR` annotations used in combination with the older `--error-format` which is now `error-pattern`.
custom mir: make it clear what the return block is Custom MIR recently got support for specifying the "unwind action", so now there's two things coming after the actual call part of `Call` terminators. That's not very self-explaining so I propose we change the syntax to imitate keyword arguments: ``` Call(popped = Vec::pop(v), ReturnTo(drop), UnwindContinue()) ``` Also fix some outdated docs and add some docs to `Call` and `Drop`.
Use Result::flatten in catch_with_exit_code
Support reg_addr register class in s390x inline assembly In s390x, `r0` cannot be used as an address register (it is evaluated as zero in an address context). Therefore, currently, in assemblies involving memory accesses, `r0` must be [marked as clobbered](https://github.com/taiki-e/atomic-maybe-uninit/blob/1a1155653a26667396c805954ab61c8cbb14de8c/src/arch/s390x.rs#L58) or [explicitly used to a non-address](https://github.com/taiki-e/atomic-maybe-uninit/blob/1a1155653a26667396c805954ab61c8cbb14de8c/src/arch/s390x.rs#L135) or explicitly use an address register to prevent `r0` from being allocated to a register for the address. This patch adds a register class for allocating general-purpose registers, except `r0`, to make it easier to use address registers. (powerpc already has a register class (reg_nonzero) for a similar purpose.) This is identical to the `a` constraint in LLVM and GCC: https://llvm.org/docs/LangRef.html#supported-constraint-code-list > a: A 32, 64, or 128-bit integer address register (excludes R0, which in an address context evaluates as zero). https://gcc.gnu.org/onlinedocs/gcc/Machine-Constraints.html > a > Address register (general purpose register except r0) cc ``@uweigand`` r? ``@Amanieu``
Remove libtest's dylib libtest.so is only used by rustdoc, and tests seem to pass locally with this change. I suppose if this is broken, the only way to find out is to make a PR.
Make offset_of field parsing use metavariable which handles any spacing As discussed at and around comments rust-lang/rust#106655 (comment) and rust-lang/rust#106655 (comment), the current arguments to offset_of do not accept all the whitespace combinations: `0. 1.1.1` and `0.1.1. 1` are currently treated specially in `tests/ui/offset-of/offset-of-tuple-nested.rs`. They also do not allow [forwarding individual fields as in](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=444cdf0ec02b99e8fd5fd8d8ecb312ca) ```rust macro_rules! off { ($a:expr) => { offset_of!(m::S, 0. $a) } } ``` This PR replaces the macro arguments with `($Container:ty, $($fields:expr)+ $(,)?)` which does allow any arrangement of whitespace that I could come up with and the forwarding of fields example above. This also allows for array indexing in the future, which I think is the last future extension to the syntax suggested in the offset_of RFC. Tracking issue for offset_of: #106655 ``@rustbot`` label F-offset_of ``@est31``
stop feed vis when cant access for trait item Fixes #119463 It's not necessary to feed visibility when use a private trait. r? ``@petrochenkov``
Miri subtree update r? `@ghost`
Rollup of 10 pull requests
Successful merges:
- #117636 (add test for #117626)
- #118704 (Promote `riscv32{im|imafc}` targets to tier 2)
- #119184 (Switch from using `//~ERROR` annotations with `--error-format` to `error-pattern`)
- #119325 (custom mir: make it clear what the return block is)
- #119391 (Use Result::flatten in catch_with_exit_code)
- #119431 (Support reg_addr register class in s390x inline assembly)
- #119475 (Remove libtest's dylib)
- #119532 (Make offset_of field parsing use metavariable which handles any spacing)
- #119553 (stop feed vis when cant access for trait item)
- #119574 (Miri subtree update)
r? `@ghost`
`@rustbot` modify labels: rollup
Rollup of 10 pull requests Successful merges: - #118521 (Enable address sanitizer for MSVC targets using INFERASANLIBS linker flag) - #119026 (std::net::bind using -1 for openbsd which in turn sets it to somaxconn.) - #119195 (Make named_asm_labels lint not trigger on unicode and trigger on format args) - #119204 (macro_rules: Less hacky heuristic for using `tt` metavariable spans) - #119362 (Make `derive(Trait)` suggestion more accurate) - #119397 (Recover parentheses in range patterns) - #119417 (Uplift some miscellaneous coroutine-specific machinery into `check_closure`) - #119539 (Fix typos) - #119540 (Don't synthesize host effect args inside trait object types) - #119555 (Add codegen test for RVO on MaybeUninit) r? `@ghost` `@rustbot` modify labels: rollup
Reorder check_item_type diagnostics so they occur next to the corresponding `check_well_formed` diagnostics The first commit is just a cleanup. The second commit moves most checks from `check_mod_item_types` into `check_well_formed`, invoking the checks in lockstep per-item instead of iterating over all items twice.
Set the `in-rust-tree` feature for all rust-analyzer{-proc-macro-srv} steps
Some context: This came up in https://rust-lang.zulipchat.com/#narrow/stream/185405-t-compiler.2Frust-analyzer/topic/libraryfying.20match.20checking.3F where `test` and `check` behaved differently for rust-analyzer
r? `@onur-ozkan`
|
@bors r+ |
|
☀️ Test successful - checks-actions |
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.
No description provided.