Make `flutter build` / `dart compile exe` / ... tell VM's global analysis pass which operating system we compile for

[mkustermann]

We should make all tooling - including flutter build dart compile exe - pass the target operating system to VM's global analysis. Also in g3 blaze rules.

[a-siva]

Is P1 the right priority for this issue? According to our new issue triage policy we would need updates on a weekly basis on all P1 issues.

[sstrickl]

Currently I'm working on an initial implementation in CL 274386. The current version there:

• introduces a command line flag for providing the target operating system to kernel generators
• adds a transformer to the AOT global transformations in pkg:vm that runs prior to unreachable code analysis and replaces gets of certain static final Platform fields with a constant value based on the target operating system

Originally the transformer was a standalone transformer, but I am currently reworking it to be a subclass of the ConstantsTransformer from the front end, so that it can then propagate the Platform constants according to how the ConstantsTransformer and its components, like the ConstantEvaluator, would treat them. In addition, I'm going to roll the unreachable code analysis transformer into this transformer so that the number of passes we're doing on the code is not increased.

I'm also working on replacing the detection of the Platform fields we want to replace with an annotation instead of doing a semi-hackish check for the enclosing library and file URL. Actually, I'll be adding two annotations:

• One for _operatingSystem and _pathSeparator which we look for to decide which static gets to replace with constants.
• One for methods and variable initializations that denote code that, if given a target operating system, should evaluate to a constant value (and should cause an error to be thrown at compile time if it does not).

Thus, the fields that use _operatingSystem like isAndroid, isFuchsia, etc. will have the second annotation, and user code that also abstracts over these getters or the operatingSystem/pathSeparator field values can likewise be annotated if it's expected to return a constant result for a known operating system.

Once the above pieces are in, I plan to put that CL up for review, and then look at large Flutter applications to see what sorts of refinements on the above strategy we will need to cover other opportunities for tree shaking.

[sstrickl]

All the above pieces are now in the CL, so just need to fix the CL description and do a pre-review pass to make sure there's no glaring issues and I'll put that up for review. Once that's in the review queue, I'll start the process of seeing if any refinements to the base implementation of this work are needed.

[mkustermann]

@sstrickl Can this bug be closed?

[sstrickl]

Yes, now it's just refinement, but everything listed here is done so doing so.