Replies: 4 comments
-
FYI this is because we use system() with ivlpp piped to ivl and this only returns the ivl return value and ignores any value returned by ivlpp. |
Beta Was this translation helpful? Give feedback.
-
I fixed this by emitting a special comment that the compiler can read to get the error information from the preprocessor and fail instead of just processing what it was provided. This is done after parsing since the comment with failing information is the last line in the file. For standalone operation it now prints an appropriate error message. |
Beta Was this translation helpful? Give feedback.
-
It would be better to do that check in pform_parse(), then it would also be done for load_module(). |
Beta Was this translation helpful? Give feedback.
-
Okay, I will look at that change. |
Beta Was this translation helpful? Give feedback.
-
In the elsif_test we have cases where the macro_identifier is omitted and we just ignore the construct when it seems like this should be flagged as a compilation error. This ignore behaviour is independent of the check type. @steveicarus, @martinwhitaker or any others; do you object to me making this an error for both devel and V11? I would split the test into the failing and passing components. It looks like ivlpp is marking these as errors and returning an error code, but that is not causing a failure in the actual compile so it looks like all errors in ivlpp are being ignored.
Beta Was this translation helpful? Give feedback.
All reactions