syntax: add debug_assert! that is only active with --cfg debug.

[huonw]

No description provided.

[huonw]

@thestinger has pointed out that this should probably abort not fail!, because otherwise the behaviour of the code changes between debug and release configurations. (E.g. someone could accidentally rely on/use debug_assert!'s behaviour. E.g. checking that an SQL statement only has SELECT; bam, attack vector when the assertion disappears for a release build.)

Unless someone has better argument for not changing to abort, I'll do that.

[thestinger]

@huonw: your example would still be relevant if it aborted, you could add a check you depend on and it would be still be gone with optimizations

You can catch a failure at a task boundary though, so it means you could accidentally be silencing your debugging asserts, and it doesn't ever make sense to do that.

[huonw]

@thestinger debug_assert failing would still pass a #[should_fail] test, but an abort wouldn't.

[thestinger]

@huonw: I'll r+ if you switch it to printing out an error and then calling abort()

[graydon]

I don't understand how fail vs. abort figures into it. Doesn't it get compiled-out in all cases when you don't pass --cfg debug?

[bblum]

Can we get a test_assert! counterpart to this that is only executes the contained code when cfg(test)?

[thestinger]

@graydon: the issue is that it should be clearly for debugging, and if it fails you can accidentally catch the failure at a task boundary and miss it

[emberian]

@huonw mind updating this?

[huonw]

Closing this for now to remove from bors' queue; I'll try to get back to it soon (maybe, hopefully).

[brson]

I currently disagree that this should abort.
I can sort of understand the thinking here that the semantics change a little when not using --cfg debug, but task boundaries are specifically for recovering from unexpected failures.