Variety of small cleanups - #3805
Merged
Merged
Conversation
This is minor and probably completely inconsequential to performance, but I find vec::map to be more clear than vec::each and a push.
catamorphism
added a commit
that referenced
this pull request
Oct 18, 2012
Variety of small cleanups
Contributor
|
Thanks! |
U007D
pushed a commit
to U007D/rust-mos
that referenced
this pull request
Aug 21, 2026
3805: lower literal patterns r=JoshMcguigan a=JoshMcguigan While working on rust-lang#3706 I discovered literal patterns weren't being lowered. This PR implements that lowering. Questions for reviewers: 1. This re-uses the existing conversion from `ast::LiteralKind` to `Literal`, but `ast::LiteralKind` doesn't include information about the actual value of the literal, which causes `Literal` to be created with the default value for the type (rather than the actual value in the source code). Am I correct in thinking that we'd eventually want to change things in such a way that we could initialize the `Literal` with the actual literal value? Is there an existing issue for this, or else perhaps I should create one to discuss how it should be implemented? My main question would be whether `ast::LiteralKind` should be extended to hold the actual value, or if we should provide some other way to get that information from `ast::Literal`? 2. I couldn't find tests which directly cover this, but it does seem to work in rust-lang#3706. Do we have unit tests for this lowering code? 3. I'm not sure why `lit.literal()` returns an `Option`. Is returning a `Pat::Missing` in the `None` case the right thing to do? 4. I was basically practicing type-system driven development to figure out the transformation from `ast::Pat::LiteralPat` to `Pat::Lit`. I don't have an immediate question here, but I just wanted to ensure this section is looked at closely during review. Co-authored-by: Josh Mcguigan <joshmcg88@gmail.com>
U007D
pushed a commit
to U007D/rust-mos
that referenced
this pull request
Aug 21, 2026
3806: lower bool literal value r=flodiebold a=JoshMcguigan Following up on rust-lang#3805, this PR adds the literal value to `ast::LiteralKind` so when we lower we can use the actual value from the source code rather than the default value for the type. Ultimately I plan to use this for exhaustiveness checking in rust-lang#3706. I didn't include this in the previous PR because I wasn't sure if it made sense to add this information to `ast::LiteralKind` or provide some other mechanism to get this from `ast::Literal`. For now I've only implemented this for boolean literals, but I think it could be easily extended to other types. A possible exception to this are string literals, since we may not want to clone around an owned string to hold onto in `ast::LiteralKind`, and it'd be nice to avoid adding a generic lifetime as well. Perhaps we won't ever care about the actual value of a string literal? Co-authored-by: Josh Mcguigan <joshmcg88@gmail.com>
This file contains hidden or 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
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.
This pull request includes: