[PATCH] D154290: [Clang] Implement P2741R3 - user-generated static_assert messages

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman 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}}
+
----------------
cor3ntin wrote:
> 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.
> 
Okay, I can see the logic there. My concern was mostly around whether we can display the message in all cases or not. e.g., can the constexpr evaluation fail such that the data returned is effectively garbage and thus we display gibberish to the user?

e.g., https://godbolt.org/z/Wx74as4Gh

(This one doesn't show gibberish, but... we didn't exactly find a message either.)


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D154290/new/

https://reviews.llvm.org/D154290