[pigeon] Use a shared generation step for platform_tests/#2823
Conversation
|
Adding overrides as this is a dev-only change, the scripts just don't know about pigeon's test structure. (Eventually we should fix that; it wouldn't be that big a deal to special-case it in the tooling.) |
stuartmorgan-g
left a comment
There was a problem hiding this comment.
This seemed like a reasonably sized cut-point for this prep work, but let me know if you want me to split anything out.
| objects = { | ||
|
|
||
| /* Begin PBXBuildFile section */ | ||
| 0D02163D27BC7B48009BD76F /* nullable_returns.gen.m in Sources */ = {isa = PBXBuildFile; fileRef = 0D02163C27BC7B48009BD76F /* nullable_returns.gen.m */; }; |
There was a problem hiding this comment.
These project changes are all mechanical renames due to switching over to camel-casing for ObjC generation.
| #import <XCTest/XCTest.h> | ||
| #import "EchoMessenger.h" | ||
| #import "all_datatypes.gen.h" | ||
| #import "AllDatatypes.gen.h" |
There was a problem hiding this comment.
The ObjC test changes are all:
- import renames for CamelCase files, or
- removal of prefixes.
| } | ||
|
|
||
| // A map of pigeons/ files to the languages that they can't yet be generated | ||
| // for due to limitations of that generator. |
There was a problem hiding this comment.
This is a behavioral change; we used to generate an opted-in list of files for each language, whereas now we generate everything that doesn't actively fail. That means we're generating files that we aren't using yet, but
- that should be harmless
- it can be useful for manual generator change checking
- it'll be one less thing to change when backfilling missing platform tests
- [pigeon] Reorganize test pigeons flutter#115168 will render the difference moot anyway
|
Hm, I'm not sure what's going on with Windows; it passes for me locally now. I suspect we're missing some log output, as we've seen with other Windows LUCI hangs. |
|
Still hanging :/ |
|
With verbose build logging it looks suspiciously like it's hanging in the package resolution failure stage, which generally means a resolution conflict. But I didn't change anything about the Dart dependencies, so now I'm even more confused. |
…differences" This reverts commit ddfbf8b.
|
It turns out I forgot to update the header includes in the unit tests, so it may be that this was actually just the tests failing to compile (and passing for me locally because I apparently forgot to clean the output directory, so had the old files?). Why even just failing to compile would hang the CI, I have no idea; I'll file an issue with a repro case if that's really all it was. |
| - (void)testEcho { | ||
| ACDataWithEnum *data = [[ACDataWithEnum alloc] init]; | ||
| data.state = ACEnumStateError; | ||
| DataWithEnum *data = [[DataWithEnum alloc] init]; |
There was a problem hiding this comment.
How come we lost all the prefixes to class names?
There was a problem hiding this comment.
From the PR description:
ObjC prefixes are no longer used, since collisions were eliminated from the input pigeons during the Swift generator bringup.
gaaclarke
left a comment
There was a problem hiding this comment.
This looks good with a few recommendations:
- Fill in some of the docstrings, nothing exhaustive needed, just a simple sentence that explains what public procedures are doing
- I'd keep the class prefix on objc generation. Since there is no namespaces in objc its easy to get collisions and we don't want people coming up with goofy names just to avoid collisions.
| final String iosObjCBase = | ||
| p.join(baseDir, 'platform_tests', 'ios_unit_tests'); | ||
|
|
||
| for (final String input in inputs) { |
There was a problem hiding this comment.
It worth trying parallelizing this: https://pub.dev/packages/pmap The input size is small and the execution time is large.
There was a problem hiding this comment.
I forgot to move your existing TODO about this; I've added it. (But also, flutter/flutter#115168 will largely make this much less of an issue.)
| return process; | ||
| } | ||
|
|
||
| Future<int> runProcess(String command, List<String> arguments, |
|
|
||
| import 'process_utils.dart'; | ||
|
|
||
| Future<int> runFlutterCommand( |
There was a problem hiding this comment.
docstrings would help here too
| return specialCases[inputName] ?? _snakeToPascalCase(inputName); | ||
| } | ||
|
|
||
| Future<int> generatePigeons({required String baseDir}) async { |
There was a problem hiding this comment.
Thanks, I completely forgot to go back and add them! Done everywhere.
stuartmorgan-g
left a comment
There was a problem hiding this comment.
I'd keep the class prefix on objc generation. Since there is no namespaces in objc its easy to get collisions and we don't want people coming up with goofy names just to avoid collisions.
We already need different names to make things work in Swift (and maybe Kotlin?). And it'll be moot when we do flutter/flutter#115168 anyway.
| final String iosObjCBase = | ||
| p.join(baseDir, 'platform_tests', 'ios_unit_tests'); | ||
|
|
||
| for (final String input in inputs) { |
There was a problem hiding this comment.
I forgot to move your existing TODO about this; I've added it. (But also, flutter/flutter#115168 will largely make this much less of an issue.)
| return specialCases[inputName] ?? _snakeToPascalCase(inputName); | ||
| } | ||
|
|
||
| Future<int> generatePigeons({required String baseDir}) async { |
There was a problem hiding this comment.
Thanks, I completely forgot to go back and add them! Done everywhere.
In preparation for adding integration tests to
test_pluginandalternate_language_test_plugin, which will involve multiple different tests running code based on the same generated output, this restructures the Pigeon test scripts to do generation of the*_test_pluginoutput files in a single shared step at the start of the test run, rather than having it be part of each test. This has several advantages:pigeon, so doing it# filestimes instead of# filesx# languagestimes is faster.It does mean that running just individual tests that don't use the test plugins are currently slower; if that ends up being a common enough case before we switch to checking in generated code, we can potentially add logic to make this conditional. (Since that will be easier once everything is Dart, and my hope is that we move to checking in relatively soon, I didn't invest effort in that here.)
Opportunistic refactoring/cleanup done as part of this PR:
runPigeonto a separate file (unchanged).runProcessto a separate file, and adjusted it slightly so that code that was currently usingProcess.startdirectly can sharerunProcess instead.flutter_plugin_tools, where they have been useful abstractions.).gen.*instead of some using that and some using.g.*.Prep for flutter/flutter#111505
Part of flutter/flutter#115169
Part of flutter/flutter#85068
Pre-launch Checklist
dart format.)[shared_preferences]pubspec.yamlwith an appropriate new version according to the pub versioning philosophy, or this PR is exempt from version changes.CHANGELOG.mdto add a description of the change, following repository CHANGELOG style.///).