dusklang / dusk

The Dusk Programming Language
Other
0 stars 0 forks source link

Infinite loop in TIR generation #122

Open zachwolfe opened 2 years ago

zachwolfe commented 2 years ago

Code like this causes TIR generation to go on forever. It seems to be triggered by the combination of using the the function name as its own return type, and having a member ref in the body of the function.

fn foo(): foo {
    0.member // The base expression and field name can be anything; doesn't matter
}
zachwolfe commented 2 years ago

Update: this is now "fixed" with recent changes to TIR solving. That is, compilation at least exits with an error message instead of never exiting at all. But I will leave this issue open for two reasons:

  1. In this case I think it would clearly be better to not consider a function's own name when resolving names in its return type. In other words, the foo declref in the return type would fail to find any declarations (unless there are other overloads of that name in the outer scope). In theory this would also break the dependency cycle, freeing up the typechecker to progress to diagnosing the undefined foo and 0.member declrefs.
  2. There are also cases where dependency cycles are detected erroneously (or more likely, generated erroneously and detected correctly), and those need to be fixed. I'll try to come up with a minimal-ish reproducible sample soon.