-
Notifications
You must be signed in to change notification settings - Fork 12.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
add more tests for type-instantiation pat::<T>
syntax in patterns
#22546
Comments
Nominating. (Removing support for this is arguably P-backcompat-lang. It is also arguably "just a bug", i.e. "polish at best".) I suspect it is not too hard for someone familiar with the parser to fix, though. I am mainly nominating it to answer the question: Is it actually buggy syntax or not? |
Now that patterns fully participate in type inference, that can come in useful like in this example: let Foo::<uint>(a, b) = Default::default(); |
@brson points out that we might nonetheless need further testing of the cases here; @alexcrichton relayed an anecdote that these used to be ignored, but clearly are not today (at least not in all cases). Tagging as E-needstest, removing nomination without milestone. |
Fixes #22757 Fixes #22972 Fixes #23044 Fixes #23151 Fixes #23597 Fixes #23656 Fixes #23929 It also fixes some other corner cases in range patterns, like incorrect spans or not accepting global paths after `...`. It passes `make check` but needs some additional tests (then it will fix #22546 as well), I'll write them today or tomorrow.
Fixes rust-lang#22757 Fixes rust-lang#22972 Fixes rust-lang#23044 Fixes rust-lang#23151 Fixes rust-lang#23597 Fixes rust-lang#23656 Fixes rust-lang#23929 It also fixes some other corner cases in range patterns, like incorrect spans or not accepting global paths after `...`. It passes `make check` but needs some additional tests (then it will fix rust-lang#22546 as well), I'll write them today or tomorrow.
Reopened per #23930 (comment) |
pat::<T>
syntax supported in patternspat::<T>
syntax in patterns
Skimming the followup PR #24033, it seems like it adds some tests here. @brson @alexcrichton should we close this ticket due to that? Or are there specific cases you can think of that you wanted tested? (@petrochenkov was actively working in the parser code here, so I am willing to assume that he's knowledgable of how much code coverage he is getting here.) |
triage: ping, @pnkfelix 's question still stands |
I'm pretty sure this can be closed. |
Fixed years ago. |
Spawned off of issue #22544
Consider this code:
The above compiles and runs in the playpen today.
We probably shouldn't accept the use of
Foo::<T>
in a pattern, right?(Is there some context where we would want that, i.e. as some sort of feedback into type-inference? I dunno, I still remain to be convinced that type ascription in patterns is generally useful.)
The text was updated successfully, but these errors were encountered: