Strong mode hotlist

[munificent]

This is a hotlist issue for the main stuff the people hacking on strong mode are focusing on right now:

Generic methods (@jmesserly)

• SDK needs to have generic method comments where appropriate
• comment syntax allows reifying a tighter type than VM supports, e.g. new List<num/*=T*/>() (Generic method prototype syntax doesn't map well to checked mode #25637)
• implement missing warnings/errors (Implement missing warnings for generic methods #25200)
• implement missing AST nodes, e.g. f<int> and o.m<int> (implement generic functions/methods in other AST nodes besides MethodInvocation #25175)
• declaration and use of generic function types, e.g. <T>(T) ->T (support declaration & use of generic function types #25179)
• should we allow invalid use of comment form? (Analyzer complains about error in comment #24985)

Consistent use of upwards/downwards inference

• Downwards inference on generic methods (downwards inference for generic methods #25477)
• Upwards inference on constructors (infer constructor type arguments from values #25220)
• Upwards inference for list/map literals (infer constructor type arguments from values #25220)
• Consider upwards inference for block bodied closure returns & implicit unions (Handle implicit future unions in downwards inference #25322)

Function parameter type and dynamic (top vs bottom)

Needs design.

• Top-level function type weirdness (Will need runtime check to cast to type (num) #24507)
• Instance method overrides -- warning? (support covariant parameter overrides #25578)

Closure / function parameter and return type inference (@leafpetersen)

• Non-arrow function return (open, easily closable, uninferred closure) (Remove UninferredClosure type dart-archive/dev_compiler#290)

Future / async typing

• Future<Future<T>> flattening
• flattening diverges (strong mode: future flattening diverges #25611)

Generics and variance

@vsm: try making DefaultEquality generic, revisit package:collection - do we need this?

• B <: A<bottom> (Support B <: A<bottom> #25604)
• Add flag for invariant generics?

Ground types and is/as

Needs design.

• is on type parameter? ("Runtime check on non-ground type T may throw StrongModeError" #24565)

Least upper bound

• is unsound & EfficientLength problem (fix strong mode LUB #25802)

Field overrides

• do we want a @virtual?
• Disallow for now? (shadowing fields with fields dart-archive/dev_compiler#52)

Error / warning quality

Should work on phrasing.

• Overhaul categorization
• Rephrase DDC wording
• Make errors actionable
• Separate out DDC errors unrelated to soundness

No dynamic

• No reified dynamic (Add --no-implicit-dynamic flag to strong mode #25573)
• Inferences fails / no static dynamic
• No dynamic helpers generated

Improve type promotion

Various improvements that would help user productivity:

• meta bug: improve type promotion in strong mode #25565

Other bugs to fix

• Type of (x) => null (Static type of "(x) => null" is computed as "(dynamic) => <bottom>" dart-archive/dev_compiler#47)
• F-bounded quantification (F bounded quantification bug #25530)
• Private methods incorrectly treated as overrides even in different libs (private methods are incorrectly overriding methods from a different library dart-archive/dev_compiler#366)
• assignment in setter (Error for using a lambda in a setter #25642)
• infer type from parameter default value (Strong mode should infer parameter types from default value expressions #25794)
• not checking inferred field initializer (Strong mode override inference not checked against initializer #25546)

[jmesserly]

I went through and updated this with current bug numbers (at this point, all Strong Mode bugs should be here, not in DDC repo). I tried to add open issues we were missing. Not sure if I captured all of them. I think we are going to want to trim this list down.

[jmesserly]

I'm going to close this now that we've gone through and triaged bugs. But we can reopen if needed