// trackWidgetCreation is in TargetFlags.
"trackWidgetCreation=$trackWidgetCreation",
// includeUnsupportedPlatformLibraryStubs is in TargetFlags.
"includeUnsupportedPlatformLibraryStubs="
"$includeUnsupportedPlatformLibraryStubs",I don't understand the two comments here. If this information is important could you elaborate them a little more?
/// This is used to transforming the libraries, but not for instance```suggestion
/// This is used to transform the libraries, but not for instance
```
bool isModularCompatibleWith(Target other) => true;Do we really want this default implementation? Wouldn't this be better left unimplemented to force subclasses to verify the compatibility of their targets?
I don't see an override implementation in DevCompilerTarget in this CL. Would we really want it inheriting this default behavior?
void updateModularCompatibilityAs(Target other) {}Same here. Should this be abstract as well?
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Commit-Queue | +1 |
// trackWidgetCreation is in TargetFlags.
"trackWidgetCreation=$trackWidgetCreation",
// includeUnsupportedPlatformLibraryStubs is in TargetFlags.
"includeUnsupportedPlatformLibraryStubs="
"$includeUnsupportedPlatformLibraryStubs",I don't understand the two comments here. If this information is important could you elaborate them a little more?
These are "tags" used to verify that we can reuse the previous incremental state. The "trackWidgetCreation" part is old, I added "includeUnsupportedPlatformLibraryStubs" (although technically not necessary to fix the issue at hand) and I thought it best to also add where they came from so I added these comments trying to tell the reader that it is used in `TargetFlags` created previously as
```
TargetFlags targetFlags = new TargetFlags(
trackWidgetCreation: trackWidgetCreation,
includeUnsupportedPlatformLibraryStubs:
includeUnsupportedPlatformLibraryStubs,
);
```
These could probably be moved into the `isModularCompatibleWith` commented on below, but that would be more of a refactor than a fix I think, and thus - to me - belongs in a different CL.
/// This is used to transforming the libraries, but not for instance```suggestion
/// This is used to transform the libraries, but not for instance
```
Done
Do we really want this default implementation? Wouldn't this be better left unimplemented to force subclasses to verify the compatibility of their targets?
I don't see an override implementation in DevCompilerTarget in this CL. Would we really want it inheriting this default behavior?
Well.
Before there was no check. Adding the check will therefore be a no-op for the Targets when this defaults to `true` (and doing nothing in the update version). That makes sense to me.
As mentioned above I agree that a refactor could move at least some of the tags into this method instead of having it as tags. To me that belongs in another CL though.
Same here. Should this be abstract as well?
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Code-Review | +1 |
bool isModularCompatibleWith(Target other) => true;Maybe `hasModularCompatibilityWith` or `isModularlyCompatibleWith`.
bool isModularCompatibleWith(Target other) => true;
void updateModularCompatibilityAs(Target other) {}
}Add documentation for these.
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Commit-Queue | +1 |
Maybe `hasModularCompatibilityWith` or `isModularlyCompatibleWith`.
Done
bool isModularCompatibleWith(Target other) => true;
void updateModularCompatibilityAs(Target other) {}
}Jens JohansenAdd documentation for these.
Done
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Code-Review | +1 |
Thanks for the extra explanations.
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Reapply "[kernel/cfe/etc] Split outline transformation into performOutlineTransformations and performOutlineComponentOperations"
This reverts commit 264098c85fa326bcc5c88cd4ccd7628980a58c14.
Currently outline transformations aren't run via the incremental
compiler which causes problems in
https://dart-review.googlesource.com/c/sdk/+/491702 which fixes it by
calling the current transformation in the incremental compiler. This
calls it twice though (because it's run again in
`frontend_server/lib/compute_kernel.dart`, but removing it there doesn't
work because a filtering is done which doesn't apply through the
incremental compiler.
This CL splits up the outline transformation stage into a call that can
actually transform the libraries and one that can do the filtering,
which should fix the issue.
Original CL was reverted because it caused errors in google3. The
original CL is in patchset 1. The error has been reproduced and
recreated in a test added in patchset 2. The fix is in patchset 3.
The dwds failure @
https://github.com/dart-lang/webdev/actions/runs/24516059718/job/71660245069
has been verified as fixed as well.
The problem was this:
Previously outline transformations were not run by the incremental
compiler, but only outside. When it was moved to the incremental
compiler it had on old - outdated - `target` which for the ddc/dart2js
summary target would hold a list of source files that it was initially
created with, not the ones currently being compiled. This meant that the
transformation step that removed "unrelated" libraries actually removed
the newly compiled libraries instead. It could cause one of two issues:
1) Empty output: With no overlap between the combined output of the
compile and the sources of the first compile (i.e. the ones in the
outdated `target`) all libraries were filtered out. If a later
compile was given this as a summary input the compile could fail with
a file not found error because the given summary - which should
contain the missing library didn't.
2) Non-empty output: With an overlap between the combined output of the
compile and the sources of the first compile only the overlap would
be included. In practise this would mean that the output would be a
(potentially partial) copy of the first compile. If then a later
compile was given both the summary from the first compile and the
output with the copy it would throw when loading because it got the
same library from two different summaries.
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |