You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Reflectable currently generates code that uses the parameter type dynamic in a number of generated function literals, even though they are stored in the reflectable "database" and will be used in a type specific manner: A function literal that enables reflective invocation of foo on an instance of Foo may have the form (o) => o.foo, but it could be (Foo o) => o.foo.
Using explicit types will be much more friendly to static analysis, and in particular to tree-shaking, because it is then known at compile-time that this function literal body won't access any other members named foo than the one in Foo, which may allow some other members named foo to be eliminated from the compiled program.
The text was updated successfully, but these errors were encountered:
Is there a way to tell the analyzer to generally ignore the issue for files generated by reflectable? Otherwise it seems that you just can't use implicit-casts: false and reflectable at the same time without being overwhelmed by analysis errors. As somebody new to dart/flutter it's disappointing to be forced to choose between convenient json serialization and increased type safety.
I don't see any failures with the tests of reflectable (https://github.com/dart-lang/test_reflectable), and it has had implicit-casts: false for a long time. It might be because of the transition to code with null safety. It would be helpful to know more about which kinds of errors you are seeing.
The ability to change the severity of some compile-time errors is going away: dart-lang/sdk#42977. I believe that usage has to do with code that is not yet generated (so it's actually the library which is missing, until code generation has taken place), but it wouldn't in general be a safe bet to ignore an error.
It might be helpful to let the analyzer skip the generated files with this in your analysis_options.yaml:
Reflectable currently generates code that uses the parameter type
dynamic
in a number of generated function literals, even though they are stored in the reflectable "database" and will be used in a type specific manner: A function literal that enables reflective invocation offoo
on an instance ofFoo
may have the form(o) => o.foo
, but it could be(Foo o) => o.foo
.Using explicit types will be much more friendly to static analysis, and in particular to tree-shaking, because it is then known at compile-time that this function literal body won't access any other members named
foo
than the one inFoo
, which may allow some other members namedfoo
to be eliminated from the compiled program.The text was updated successfully, but these errors were encountered: