Closed MichaelRawson closed 3 months ago
Could we somehow propagate the lineNumber()
even with the USER_ERROR
s?
Right, this is what we lose - we can just add a field to UserErrorException
, but I'm not sure I see the value. If e.g. the user supplies assumption
s or mixes HOL and theories, it doesn't really matter where exactly.
The value is in being able to say "You are doing something stupid >AROUND HERE<." which is more informative than "You are doing something stupid in this 5 MB file of yours."
Not saying the current way is the best solution, but could we have this PR without 2. and think about it a bit more?
Ah, I see - some of the USER_ERROR
s are more like a SEMANTIC_ERROR
. OK, let's add a field to UserErrorException
, it should not be so hard.
Done.
See #542. Fix some of the crashes reported there.
AtomicSort::create
, notTerm::create
. I think it was probably fine data-wise, but we fail an assertion.USER_ERRORS
and wrap them asPARSE_ERRORS
with a line number. I'm not sure how useful this is and it means we can't distinguish between "we parsed this but can't do anything with it" (e.g. HOL + theories), and "syntax error". Don't do that.PARSE_ERRORS
should beUSER_ERRORS
.