Uh oh!
There was an error while loading. Please reload this page.
libcore: add a str::with_capacity to match the fn in vec - #3706
Merged
Conversation
catamorphism added a commit
that referenced
this pull request
Oct 17, 2012
libcore: add a str::with_capacity to match the fn in vec
catamorphism
commented
Oct 17, 2012
Contributor
Thanks! |
bors pushed a commit
to rust-lang-ci/rust
that referenced
this pull request
May 15, 2021
RalfJung pushed a commit
to RalfJung/rust
that referenced
this pull request
Jun 29, 2024
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>
U007D pushed a commit
to U007D/rust-mos
that referenced
this pull request
Aug 21, 2026
3706: missing match arms diagnostic r=flodiebold a=JoshMcguigan Following up on rust-lang/rust-analyzer#3689 (comment), this PR creates a missing match arms diagnostic. At the moment this is a very early draft, but I wanted to open it just to get some initial feedback. Initial questions: * Have I roughly created the correct boilerplate? * Inside the new `validate_match` function: * Am I correct in thinking I want to do validation by comparing the match arms against `match_expr`? And when analyzing `match_expr` I should be looking at it as a `hir_def::expr::Expr`? * I mostly copied the chained if-let statements from the struct validation. Shouldn't there be a non-failable way to get an AstPtr from the hir data structures? Thanks for all the guidance. Co-authored-by: Josh Mcguigan <joshmcg88@gmail.com>
U007D pushed a commit
to U007D/rust-mos
that referenced
this pull request
Aug 21, 2026
3884: Match check fix missing pattern panic r=flodiebold a=JoshMcguigan As reported by @cynecx, match arm exhaustiveness checking could panic when tuple enums were missing their pattern. This was reported in the comments of rust-lang#3706. This fixes the panic, and adds a similar test to ensure tuples don't have this problem. It turns out malformed tuple patterns are caught in the "type check" outside the `is_useful` function, while malformed enum tuple patterns are not. This makes sense to me in hindsight, since the type checker can tell that an enum is the right type even if it is missing its internal pattern, but a tuple (non-enum) just becomes a different type if it is "missing" its pattern. This discrepency is why we report a diagnostic in the tuple case (because all arms are filtered out, so there are missing arms), but not in the enum tuple case (because we return an `Err(MalformedMatchArm)` from `is_useful`). I don't think this is that big of a deal, because in both cases this is malformed code and there should eventually be a `MalformedMatchArm` diagnostic or similar. But perhaps we should change things so that if any arm fails the type check we skip the entire diagnostic? That would at least make these two cases behave in the same way. @flodiebold 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 freeto join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
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.
I enjoy using
vec::with_capacity, so it'd be nice to have the same function for ~strs.