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

CFE fails to notice record field name differences when performing subtype matches #55802

Closed
stereotype441 opened this issue May 21, 2024 · 1 comment
Assignees
Labels
area-front-end Use area-front-end for front end / CFE / kernel format related issues. cfe-dysfunctionalities Issues for the CFE not behaving as intended cfe-unreported-error Issues for missing compile-time errors in CFE.

Comments

@stereotype441
Copy link
Member

The following code is accepted by the CFE but rejected by the analyzer:

({T foo}) f<T>(T x) => (foo: x);

g(Object y) {
  if (y is ({double bar})) {
    y = f(1..h()); // (1)
    print(y);
  }
}

extension on double {
  void h() {
    print('$this.h() called');
  }
}

main() {
  g((bar: 0.5));
}

The analyzer's error message (at the line marked (1)) is:

The method 'h' isn't defined for the type 'int'. Try correcting the name to the name of an existing method, or defining a method named 'h'.

The analyzer is correct to reject the code.

What's going wrong on the CFE side is that when performing type inference on the call f(1..h()), the context is ({double bar}), and the CFE is called upon to try to match that to the return type of f, which is ({T foo}). Due to a bug in TypeConstraintGatherer._isNullabilityAwareSubtypeMatch, the CFE fails to notice that the names foo and bar disagree, so it infers a type of double for T. As a result, the argument of f (1..h()) gets type inferred with a context of double, so 1 gets interpreted as 1.0, and so the CFE thinks the extension method h is available.

I'll send out a fix for review shortly.

@stereotype441 stereotype441 added area-front-end Use area-front-end for front end / CFE / kernel format related issues. cfe-unreported-error Issues for missing compile-time errors in CFE. cfe-dysfunctionalities Issues for the CFE not behaving as intended labels May 21, 2024
@stereotype441 stereotype441 self-assigned this May 21, 2024
@stereotype441
Copy link
Member Author

Fix is out for review: https://dart-review.googlesource.com/c/sdk/+/367462

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area-front-end Use area-front-end for front end / CFE / kernel format related issues. cfe-dysfunctionalities Issues for the CFE not behaving as intended cfe-unreported-error Issues for missing compile-time errors in CFE.
Projects
None yet
Development

No branches or pull requests

1 participant