The MockCanvas API was originally used to test the output of rendering methods to match them against a reference set of "MockData" structures. This API has been superseded by just using a DisplayListBuilder to record reference operations and then to compare the resulting DisplayList objects.
This PR deletes the last remaining uses of MockCanvas as well as the mechanism itself.
Based on the (internal) discussion around converging on using the official Dart style guide, the design discussion https://flutter.dev/go/use-dart-style-in-flutter-engine, and with the exception of the code that gets published under `dart:ui` (as that is user-facing, and we'd like to evolve the code style in conjunction with the framework), we're going to be (gradually) adopting the Dart style guide in `flutter/engine`.
For now, we:
- Remove `always_specify_types` (except for `lib/ui`, i.e. `dart:ui`)
- Re-enable `type_annotate_public_apis` (which is now relevant since the above is disabled)
- Announce our _intent_ to re-format and apply the Dart formatter (which we'll land in the near future)
---
I also took the opportunity to specify more about our style guide use in general, mostly to make it easier to understand our conventions, and also call out known problem areas (notably, our over-use of `shared_ptr` and `auto` in some cases). I am happy to split those up, but it was easier to make the markdown changes at once.
I also took @cbracken and folks advice and clarified directly that explicit types in Dart are _not_ bad (with examples).
`engine_dev_setup` moved to markdown
*Replace this paragraph with a description of what this PR is changing or adding, and why. Consider including before/after screenshots.*
*List which issues are fixed by this PR. You must list at least one issue.*
*If you had to change anything in the [flutter/tests] repo, include a link to the migration guide as per the [breaking change policy].*
[C++, Objective-C, Java style guides]: https://github.com/flutter/engine/blob/main/CONTRIBUTING.md#style
Reverts: flutter/engine#52859
Initiated by: zanderso
Reason for reverting: This sort of change *is* in scope for a discussion at the Dash forum.
Original PR Author: matanlurey
Reviewed By: {cbracken, gaaclarke, johnmccutchan}
This change reverts the following previous change:
Based on the (internal) discussion around converging on using the official Dart style guide, with the exception of the code that gets published under `dart:ui`, as that is user-facing, and we'd like to evolve the code style in conjunction with the framework.
I also took the opportunity to specify more about our style guide use in general, mostly to make it easier to understand our conventions, and also call out known problem areas (notably, our over-use of `shared_ptr` and `auto` in some cases). I am happy to split those up, but it was easier to make the markdown changes at once.
I also took @cbracken and folks advice and clarified directly that explicit types in Dart are _not_ bad (with examples).
Based on the (internal) discussion around converging on using the official Dart style guide, with the exception of the code that gets published under `dart:ui`, as that is user-facing, and we'd like to evolve the code style in conjunction with the framework.
I also took the opportunity to specify more about our style guide use in general, mostly to make it easier to understand our conventions, and also call out known problem areas (notably, our over-use of `shared_ptr` and `auto` in some cases). I am happy to split those up, but it was easier to make the markdown changes at once.
I also took @cbracken and folks advice and clarified directly that explicit types in Dart are _not_ bad (with examples).
This avoids the awkward capitalisation 'E.g.' but more importantly
triggers a build with the latest recipe update, which includes Windows
UWP build products.
The engine build bots and engine development team now rely solely on
Xcode 9 to build the engine. The iOS 11 SDK is required (though we build
with deployment target of iOS 8) for several features such as safe area
inset support.
As we anyway always recommend to set the target_os to android.
Also if you happen to not set the target_os to android it messes up the licenses script output.
* Removed 'pub get' from the instructions
According to Hixie, 'pub get' is abstracted into flutter packages upgrade, and so there shouldn't be a need to run pub get directly.
* Removed pub get lines entirely.
