tra added a subscriber: rsmith.
tra added a comment.
It's an interesting idea and it may be needed to handle wider range of
implicitly-HD functions.
However it's likely to have interesting consequences, not all of them
desirable.
It may be worth considering hiding the new behavior behind a flag, make it
optional at first, give it some soak time and only then make it the default.
Summoning @rsmith for the big picture input.
One side effect of this change is that we'll probably stop producing
diagnostics for the code that is known to be wrong, but happens to be unused.
E.g.
__host__ __device__ static void hd() {
no_such_type_t t;
}
We obviously can never compile this function on either side of the compilation
and clang currently does diagnose it on both sides.
However, if all diagnostics in HD functions are postponed until codegen, this
error will go unreported.
What if I have a syntax error in a HD function? I'd still want it to be
diagnosed.
It's going to be interesting to see how it affects parsing subsequent code.
E.g https://godbolt.org/z/1vfPcc -- clang complains about the error in
`innocent` due to an error in `hd`. If all diags issues in `hd` are postponed
and the user only sees `error: function definition is not allowed here`, it
will be rather confusing, because the `innocent` itself is perfectly fine.
Also, this patch may need more eyes on it. I'm sure there are more corner cases
we may need to think about.
E.g. how would it affect SFINAE? Will it allow some things to succeed where
they would've failed previously? If so, is it always the right thing to do?
We'll certainly want to have more tests that cover the errors that we still
want to be produced.
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D84364/new/
https://reviews.llvm.org/D84364
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
