Handle assert with custom message#4581
Conversation
The built-in macro "assert" has a second form, with a custom message used on assertion failure. This patch allows the second form to be compiled. gcc/rust/ChangeLog: * expand/rust-macro-builtins-log-debug.cc (MacroBuiltin::assert_handler): Forward any custom message on to the built-in panic macro. gcc/testsuite/ChangeLog: * rust/compile/assert_missing_panic.rs: Add usage of the second form of assert. Signed-off-by: Owen Avery <powerboat9.gamer@gmail.com>
|
Can you add a testcase for something of this form? // 2. begin <= end
assert!(
begin <= end,
"begin <= end ({} <= {}) when slicing `{}`{}",
begin,
end,
s_trunc,
ellipsis
);this is one of the hindrances I ran into with |
I could, but the part of a test I added should already cover this (and does seem to prevent this bit of core from erroring). Note that the formatting itself isn't tested, just the compilation down to a |
| // TODO: insert stringify invocation | ||
| (void) 0; |
There was a problem hiding this comment.
Maybe let's put a warning here? Not a full-on sorry at, but a warning saying this is a stub implementation of assert
There was a problem hiding this comment.
Also please open an issue for this, I think it shouldn't be too hard to implement even by a newcomer contributor
There was a problem hiding this comment.
I'm thinking we'd run into issues making sure that stringify! actually calls the built-in stringify!, in all cases. Also, I'll open an issue, but I'm not sure I should insert a sorry warning -- it's a preexisting issue that only effects the message an assert! emits upon failure. If you do still want me to put it in, I will.
There was a problem hiding this comment.
I think it would be nice to have a rust_warning_at but not a rust_sorry as yeah it's not super important and very specific to assert! as you said
CohenArthur
left a comment
CohenArthur
left a comment
There was a problem hiding this comment.
I think we should merge this now as I need it for core and see how we can improve it in the future
|
Opened #4635 |
2 participants
Fixes #4578