Extract an arguments struct for Builder::then_else_break
#121928
Merged
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
rustbot
added
S-waiting-on-review
|
Some changes occurred in match lowering cc @Nadrieril |
|
All of the new comments are based on my own understanding, so they could certainly use a second opinion from someone more familiar with this code. |
Nadrieril
reviewed
Mar 3, 2024
|
I have one comment, otherwise I think this is a net improvement in code legibility, thank you! r? @Nadrieril |
|
Updated to address feedback (diff). Now all of the external callers are unchanged, except for some extra comments. The arguments struct is purely an internal detail of |
Zalathar
commented
Mar 4, 2024
Most of this method's arguments are usually or always forwarded as-is to recursive invocations. Wrapping them in a dedicated struct allows us to document each struct field, and lets us use struct-update syntax to indicate which arguments are being modified when making a recursive call.
|
Thank you! @bors r+ rollup=always |
bors
added
S-waiting-on-bors
GuillaumeGomez
added a commit
to GuillaumeGomez/rust
that referenced
this pull request
Mar 4, 2024
Extract an arguments struct for `Builder::then_else_break` Most of this method's arguments are usually or always forwarded as-is to recursive invocations. Wrapping them in a dedicated struct allows us to document each struct field, and lets us use struct-update syntax to indicate which arguments are being modified when making a recursive call. --- While trying to understand the lowering of `if` expressions, I found it difficult to keep track of the half-dozen arguments passed through to every call to `then_else_break`. I tried switching over to an arguments struct, and I found that it really helps to make sense of what each argument does, and how each call is modifying the arguments. I have some further ideas for how to streamline these recursive calls, but I've kept those out of this PR so that it's a pure refactoring with no behavioural changes.
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Mar 4, 2024
…llaumeGomez Rollup of 9 pull requests Successful merges: - rust-lang#120976 (constify a couple thread_local statics) - rust-lang#121576 (Convert the rest of the visitors to use `VisitorResult`) - rust-lang#121826 (Use root obligation on E0277 for some cases) - rust-lang#121928 (Extract an arguments struct for `Builder::then_else_break`) - rust-lang#121958 (Fix redundant import errors for preload extern crate) - rust-lang#121959 (Removing absolute path in proc-macro) - rust-lang#121968 (Don't run test_get_os_named_thread on win7) - rust-lang#121977 (Doc: Fix incorrect reference to integer in Atomic{Ptr,Bool}::as_ptr.) - rust-lang#121978 (Fix duplicated path in the "not found dylib" error) r? `@ghost` `@rustbot` modify labels: rollup
matthiaskrgr
added a commit
to matthiaskrgr/rust
that referenced
this pull request
Mar 4, 2024
Extract an arguments struct for `Builder::then_else_break` Most of this method's arguments are usually or always forwarded as-is to recursive invocations. Wrapping them in a dedicated struct allows us to document each struct field, and lets us use struct-update syntax to indicate which arguments are being modified when making a recursive call. --- While trying to understand the lowering of `if` expressions, I found it difficult to keep track of the half-dozen arguments passed through to every call to `then_else_break`. I tried switching over to an arguments struct, and I found that it really helps to make sense of what each argument does, and how each call is modifying the arguments. I have some further ideas for how to streamline these recursive calls, but I've kept those out of this PR so that it's a pure refactoring with no behavioural changes.
This was referenced Mar 4, 2024
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Mar 4, 2024
…iaskrgr Rollup of 10 pull requests Successful merges: - rust-lang#120976 (constify a couple thread_local statics) - rust-lang#121683 (Fix LVI tests after frame pointers are enabled by default) - rust-lang#121703 (Add a way to add constructors for `rustc_type_ir` types) - rust-lang#121732 (Improve assert_matches! documentation) - rust-lang#121928 (Extract an arguments struct for `Builder::then_else_break`) - rust-lang#121939 (Small enhancement to description of From trait) - rust-lang#121968 (Don't run test_get_os_named_thread on win7) - rust-lang#121969 (`ParseSess` cleanups) - rust-lang#121977 (Doc: Fix incorrect reference to integer in Atomic{Ptr,Bool}::as_ptr.) - rust-lang#121994 (Update platform-support.md with supported musl version) r? `@ghost` `@rustbot` modify labels: rollup
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Mar 4, 2024
…iaskrgr Rollup of 10 pull requests Successful merges: - rust-lang#120976 (constify a couple thread_local statics) - rust-lang#121683 (Fix LVI tests after frame pointers are enabled by default) - rust-lang#121703 (Add a way to add constructors for `rustc_type_ir` types) - rust-lang#121732 (Improve assert_matches! documentation) - rust-lang#121928 (Extract an arguments struct for `Builder::then_else_break`) - rust-lang#121939 (Small enhancement to description of From trait) - rust-lang#121968 (Don't run test_get_os_named_thread on win7) - rust-lang#121969 (`ParseSess` cleanups) - rust-lang#121977 (Doc: Fix incorrect reference to integer in Atomic{Ptr,Bool}::as_ptr.) - rust-lang#121994 (Update platform-support.md with supported musl version) r? `@ghost` `@rustbot` modify labels: rollup
rust-timer
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Mar 5, 2024
Rollup merge of rust-lang#121928 - Zalathar:then-else-args, r=Nadrieril Extract an arguments struct for `Builder::then_else_break` Most of this method's arguments are usually or always forwarded as-is to recursive invocations. Wrapping them in a dedicated struct allows us to document each struct field, and lets us use struct-update syntax to indicate which arguments are being modified when making a recursive call. --- While trying to understand the lowering of `if` expressions, I found it difficult to keep track of the half-dozen arguments passed through to every call to `then_else_break`. I tried switching over to an arguments struct, and I found that it really helps to make sense of what each argument does, and how each call is modifying the arguments. I have some further ideas for how to streamline these recursive calls, but I've kept those out of this PR so that it's a pure refactoring with no behavioural changes.
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.
Most of this method's arguments are usually or always forwarded as-is to recursive invocations.
Wrapping them in a dedicated struct allows us to document each struct field, and lets us use struct-update syntax to indicate which arguments are being modified when making a recursive call.
While trying to understand the lowering of
ifexpressions, I found it difficult to keep track of the half-dozen arguments passed through to every call tothen_else_break. I tried switching over to an arguments struct, and I found that it really helps to make sense of what each argument does, and how each call is modifying the arguments.I have some further ideas for how to streamline these recursive calls, but I've kept those out of this PR so that it's a pure refactoring with no behavioural changes.