-
Notifications
You must be signed in to change notification settings - Fork 406
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
IR check failed in presence of noncomputable #1785
Comments
minimized: noncomputable def char (x : α) : Bool := true
def bug (x : α) : Bool := not (char x)
-- IR check failed at 'bug._rarg', error: unknown declaration 'char' |
@digama0 Thanks for minimizing the problem. The minimized version makes it clear what the issue is. @alexjbest We will improve the error message and make it clear code generation failed because |
Thanks, and sorry for being so bad at minimizing! All modifications I tried gave the correct error message, so I assumed this problem was somehow more complicated than it appears to actually be :) |
Here's another example of the same issue, discovered on zulip. (Original by @kbuzzard, minimized by @digama0.)
|
Here's another one. |
Yet another example is here. (And indeed a new-user papercut :) ) |
Here's another. The user initially asked completely the wrong question, led astray by |
Currently, `ll_infer_type` is responsible for telling the user about `noncomputable` when a definition depends on one without executable code. However, this is imperfect because type inference does not check every subexpression. This leads to errors later on that users find to be hard to interpret. Now, `Lean.IR.checkDecls` has a friendlier error message when it encounters constants without compiled definitions, suggesting to consider using `noncomputable`. While this function is an internal IR consistency check, it is also reasonable to have it give an informative error message in this particular case. The suggestion to use `noncomputable` is limited to just unknown constants. Some alternatives would be to either (1) create another checker just for missing constants, (2) change `ll_infer_type` to always visit every subexpression no matter if they are necessary for inferring the type, or (3) investigate whether `tests/lean/run/1785.lean` is due to a deeper issue. Closes leanprover#1785
Here's another. "This is giving weird errors, I'm not sure what's the problem here." |
Here is another rather small example: axiom Later : Type → Type
axiom gfix {α : Type} (f : Later α → α) : Later α
def gfix2 {α : Type} (f : Later α → α) : α := f (gfix f) It certainly triggers a related error message (4.10-rc2):
It took me a bit, but of course the error is that |
Two people caught out by this in one day today: here's the other one. |
Currently, `ll_infer_type` is responsible for telling the user about `noncomputable` when a definition depends on one without executable code. However, this is imperfect because type inference does not check every subexpression. This leads to errors later on that users find to be hard to interpret. Now, `Lean.IR.checkDecls` has a friendlier error message when it encounters constants without compiled definitions, suggesting to consider using `noncomputable`. While this function is an internal IR consistency check, it is also reasonable to have it give an informative error message in this particular case. The suggestion to use `noncomputable` is limited to just unknown constants. Some alternatives would be to either (1) create another checker just for missing constants, (2) change `ll_infer_type` to always visit every subexpression no matter if they are necessary for inferring the type, or (3) investigate whether `tests/lean/run/1785.lean` is due to a deeper issue. Closes leanprover#1785
Currently, `ll_infer_type` is responsible for telling the user about `noncomputable` when a definition depends on one without executable code. However, this is imperfect because type inference does not check every subexpression. This leads to errors later on that users find to be hard to interpret. Now, `Lean.IR.checkDecls` has a friendlier error message when it encounters constants without compiled definitions, suggesting to consider using `noncomputable`. While this function is an internal IR consistency check, it is also reasonable to have it give an informative error message in this particular case. The suggestion to use `noncomputable` is limited to just unknown constants. Some alternatives would be to either (1) create another checker just for missing constants, (2) change `ll_infer_type` to always visit every subexpression no matter if they are necessary for inferring the type, or (3) investigate whether `tests/lean/run/1785.lean` is due to a deeper issue. Closes #1785
Currently, `ll_infer_type` is responsible for telling the user about `noncomputable` when a definition depends on one without executable code. However, this is imperfect because type inference does not check every subexpression. This leads to errors later on that users find to be hard to interpret. Now, `Lean.IR.checkDecls` has a friendlier error message when it encounters constants without compiled definitions, suggesting to consider using `noncomputable`. While this function is an internal IR consistency check, it is also reasonable to have it give an informative error message in this particular case. The suggestion to use `noncomputable` is limited to just unknown constants. Some alternatives would be to either (1) create another checker just for missing constants, (2) change `ll_infer_type` to always visit every subexpression no matter if they are necessary for inferring the type, or (3) investigate whether `tests/lean/run/1785.lean` is due to a deeper issue. Closes leanprover#1785
Prerequisites
Description
Code generator sometimes doesn't correctly flag noncomputaility
Steps to Reproduce
In this (somewhat) minimal example I believe
def bug
should be marked noncomputable, but theIR
generator doesn't pick up on this for some reason.Expected behavior: message saying
def bug
must be marked noncomputableActual behavior: IR check failed
Reproduces how often: 100% but seems to need a fairly complicated example
Versions
nightly-10-25
The text was updated successfully, but these errors were encountered: