This is an archive of the discontinued LLVM Phabricator instance.

[clang] [concepts] Correctly(?) handle placeholder types in ExprRequirements.
ClosedPublic

Authored by Quuxplusone on Jan 29 2022, 9:05 PM.

Details

Summary

PR52905 was originally papered over in a different way, but I believe this is the actually proper fix, or at least closer to it. We need to detect placeholder types as close to the front-end as possible, and cause them to fail constraints, rather than letting them persist into later stages.

Fixes https://llvm.org/PR52905
Fixes https://llvm.org/PR52909
Fixes https://llvm.org/PR53075

Diff Detail

Event Timeline

Quuxplusone requested review of this revision.Jan 29 2022, 9:05 PM
Quuxplusone created this revision.
Quuxplusone added inline comments.
clang/lib/AST/ASTContext.cpp
3375

Btw, I strongly suspect that the presence of placeholder type UnknownAny all the way down in here is a bug (@rjmccall, thoughts?). But I found that the test suite didn't pass without this exception, and I'm not terribly interested in tracking down why; I don't have any idea what UnknownAny is, myself.

It's a type that the debugger integration uses when it doesn't know the type of a symbol. If it's a data symbol, you make a VarDecl with UnknownAny type; if it's a function symbol, you make a FunctionDecl with UnknownAny. In either case, if the user fails to cast it, it gets diagnosed as an error.

I can't think of any reason why we'd want to build a reference to UnknownAny type; generally it's bad if the type "escapes" into subordinate positions. Probably we should be diagnosing something before we try to propagate the UnknownAny type.

clang/lib/AST/ASTContext.cpp
3375

It's a type that the debugger integration uses when it doesn't know the type of a symbol. If it's a data symbol, you make a VarDecl with UnknownAny type; if it's a function symbol, you make a FunctionDecl with UnknownAny. In either case, if the user fails to cast it, it gets diagnosed as an error.

I can't think of any reason why we'd want to build a reference to UnknownAny type; generally it's bad if the type "escapes" into subordinate positions. Probably we should be diagnosing something before we try to propagate the UnknownAny type.

I've found https://github.com/llvm/llvm-project/issues/32247 on the same topic, and updated it with a comment and my own test case.

Poke CI (clang-format failed).

Gentle ping! (@ChuanqiXu @urnathan perhaps?)
I'm hoping to land D118552 followed by a re-land of D117603, this week and ideally tomorrow. :)

urnathan added inline comments.Jan 31 2022, 10:28 AM
clang/lib/AST/ASTContext.cpp
3373

sorry to be picky, but
(a) why the {...} on the single body stmt? Isn't that against style?
(b) are we sure the if's condition is sufficiently const so that it goes away when the assert is inactive? if's containing a single assert make me nervous.

clang/lib/AST/ASTContext.cpp
3373

No problem, I'll move the whole thing into the assert, which will fix both points. Ditto line 3414.

(I did it this way originally only for historical reasons, because I had been putting extra code (printf/abort) into the if to find out what placeholder types I needed to grandfather in.)

Update assert style.

Quuxplusone marked an inline comment as done.Jan 31 2022, 11:07 AM

Update another single-line if too.

urnathan accepted this revision.Jan 31 2022, 11:38 AM

thanks!

This revision is now accepted and ready to land.Jan 31 2022, 11:38 AM
This revision was landed with ongoing or failed builds.Feb 1 2022, 12:16 PM
This revision was automatically updated to reflect the committed changes.