Allow using named consts in pattern types #136284
Conversation
rustbot
added
S-waiting-on-review
|
Some changes occurred in src/tools/clippy cc @rust-lang/clippy HIR ty lowering was modified cc @fmease |
oli-obk
force-pushed
the
push-zsxuwnzmonnl
branch
from
62ac839 to
5337e0d
Compare
|
☔ The latest upstream changes (presumably #136454) made this pull request unmergeable. Please resolve the merge conflicts. |
oli-obk
force-pushed
the
push-zsxuwnzmonnl
branch
from
5337e0d to
611b966
Compare
| span: self.lower_span(pattern.span), | ||
| }); | ||
| hir::ConstArgKind::Anon(ac) | ||
| }; |
There was a problem hiding this comment.
this is pretty much mgce? 🤔 as in, this also adds consts in the type system.
Can you delegate this to lower_const_arg or whatever instead?
There was a problem hiding this comment.
Yes, but at that point I should modify the ast, and I'd prefer to do that in other PRs
| let hir::TyKind::Pat(ty, p) = tcx.parent_hir_node(pat.hir_id).expect_ty().kind else { | ||
| bug!() | ||
| }; | ||
| assert_eq!(p.hir_id, pat.hir_id); |
There was a problem hiding this comment.
why do we use the same HirId for the TyKind::Pat and its pattern?
There was a problem hiding this comment.
We don't. This assertion is just x == child(parent(x)) and mostly a leftover from getting the PR to this state
| let hir::TyKind::Pat(ty, p) = tcx.parent_hir_node(pat.hir_id).expect_ty().kind else { | ||
| bug!() | ||
| }; | ||
| assert_eq!(p.hir_id, pat.hir_id); |
| let start = start.map(expr_to_const); | ||
| let end = end.map(expr_to_const); | ||
| let start = start.map(|expr| self.lower_const_arg(expr, FeedConstTy::No)); | ||
| let end = end.map(|expr| self.lower_const_arg(expr, FeedConstTy::No)); |
There was a problem hiding this comment.
do we currently not evaluate the range during typeck?
given that we don't feed its types and computing the type relies on typeck?
| @@ -0,0 +1,72 @@ | |||
| error[E0391]: cycle detected when evaluating type-level constant | |||
There was a problem hiding this comment.
i guess the answer is: we do evaluate them during typeck and just get cycle errors for now :3
This required a refactoring first: I had to stop using
hir::Patinhir::TyKind::Patand instead create a separateTyPatthat hasConstArgfor range ends instead ofPatExpr. Within the type system we should be usingConstArgfor all constants, as otherwise we'd be maintaining two separate const systems that could diverge. The big advantage of this PR is that we now inherit all the rules from const generics and don't have a separate system. While this makes things harder for users (const generic rules wrt what is allowed in those consts), it also means we don't accidentally allow some things like referring to assoc consts or doing math on generic consts.