aboutsummaryrefslogtreecommitdiff
path: root/gcc/tree-ssa-loop-prefetch.cc
diff options
context:
space:
mode:
authorJason Merrill <jason@redhat.com>2022-04-14 08:16:45 -0400
committerJason Merrill <jason@redhat.com>2022-04-14 14:51:49 -0400
commit74b2e20222cf4fb24b90561ddb6f0989738bb722 (patch)
tree4497f32f6a794c993200be3df9b3b86cc504e3a9 /gcc/tree-ssa-loop-prefetch.cc
parentd634c5d7c78c6ec0fa39d96984460475564519c8 (diff)
downloadgcc-74b2e20222cf4fb24b90561ddb6f0989738bb722.zip
gcc-74b2e20222cf4fb24b90561ddb6f0989738bb722.tar.gz
gcc-74b2e20222cf4fb24b90561ddb6f0989738bb722.tar.bz2
c++: lambda and the current instantiation [PR82980]
When a captured variable is type-dependent, we've expressed the type of the capture field and proxy with a decltype variant. But if the type is "the current instantiation", we need to be able to see that so that we can do lookup inside it just like we could with the captured variable itself. I also tried looking through lambda capture in cp_parser_postfix_dot_deref_expression, but this way seems cleaner. I plan to treat more types as deducible in stage 1. I considered also using this in do_auto_deduction, but think that would be wrong: [temp.dep.expr] says an id-expression is type-dependent if it is "associated by name lookup with a variable declared with a type that contains a placeholder type where the initializer is type-dependent". That doesn't clearly exclude deducing a dependent type from the initializer, but it seems like a barrier, and other implementations agree. PR c++/82980 gcc/cp/ChangeLog: * lambda.cc (type_deducible_expression_p): New. (lambda_capture_field_type): Check it. gcc/testsuite/ChangeLog: * g++.dg/cpp0x/lambda/lambda-current-inst1.C: New test.
Diffstat (limited to 'gcc/tree-ssa-loop-prefetch.cc')
0 files changed, 0 insertions, 0 deletions