Allow assertion to stringify its arguments similar to C's preprocessor, add utility assertion methods

[LouisJenkinsCS]

I think some new helper assertion methods would be nice...

proc assertLess(a, b) {
   assert(a < b, a + "<" + b);
}

proc assertEqual(a,b) {
   assert(a == b, a + "==" + b);
}

Currently when an assertion fails without a specified error message, the default error message is unhelpful: error: assert failed. It does not state why it failed nor even what the condition was. This leads to the user having to jump to the problematic line number and perform their own printf-debugging.

It would great if it could stringify its arguments similar to C's preprocessor, where if the user calls something like assert(ptr != nil), they get to see assert failed: 'ptr != nil'.

[bradcray]

I think we already have this. See the second assert() signature in the Assert module. (I can't hyperlink to it directly because our current chpldoc setup only supports links to the first of a series of overloads). If you git grep the modules/ directory, you should see uses that pass strings and/or additional arguments after the test condition.

[LouisJenkinsCS]

What about a way to stringify the passed expression?

[bradcray]

Are the normal ways of stringifying things not working for you? (cast-to-string, append strings, string.format)

[LouisJenkinsCS]

I could manually stringify the expression myself, but it could be useful if it was done for the user. I.E: writing assert(ptr != nil, "ptr != nil") is rather redundant. Plus you can do this in C using the preprocessor quite easily.

[bradcray]

Oh sorry, I didn't understand what you meant by "passed expression" in your previous comment. Chapel doesn't have a way to stringify code at present, nor are there current plans to provide such a capability. If that's something you want to advocate for, I'd suggest splitting it off into a new issue with a proposal for what it would look like and (ideally) how it would work.