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

Missed nullness pattern in migration #44217

Closed
johnniwinther opened this issue Nov 15, 2020 · 4 comments
Closed

Missed nullness pattern in migration #44217

johnniwinther opened this issue Nov 15, 2020 · 4 comments
Labels
area-analyzer Use area-analyzer for Dart analyzer issues, including the analysis server and code completion. type-enhancement A request for a change that isn't a bug

Comments

@johnniwinther
Copy link
Member

When the migration tries to migrate code like

class Class {
  Foo field;

  Bar toBar() {
    if (field == null) {
      throw 'Field is null';
    }
    return field as Bar;
  }
}

it proposes

class Class {
  Foo? field;

  Bar? toBar() {
    if (field == null) {
      throw 'Field is null';
    }
    return field as Bar?; // This should be `as Bar`.
  }
}

that is, failing to see that the cast must be to a non-nullable type.

@johnniwinther johnniwinther added type-enhancement A request for a change that isn't a bug pkg-migration labels Nov 15, 2020
@lrhn
Copy link
Member

lrhn commented Nov 15, 2020

Likely missed that because we don't do promotion of instance variables. It's not safe to assume that field has the same value in field as Bar as it had in field == null - a subclass could override field and return something new each time.
(Probably won't, but compilers can't rely on "probably").

Not saying that migration tools can't assume that the code is reasonable, though. It might make sense for the migration tool to assume that checks do promote field, and so field as Bar could assume that field is not null and not make it as Bar?.
(Not sure how easy that would be, though. It won't be able to piggy-back on the existing analysis for that because we don't do that for instance fields).

@keertip keertip added the area-analyzer Use area-analyzer for Dart analyzer issues, including the analysis server and code completion. label Nov 16, 2020
@johnniwinther
Copy link
Member Author

cc/ @stereotype441

@stereotype441
Copy link
Member

Likely missed that because we don't do promotion of instance variables. It's not safe to assume that field has the same value in field as Bar as it had in field == null - a subclass could override field and return something new each time.
(Probably won't, but compilers can't rely on "probably").

Not saying that migration tools can't assume that the code is reasonable, though. It might make sense for the migration tool to assume that checks do promote field, and so field as Bar could assume that field is not null and not make it as Bar?.
(Not sure how easy that would be, though. It won't be able to piggy-back on the existing analysis for that because we don't do that for instance fields).

Agreed. This is one of the prinicpal improvements discussed in #40566. Glad to hear I'm not the only one who thinks this would be beneficial.

@stereotype441
Copy link
Member

Duplicate of #40566

@stereotype441 stereotype441 marked this as a duplicate of #40566 Nov 16, 2020
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area-analyzer Use area-analyzer for Dart analyzer issues, including the analysis server and code completion. type-enhancement A request for a change that isn't a bug
Projects
None yet
Development

No branches or pull requests

4 participants