Add unimplemented error for first-class built-ins

[romdotdog]

Fixes #2202. Another candidate for this error could be functions with DecoratorFlags.LAZY, but it seems that none exist.

• I've read the contributing guidelines
• I've added my name and email to the NOTICE file

[dcodeIO]

The underlying cause is quite similar to what happens when trying to pass a class by value. On this background, a perhaps more precise error describing what's going on under the hood could be AS234, "Expression does not compile to a value at runtime". Wdyt?

[romdotdog]

I chose the unimplemented error because it may be possible to implement first-class "proxy" functions if anyone may need such a thing, i.e.

function proxy(i: u16): u8 { // generated by the compiler
  return u8(i);
}

function converter<I, R>(f: (i: I) => R, i: I): R {
  return f(i);
}

converter<u16, u8>(proxy, 32767);

That isn't to say that it will be implemented.

The difference between unimplemented! and todo! is that while todo! conveys an intent of implementing the functionality later and the message is “not yet implemented”, unimplemented! makes no such claims. Its message is “not implemented”. Also some IDEs will mark todo!s.

[dcodeIO]

My assumption would be that we'd eventually implement such wrappers, yeah. Basically just wrap the builtin's instruction in a function so it can be represented with a value. That would be a case for "todo" as of the quoted paragraph, though, while the idea above is rather to just use the more descriptive message of what's going on. Not feeling strongly about which one, though, mostly just my immediate thoughts. I guess ideally we'd just implement wrappers :)

[romdotdog]

That would be a case for "todo" as of the quoted paragraph, though

todo! is a "subset" of unimplemented! so an unimplemented! can be implemented later. If you want to be specific, we can add a new TODO: {0} diagnostic.

I guess ideally we'd just implement wrappers :)

Triaging and a roadmap would help, I think. My objective for this PR and others is to fix all the crashes that I've posted as issues, at least as provisional errors, so that my AS fuzzer can catch more complex and elusive crashes that are not shadowed by trivial and common ones.

[dcodeIO]

Sounds like a good plan. I'm OK with adding the suggested error :)

[romdotdog]

Sounds like a good plan. I'm OK with adding the suggested error :)

To be consistent, adding the suggested error would be, in my opinion, enough of a change to belong in a separate PR which would involve auditing all DiagnosticCode.Not_implemented_0 errors, and would require one who is capable of deciding what will be and could do without implementation—which would probably not be me 😅. My proposition is to leave this diagnostic as DiagnosticCode.Not_implemented_0 and create the new error in a separate PR along with the aforementioned audits.

[dcodeIO]

Thanks! Would agree that it doesn't seem pressing to add a TODO kind error just yet :)