top-down type inference, implements rfc 149

[metagn]

refs nim-lang/RFCs#149, closes nim-lang/RFCs#36

Name copied from Haxe manual

Proof of concept for adding top-down type inference on top of the validating style inference used by fitNode. (I think this is called "bidirectional typing"). Each expression can opt-in to this and define their own behaviors.

Todo

• assignments
• let/var/const type annotations
• blocks/statement lists
• if/case/try branches
• if/while conditions
• set literal elements
• array literal elements
• seq literal elements (if @ is overloaded, only activates if you call system.`@`)
• tuple elements
• object constructors
• table constructor
• proc body inference based on return type
• string literal (cstrings)
• nil literal
• generalized overload specification
• surface level range types
• document
• better refactor for expectedType?
• please review style use etc, don't know the best style to use in many cases here

Notes

Performance should be considered. The biggest performance pitfalls I can think of are the passing of the expectedType parameter everywhere (which isn't that bad because it's basically just an int) and the expectedType != nil checks. Theoretically it should be negligible.

Keeping this as compatible as possible is best, but if needed, it can be made into a compile option (--topDownInference:on) or experimental switch.

fitNode already has errors, so new errors/enforcing expectedType are probably not needed.

Type conversions are left alone.

Current incompatibilities:

• a sequtils test breaks (AFAICT some kind of Illegal symbol reuse in template with method call syntax #14844 is unlocked with single use of MCS, so probably not my fault), sequtils is changed to make the test work

Potential extensions outside this PR, can go in new RFC after merge

• new magic like infer(x: untyped, T: type): T or x as T as opposed to T(x) to ensure compile-time only, costless conversion

• lambda/do signature inference. not because it would be hard but because I don't want to bother

• Most useful potential application: Routine arguments. I am not equipped to start this yet but I can think of some ways to do it. All of them could have bad performance.

  • 1. Query all overloads; filter based on param count, named arguments etc; then get the common type of each argument and infer based on those types. Disadvantages are these common types will not give too much information, and varargs/untyped would completely disable arguments where they could be.
  • 2. Gradually type arguments in a row (except untyped arguments) until only 1 overload remains. For example if there are overloads that are like (A, X, Y), (B, X, Y), (C, X, Y), you sem the first argument (not accounting for named arguments) and get A, then only the overload of (A, X, Y) remains, so you know to use X and Y for the remaining arguments. This has the advantage of working with method-style signatures much better. I think this would also be the easiest to do efficiently.
  • 3. Combination of the two. For example if you have (A, X, T1) and (B, X, T2), you can't infer the first argument, you can infer the second argument because the common types are X, but 2 overloads are still remaining, so you can't infer the third argument. This is stronger than 2 (2 cannot infer X) but slower because of the common type calculation.

  I do not see myself doing this any time soon so the implementation details don't have to be up to me.

[Araq]

Awesome and bounty-worthy!

[Varriount]

Just out of curiosity (I have practically no experience working with the compiler), why use an extra parameter over adding a new field to PContext?

[metagn]

If it could be refactored to that, I would do it, but I am not too confident about it. It would be really hard to keep track of (you would need to think about it for every sem call). For example sometimes you expect bool for if conditions then another type for their branches. Sometimes you are supposed to leave the type empty, like in statement lists until the last statement.

I guess also for now I want the behavior of having nil by default instead of propagating the type. For example if there was a expectType(typ): sem() wrapper, you would have to call expectType(nil): sem() to opt expressions out of it.

[metagn]

Forgot to comment this is ready for review, it just might be a little painful to do so.

[github-actions]

Thanks for your hard work on this PR!
The lines below are statistics of the Nim compiler built from 0014b9c

Hint: mm: orc; threads: on; opt: speed; options: -d:release
163798 lines; 13.113s; 841.578MiB peakmem