subtree-push 2024-06-24 #6217
subtree-push 2024-06-24 #6217
Conversation
This paves the way for tracking more state (e.g. error tainting) in the diagnostic context handle
Merge `PatParam`/`PatWithOr`, and `Expr`/`Expr2021`, for a few reasons. - It's conceptually nice, because the two pattern kinds and the two expression kinds are very similar. - With expressions in particular, there are several places where both expression kinds get the same treatment. - It removes one unreachable match arm. - Most importantly, for #124141 I will need to introduce a new type `MetaVarKind` that is very similar to `NonterminalKind`, but records a couple of extra fields for expression metavars. It's nicer to have a single `MetaVarKind::Expr` expression variant to hold those extra fields instead of duplicating them across two variants `MetaVarKind::{Expr,Expr2021}`. And then it makes sense for patterns to be treated the same way, and for `NonterminalKind` to also be treated the same way. I also clarified the comments, because I have long found them a little hard to understand. 
…r-errors Rework pattern and expression nonterminal kinds. Some tweaks to `NonterminalKind` that will assist with #124141. Details in the individual commits. r? compiler-errors cc ```@eholk```
Implement `use<>` formatting in rustfmt This PR implements formatting for precise-capturing `use<>` syntax as proposed in rust-lang/rust#126753. The syntax is implemented as-if the `use<>` bound were a trait bound but with the `use` keyword as its path segment identifier. I opted to develop this in the rust-lang/rust tree since I'm not certain when the next rustfmt subtree sync is going to be, and I'd rather not block landing nightly support for `use<>` on something I have no control over. If ``@rust-lang/rustfmt`` would rather I move this PR over to that repository, then I would at least like to know when the next rustfmt->rust subtree sync is going to be, since stabilizing `precise_capturing` without formatting will be disruptive. This implementation is otherwise rather straightforward. Tracking: - rust-lang/rust#123432
Remove stray println from rustfmt's `rewrite_static` r? `@calebcartwright` `@ytmimi` -- though anyone should probably r+ this so it gets into nightly sooner than later, since it's obviously wrong. This can just be fixed in-tree, since I don't think we want to wait until the next sync to fix this. Fix rust-lang#6210 Fix rust-lang/rust#126887
| weird, I see that 514fe39 pulled in the commit that removed the stray Maybe there was an issue with the merge? |
| Oh yea, what the heck? The merge commit added it back. |
| Really strange behavior. Maybe you could reset to 514fe39 and then try the merge again? |
| Yep -- I did that. I think this is just what git thinks is right when merging |
| I believe this is relevant:
|
| I'll push a commit on top to revert the bad merge tomorrow. Git is so weird. |
it really can be. it's times like these that make me feel like I need to review every line of diffs on the pushes, even the "successfully" staged ones |
| @calebcartwright: I believe it's probably most effective to add as a "step" to your runbook (in your brain or otherwise) to review the diff of the merge commit itself, rather than reviewing every line which can be a lot of work. You can view the diff of the merge commit if you ask git to show it:
I would've probably caught that if I knew that this was something git could do. |
…-2024-06-24 subtree-push 2024-06-24 Merge commit from master
7 participants
Bumped the toolchain from rust-lang/rust@8337ba918 2024-06-12 to rust-lang/rust@6b0f4b5ec 2024-06-24.
Pulled in some interesting commits, notably:
rewrite_staticrust#126888 hotfix for a stray println.use<>formatting in rustfmt rust#126754 which implements the style consensus in Add nightly style guide section forprecise_capturinguse<>syntax rust#126753.Otherwise a pretty minor subtree sync :^)