bjoernager/rust
bjoernager/rust
1
Fork 0
Code Issues Pull requests Activity

Auto merge of #125863 - fmease:rej-CVarArgs-in-parse_ty_for_where_clause, r=compiler-errors

Browse source 
Reject `CVarArgs` in `parse_ty_for_where_clause`

Fixes #125847. This regressed in #77035 where the `parse_ty` inside `parse_ty_where_predicate` was replaced with the at the time new `parse_ty_for_where_clause` which incorrectly stated it would permit CVarArgs (maybe a copy/paste error).

r? parser
This commit is contained in:
bors 2024-06-01 21:13:52 +00:00
commit f67a1acc04
4 changed files with 26 additions and 4 deletions
Download patch file Download diff file Expand all files Collapse all files

5
compiler/rustc_parse/src/parser/ty.rs
View file

@ -194,7 +194,7 @@ impl<'a> Parser<'a> {
pub(super) fn parse_ty_for_where_clause(&mut self) -> PResult<'a, P<Ty>> {
self.parse_ty_common(
AllowPlus::Yes,
AllowCVariadic::Yes,
AllowCVariadic::No,
RecoverQPath::Yes,
RecoverReturnSign::OnlyFatArrow,
None,
@ -344,8 +344,9 @@ impl<'a> Parser<'a> {
match allow_c_variadic {
AllowCVariadic::Yes => TyKind::CVarArgs,
AllowCVariadic::No => {
// FIXME(Centril): Should we just allow `...` syntactically
// FIXME(c_variadic): Should we just allow `...` syntactically
// anywhere in a type and use semantic restrictions instead?
// NOTE: This may regress certain MBE calls if done incorrectly.
let guar = self
.dcx()
.emit_err(NestedCVariadicType { span: lo.to(self.prev_token.span) });