| Code-Review | +1 |
LGTM provided that the change related to Object? are moved to a separate CL.
return typeProvider.objectQuestionType;This change seems unrelated. Should it (and the correlated changes) be moved to its own CL?
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
This change seems unrelated. Should it (and the correlated changes) be moved to its own CL?
I accidentally rebased this CL, but forgot to rebase its parent.
This file change is from master.
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
bool get isSynthetic;I'm uncomfortable about introducing a deprecated getter that overrides a non-deprecated one, because this means that:
(a) Clients that call `isSynthetic` through the base class won't see the deprecation message, and
(b) There is nothing we can remove in a future breaking change release of the analyzer that corresponds to this deprecation.
Would it be possible, instead, to replace *all* instances of `isSynthetic` with more explicit flags, so that the deprecation can be applied to the base class? (And thus the `isSynthetic` flag can be removed entirely in a future breaking change release of the analyzer)
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
bool get isSynthetic;I'm uncomfortable about introducing a deprecated getter that overrides a non-deprecated one, because this means that:
(a) Clients that call `isSynthetic` through the base class won't see the deprecation message, and
(b) There is nothing we can remove in a future breaking change release of the analyzer that corresponds to this deprecation.Would it be possible, instead, to replace *all* instances of `isSynthetic` with more explicit flags, so that the deprecation can be applied to the base class? (And thus the `isSynthetic` flag can be removed entirely in a future breaking change release of the analyzer)
Yes, eventually `Element.isSynthetic` will be deprecated and removed.
This CL introduces new flags and migrates what is possible.
This partial migration serves as reducing amount of work, and to display what and how is migrated.
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Code-Review | +1 |
lgtm assuming the commit message is updated to indicate that the plan is to eventually deprecate and remove `Element.isSynthetic`.
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Code-Review | +1 |
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Commit-Queue | +2 |
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
DeCo. Use origin flags for constructors.
Introduce explicit origin flags on ConstructorElement and its fragment
(isOriginDeclaration, isOriginImplicitDefault, isOriginMixinApplication)
and deprecate isSynthetic in favor of these. Define isSynthetic as the
inverse of isOriginDeclaration to preserve the legacy meaning while
encouraging clients to use the more precise origin predicates.
Eventually `Element.isSynthetic` also will be deprecated and removed.
This CL is a step toward this goal, migrating what is possible with new
flags.
Update analyzer internals to rely on the new origin flags when checking
for non-factory generative constructors, building synthetic constructors
for mixin applications, and walking constructor chains in index/search
logic. Only constructors with an origin declaration are now treated as
declarations, and nonSynthetic is defined in terms of origin
declarations rather than synthetic-ness. Add corresponding origin
descriptors to the manifest enum and bump AnalysisDriver.DATA_VERSION.
Adjust analysis server refactorings and fixes to distinguish implicit
default constructors from other synthetic constructors. Code paths that
previously checked isSynthetic for default constructors now check
isOriginImplicitDefault, and mixin-application traversal uses
isOriginMixinApplication.
Overall, this change removes the overloaded semantics of isSynthetic,
makes constructor provenance explicit, and prepares the element model
for future DeCo and primary-constructor scenarios without relying on
brittle synthetic heuristics.
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |