Skip to content
This repository has been archived by the owner on Sep 16, 2022. It is now read-only.

Allow mixing of deferred/non components #1558

Closed
matanlurey opened this issue Aug 9, 2018 · 3 comments
Closed

Allow mixing of deferred/non components #1558

matanlurey opened this issue Aug 9, 2018 · 3 comments

Comments

@matanlurey
Copy link
Contributor

Ran into this while debugging #1539.


If you use @deferred in a certain way (details pending), the following is emitted:

import '1539_nested_template_test.dart' deferred as deflib0;

class ViewNestedTemplateTest0 extends AppView<deflib0.NestedTemplateTest> { ... }

That is illegal in Dart, resulting in:

[error] The deferred type 'deflib0.NestedTemplateTest' can't be used in a declaration, cast or type test

This is based, I believe, on trying to re-use existing import statements. We should not be treating deferred libraries as something usable for types. This might be trivial to fix, it might not, but it makes the usability of @deferred fairly brittle :(

@matanlurey
Copy link
Contributor Author

@matanlurey matanlurey self-assigned this Aug 9, 2018
@matanlurey matanlurey changed the title View compiler references deferred libraries (illegally) Better errors when mixing deferred/non-deferred components Aug 9, 2018
@matanlurey matanlurey changed the title Better errors when mixing deferred/non-deferred components Better errors when mixing deferred/non components Aug 9, 2018
@matanlurey
Copy link
Contributor Author

After talking offline, we'll likely just fail instead of waiting for DDC/Dart2JS to fail.

@matanlurey matanlurey changed the title Better errors when mixing deferred/non components Allow mixing of deferred/non components Aug 10, 2018
@matanlurey
Copy link
Contributor Author

... so turns out, this actually was just sort of a bug in dart_emitter.dart.

It was fixable 🙌 ... but required refactoring dart_emitter.dart a tiny bit. Not a huge deal.

matanlurey added a commit that referenced this issue Aug 10, 2018
... components coming from the same library (i.e. import).

Mostly involved simplifying/refactoring the bit of `DartEmitter` that created a mapping of import prefixes to use. The old method tried to use one mapping for both deferred and non-deferred libraries; my new approach uses (the already created) separate mappings.

I put a bit of refactoring in to make the method(s) more understandable in the future, and a simple change to "path_util.dart" to compensate for how deferred modules are stored (importing themselves is possible).

Closes #1558.
Closes #1559.

PiperOrigin-RevId: 208234448
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

1 participant