Skip to content
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

Late crash when using inline value as reg argument #866

Open
vbgl opened this issue Jul 13, 2024 · 4 comments
Open

Late crash when using inline value as reg argument #866

vbgl opened this issue Jul 13, 2024 · 4 comments
Labels

Comments

@vbgl
Copy link
Member

vbgl commented Jul 13, 2024

Compiling the following program triggers an unfathomable internal error:

fn f(reg u32 x) -> reg u32 {
  return x;
}

export
fn main() -> reg u32 {
  inline u32 z;
  z = 42;
  reg u32 r;
  r = f(z);
  return r;
}

"get_pvar.jazz", line 10 (2-11):
internal compilation error in function main:
stack allocation: get_Pvar: variable expected
Please report

Reported by @cos-imo.

@vbgl vbgl added the bug label Jul 13, 2024
@eponier
Copy link
Contributor

eponier commented Jul 29, 2024

Indeed, stack alloc assumes that every function argument is a variable, and badly fails otherwise. During typing, we reject most programs where it is not the case (r = f(42) is rejected, for instance), but with inline it is possible to pass typing and reach stack alloc with an argument that is not a variable.

I don't know what the proper fix is. Having stack alloc emit a nicer error is easy to do, while detecting this problem during typing seems hard, so I'd fix stack alloc. What do you think?

@vbgl
Copy link
Member Author

vbgl commented Jul 29, 2024

I think that a checker after type-checking and before compilation should be able to properly address this kind of errors.

@eponier
Copy link
Contributor

eponier commented Jul 29, 2024

In general, do you think that we should remove everything not strictly related to typing from pretyping and put it in that pass?

@vbgl
Copy link
Member Author

vbgl commented Jul 29, 2024

Precisely. That would also solve issues like #727.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants