[PATCH] Add a 'no-asserts' requirement option to LIT.

Reid Kleckner rnk at google.com
Tue Feb 3 13:39:52 PST 2015

On Tue, Feb 3, 2015 at 1:17 PM, Mehdi Amini <mehdi.amini at apple.com> wrote:

> On Feb 3, 2015, at 12:32 PM, David Blaikie <dblaikie at gmail.com> wrote:
> On Tue, Feb 3, 2015 at 12:19 PM, Mehdi Amini <mehdi.amini at apple.com>
> wrote:
>> Hi David,
>> On Feb 3, 2015, at 11:15 AM, David Blaikie <dblaikie at gmail.com> wrote:
>> On Tue, Feb 3, 2015 at 11:03 AM, Owen Anderson <resistor at mac.com> wrote:
>>> Hi chandlerc, joker.eph,
>>> This is useful when checking diagnostics and annotations that are only
>>> enabled in asserts mode.
>> Not sure I quite follow - "REQUIRES: Asserts" would be used for any test
>> case that's verifying a failure that's only enabled in asserts mode.
>> "REQUIRES: no-asserts" would be for testing the absence of that same
>> failure in a no-asserts build?
>> That seems like a thing I wouldn't want to test for. The idea is that the
>> program has undefined behavior if it would assert but you're in a
>> non-asserts build. That's not a thing to test for - there's no
>> specific/guaranteed behavior in that case.
>> To provide you with more context: I am expecting some optional metadata
>> from the front-end, but in case they are malformed for any reason I want to
>> be bullet proof and handle this case gracefully (i.e. undefined behavior /
>> crashing is not acceptable). So I’d like my assert build to verify the
>> validity of the metadata but my release build to ignore it and set a
>> suitable default value that I know allows recovery most of the time.
>> I can’t add a test to check if we recover correctly from an invalid
>> metadata without this.
>> This is valid in general for the category of assertions we put to enforce
>> some invariant/properties that are important for optimization purposes but
>> does not prevent us from generating a correct code if they are broken.
>> Does it make sense?
> Not sure how everyone else feels, but I'd rather classify something like
> that that has well-defined recovery semantics, as something other than
> 'validity’.
> To be sure I understand correctly: do you mean an assertions is not
> welcome on the normal path if we have a well-defined recovery path?

So far, that's been our policy.

Owen, can you use the new backend diagnostic machinery that Quentin added?
Is that flexible enough to allow suppressing the error in released builds
and getting the correct developer behavior of emitting an error? Or do you
really want to crash with a stack trace during development?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20150203/5133d36e/attachment.html>

More information about the llvm-commits mailing list