Skip to content

Variety of small cleanups - #3805

Merged
catamorphism merged 7 commits into
rust-lang:incomingfrom
erickt:incoming
Oct 18, 2012
Merged

Variety of small cleanups#3805
catamorphism merged 7 commits into
rust-lang:incomingfrom
erickt:incoming

Conversation

@erickt

@erickt erickt commented Oct 18, 2012

Copy link
Copy Markdown
Contributor

This pull request includes:

  • Rewriting io::ByteBuf as the struct io::BytesWriter
  • Making with_bytes_writer/with_bytes_reader pure (Make io::with_str_writer pure #3758)
  • Renaming str::to_unique to str::to_owned
  • Other minor cleanups

catamorphism added a commit that referenced this pull request Oct 18, 2012
Variety of small cleanups
@catamorphism
catamorphism merged commit 141ef23 into rust-lang:incoming Oct 18, 2012
@catamorphism

Copy link
Copy Markdown
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>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants