Generate deprecations list from the language repo #2253
Conversation
This updates the Deprecation enum to be generated from spec/deprecations.yaml in the language repo.
jathak
force-pushed
the
generated-deprecations
branch
from
67226b6
to
22e3741
Compare
CHANGELOG.md
Outdated
| `Deprecation.duplicateVarFlags` to make it consistent with the | ||
| `duplicate-var-flags` name used on the command line and in the JS API. |
.gitignore
Outdated
| *.pb*.dart | ||
| *.g.dart |
There was a problem hiding this comment.
This is a little odd, since the async files are also generated but don't have a marked filename. Might it be simpler to just explicitly ignore the deprecation.dart file?
There was a problem hiding this comment.
I was thinking in terms of having something to distinguish generated code that's not checked in, and I'd seen the .g.dart pattern with some other Dart projects, but maybe since deprecation.dart is the only file like that here (other than the protobuf files, which use their own extension) just ignoring it explicitly is better.
| import 'package:dart_style/dart_style.dart'; | ||
| import 'package:yaml/yaml.dart'; | ||
|
|
||
| void updateDeprecationFile(File yamlFile) { |
There was a problem hiding this comment.
It would be more consistent with other libraries to define the task here directly.
|
|
||
| void updateDeprecationFile(File yamlFile) { | ||
| var yamlText = yamlFile.readAsStringSync(); | ||
| var data = loadYaml(yamlText) as Map; |
There was a problem hiding this comment.
Pass in the source URL here as well.
Checking this in makes it possible to checkout and use the source without needing grinder, and there's not really any case where we would need to add or update a dependency in the language repo without having some sort of corresponding PR in this repo.
|
Based on offline discussions, I decided to change this to check in the generated deprecations file since there shouldn't really be a case where we need to update the deprecations list in the language repo without making some sort of corresponding change to the compiler, and checking it in makes it easier to use the compiler code internally without also needing to pull in the language repo and grinder. |
test/double_check_test.dart
Outdated
| fail('${deprecations.dartPath} is out-of-date.\n' | ||
| 'Run `dart run grinder` to update it.'); | ||
| } | ||
| }, testOn: "!windows"); |
There was a problem hiding this comment.
Probably worth including the above comment here as well, or moving this condition onto a group that contains both up-to-date tests.
tool/grind/deprecation.dart.template
Outdated
There was a problem hiding this comment.
Rather than having a template and a source file, could it make sense to just allow the source file to be edited directly and only have a specific subsection of it get (re)generated?
There was a problem hiding this comment.
Yeah, good point. Now that the deprecations file is checked in, there's no reason not to just generate a section of it. Fixed.
| @@ -21,7 +20,7 @@ Future<void> doubleCheckBeforeRelease() async { | |||
| fail("GITHUB_REF $ref is different than pubspec version ${pkg.version}."); | |||
| } | |||
|
|
|||
| if (listEquals(pkg.version.preRelease, ["dev"])) { | |||
| if (const ListEquality<Object?>().equals(pkg.version.preRelease, ["dev"])) { | |||
There was a problem hiding this comment.
Why doesn't listEquals() work here anymore?
There was a problem hiding this comment.
It's defined within lib/src/utils.dart, which depends on the Sass AST, so we can't import it here
See sass/sass#3872.
This updates the
Deprecationenum to be generated fromspec/deprecations.yamlin the language repo.