Support full type inference in the analyzer

[bwilkerson]

This list might be incomplete. To help avoid missing cases we should test all the cases in pkg/front_end/testcases/inference and pkg/front_end/testcases/inference_new.

• Restrict behavior of callable classes - analyzer implementation Restrict behavior of callable classes - analyzer implementation #32156
• Make it an error if a class includes in its super-interfaces the same generic interface twice with different type parameters Make it an error if a class includes in its super-interfaces the same generic interface twice with different type parameters #32148
• Implement mixin application inference behind the super-mixins flag Implement mixin application inference behind the super-mixins flag - analyzer #32146
• Top-level type inference: report errors when analyzer and front_end types would differ, such as
  • Unrestricted top level inference
  • Circularity detected
• (scheglov) Infer Object arguments instead of Null - Proposal: use the principal type for inferring argument types of closures #31546
• (scheglov) Fix type inference of closures using ‘=>’ syntax: Inconsistent type inference behavior of block-type vs expression-type closures #29606 (corresponding front end bug was Type inference of function expressions leads to unfortunate cast failures #31436)
• (scheglov) Improve for-in statement inference: Type inference for for-in statements is limited #31440
• (scheglov) Improve compound assignment inference (cded101)
• (scheglov) Use “bool” as the downward inference context for assert conditions (ae4cbb5), while/do loops (213c208), and logical operators (3b6f276)
• (scheglov) Use the type of the switch expression as the context for case expressions (b94fdce)
• (scheglov) Correctly infer list/map types when outside a method body (a7ab70e)
• (scheglov) Fix inference of methods returning “void” outside of a method body (c4ecf09)
• (scheglov) Type inference should always infer the return type of operator []= as void Type inference should always infer the return type of operator []= as void #31779
• Analyzer does not warn on function calls on Object Analyzer does not warn on function calls on Object #31509
• analyzer does not report an error on incorrect code in strong mode analyzer does not report an error on incorrect code in strong mode #31858

[devoncarew]

@stereotype441 can you please vet this and make sure this tracks the work we want to do?

[stereotype441]

SGTM as a starting point. We may decide to skip some of the subtasks if their impact is minimal, but I think for now we should plan on doing all of them.

[stereotype441]

I'm going to start working on this now. If others would like to help, please let me know so that we can divide up sub-tasks.

[devoncarew]

/cc @vsmenon and @leafpetersen for fyi

[vsmenon]

@stereotype441 @devoncarew

Re "Make it an error if a class includes in its super-interfaces the same generic interface twice with different type parameters":

This is an internal try at it on top of dev 16: cl/184080428

That's not for landing, just for an internal global test run. It appears to catch the right errors.

[stereotype441]

@vsmenon thanks! We'll use your CL as a starting point.

[bwilkerson]

@stereotype441 I'm guessing that this issue is now obsolete and can be closed. Can you close it if that's true?

[stereotype441]

No, it's not ready to close yet. #32156 is unfinished.

[stereotype441]

All remaining unfinished subtasks are now being tracked in #32395.