Open devoncarew opened 6 years ago
Devon (most of these final fields) are RO atttributes in an IDL file. We don't construct these they are browser objects. Should these fields be prefaced with @external or something else to signal that these are special final fields?
So, the implementation of the fields are native? Or, the values are injected from outside of Dart?
I'm not sure what we could respect to ignore the analysis issue, but it sounds like we just need to indicate to the analyzer that these are indeed not real issues.
You could try // ignore: final_not_initialized
at the declaration sites.
But, DDC would likely still fail the compile; hmm...
Isn't final String readOnlyThing;
the same as external String get readOnlyThing;
in this regard?
👍 that would be a good solution here
Isn't
final String readOnlyThing;
the same asexternal String get readOnlyThing;
in this regard?
yeah, that would be better from my perspective.
dart:html is shared between DDC and dart2js. Not sure if DDC and/or dart2js have anything hardcoded to treat final fields on @Native
specially (compared to external get
). If they do, it should be fixable though.
Looked into this more. For native types in DDC, external get
should be equivalent to a final field. I found an example of DDC using external get
in another library (dart:_native_typed_data).
Not sure about dart2js. I couldn't find any examples of them using an external
getter in their SDK implementation. Maybe @rakudrama or @sigmundch knows? We could also try changing the dart:html generator to produce external
and see if it works :)
Note that this may not longer be a blocker for #33837 (but likely still nice to have the generated code be free of analysis warnings and errors).
I have to dig deeper to confirm, but @johnniwinther was recently navigating into fields/external getters in the context of js-interop so he might be able to confirm more quickly
Currently, dart2js special-cases fields in native classes. Long term these should be external getters but I suspect that it's not a simple fix to change dart2js.
They emit with analysis warnings currently; those warnings will likely change to being reported as errors. When that happens, DDC will fail with compile errors when processing those libraries (and this will cause problems when we go to build the SDK).
A workaround short term is to adjust the
//pkg/dev_compiler/tool/build_sdk.dart
script to pass in the--unsafe-force-compile
flag. That would however allow other errors to creep in over time, so would only be viable as a short term solution.@terrylucas @jmesserly
This is related to https://github.com/dart-lang/sdk/issues/33837.