cor3ntin marked 3 inline comments as done.
cor3ntin added inline comments.
================
Comment at: clang/test/SemaCXX/static-assert-cxx26.cpp:110-111
+
+static_assert(false, Leaks{}); //expected-error {{the message in a static
assertion must be produced by a constant expression}} \
+ // expected-error {{static assertion failed: ub}}
+
----------------
aaron.ballman wrote:
> This diagnostic combination is a little bit jarring to me. The first one is
> telling the user that the message is incorrect and the second one tells the
> user precisely what that message was, so they're almost contradictory in some
> ways. However, I'm not certain if others think this is jarring as well.
>
> If we think that, perhaps this sort of circumstance should just say the
> static assertion failed without the message part, even though we could figure
> out something as the message in this particular instance.
I'm mostly neutral on other comment but i disagree with that.
If we can produce a useful message, we should definitely use it otherwise it
just hides useful information from the user - presumably information tried (and
failed) to make pretty.
because data() is a pointer there are a few cases where we can form a
diagnostic despite errors:
issue in the destructor (we have a full message), as above, and size()
returning something greater than what is reachable from data (in which case we
still get a full message).
For either of these scenarios we want to produce a message, because we can, and
we also want to inform the user about the fact that the ast may be leaking
memory or that something is wrong with size.
Other cases include recoverable errors from evaluating the message, data or
size(), for example https://godbolt.org/z/aj4aKMMqn
Note that all of these were discussed at length in WG21, and well, whether a
message is produced or not is QOI, so whatever we do there is conforming, i
just think we should provide as useful messages as we can.
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D154290/new/
https://reviews.llvm.org/D154290
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
