Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Parsing import allows "as" before "if" #56641

Open
munificent opened this issue Sep 3, 2024 · 2 comments
Open

Parsing import allows "as" before "if" #56641

munificent opened this issue Sep 3, 2024 · 2 comments
Assignees
Labels
area-fe-analyzer-shared Assigned by engineers; when triaging, prefer either area-front-end or area-analyzer. cfe-parser Parser issues in the CFE fe-analyzer-shared-parser Issues with the shared parser's handling of correct code type-bug Incorrect behavior (everything from a crash to more subtle misbehavior)

Comments

@munificent
Copy link
Member

munificent commented Sep 3, 2024

I don't get any errors in:

import 'foo.dart' as foo if (dart.library.html) 'other_foo.dart';

main() {
  print(foo.bar);
}

This runs if I run it with dart temp.dart and analyzes without error using dart analyze. The grammar for imports is:

⟨importSpecification⟩ ::=
import ⟨configurableUri⟩ (deferred? as ⟨typeIdentifier⟩)? ⟨combinator⟩*
‘;’

That means that the as clause, if present, must be after any if configurations.

I ran into this issue because dart format will always output the as clause after the if configurations, which then trips up its sanity check because it made a non-whitespace change by reordering those clauses.

I did find at least two libraries in the wild (dotlottie_loader-0.0.4/lib/src/loaders/network_loader.dart and sentry-8.3.0/lib/src/environment/environment_variables.dart) that has the clauses in the wrong order, so fixing this is both nominally and actually a breaking change (though likely a very minor one given the rarity of conditional imports).

@munificent munificent added fe-analyzer-shared-parser Issues with the shared parser's handling of correct code cfe-parser Parser issues in the CFE labels Sep 3, 2024
@dart-github-bot
Copy link
Collaborator

Summary: The Dart parser incorrectly allows the as clause to appear before the if clause in import statements, leading to unexpected behavior and potential breaking changes when using dart format. This issue arises because the grammar specifies that the as clause must follow any if configurations.

@dart-github-bot dart-github-bot added area-language Dart language related items (some items might be better tracked at github.com/dart-lang/language). triage-automation See https://github.com/dart-lang/ecosystem/tree/main/pkgs/sdk_triage_bot. type-bug Incorrect behavior (everything from a crash to more subtle misbehavior) labels Sep 3, 2024
@lrhn lrhn added area-fe-analyzer-shared Assigned by engineers; when triaging, prefer either area-front-end or area-analyzer. and removed area-language Dart language related items (some items might be better tracked at github.com/dart-lang/language). triage-automation See https://github.com/dart-lang/ecosystem/tree/main/pkgs/sdk_triage_bot. labels Sep 4, 2024
@munificent
Copy link
Member Author

I ran into this issue because dart format will always output the as clause after the if configurations, which then trips up its sanity check because it made a non-whitespace change by reordering those clauses.

I have a PR out for the formatter (dart-lang/dart_style#1555) which will simply preserve whatever order the input code had the clauses in, so the formatter isn't blocked on having this fix. It will gracefully handle imports whether they are spec compliant or not.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area-fe-analyzer-shared Assigned by engineers; when triaging, prefer either area-front-end or area-analyzer. cfe-parser Parser issues in the CFE fe-analyzer-shared-parser Issues with the shared parser's handling of correct code type-bug Incorrect behavior (everything from a crash to more subtle misbehavior)
Projects
None yet
Development

No branches or pull requests

4 participants