-
Notifications
You must be signed in to change notification settings - Fork 1.7k
[Class modifiers] Angular compiler implementation #50740
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
/cc grouma would this be on your team? |
/cc @grouma for real this time :) |
@itsjustkevin @leafpetersen - do we actually expect this to affect internal frameworks? More generally, would it make more sense to track internal framework efforts in the internal bug tracker instead? |
+1. From a quick glance I don't think there is much work to do on our end. It's possible we need to modify the compiler to improve error handling when the new features are used improperly. We also can take advantage of some of the new features, e.g. sealed types. cc @leonsenft for additional thoughts. |
Agreed. It seems like most of the errors produced by these features would be raised as errors in user authored code before Angular-generated code. |
We should still have some way of tracking this here. @grouma are these already tracked through internal bugs? |
For historical context: we added this meta-issue after one feature we added turned out to break the angular compiler when it was used in code that angular consumed (perhaps extension methods?). The issue is intended to track validating that everything works as intended (or is documented as not working, don't use with angular). We have historically often opened an internal bug to track any actual work, but since there is no way to link internal bugs into external milestones/projects/etc, we added these issues as part of our release checklist. I'm fine with any way of tracking this, so long as we have "validate that angular works" on some checklist somewhere. |
I added this to the "Dart 3 stable" milestone. I agree with the sentiments above that I can't think of any way that a user could use Class Modifiers that would crash the Angular compiler, or that would result in UB or something. Any static errors that arise from mis-use of the modifiers should continue to be reported as normal. |
Internal tracking id: b/279910423 |
@grouma, just wondering, can we close this now? ('status: fixed') |
Yes this can be closed. |
Thanks! |
No description provided.
The text was updated successfully, but these errors were encountered: