-
Notifications
You must be signed in to change notification settings - Fork 1.7k
VM is not using opt-in status to default sound mode with a package in the allow list #43243
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
Labels
legacy-area-front-end
Legacy: Use area-dart-model instead.
NNBD
Issues related to NNBD Release
P2
A bug or feature request we're likely to work on
type-bug
Incorrect behavior (everything from a crash to more subtle misbehavior)
Comments
natebosch
added a commit
to dart-archive/csslib
that referenced
this issue
Aug 28, 2020
The `as num` cast existed before the migration, but in the wrong place so the overall expression was still `dynamic`. Implicit casts from `dynamic` are still allowed, so it wasn't flagged that the cast was in the wrong place - disabling implicit casts from dynamic makes it more obvious that there is a problem, but doesn't fix the entire issue. In addition to the cast being in the wrong place, it also was to the wrong type. Casting to `num` instead of `num?` does not surface any warnings because it's valid to pass the `num` to an argument wanting `num?`. This was not surfaced originally due to a bug in the VM which causes the opt-in state of a package in the experiment allow list to _not_ control the soundness when executing. Add explicit opt in test runs for now. dart-lang/sdk#43243
natebosch
added a commit
to dart-archive/csslib
that referenced
this issue
Aug 29, 2020
The `as num` cast existed before the migration, but in the wrong place so the overall expression was still `dynamic`. Implicit casts from `dynamic` are still allowed, so it wasn't flagged that the cast was in the wrong place - disabling implicit casts from dynamic makes it more obvious that there is a problem, but doesn't fix the entire issue. In addition to the cast being in the wrong place, it also was to the wrong type. Casting to `num` instead of `num?` does not surface any warnings because it's valid to pass the `num` to an argument wanting `num?`. This was not surfaced originally due to a bug in the VM which causes the opt-in state of a package in the experiment allow list to _not_ control the soundness when executing. Add explicit opt in test runs for now. dart-lang/sdk#43243
I believe this is a CFE issue not a VM issue and is probably a moot point as we are in the process of flipping |
With the flipping of the flag we now also default to sound mode for auxiliary files in allowed packages when explicitly or implicitly using the experiment release version. |
mosuem
pushed a commit
to dart-lang/tools
that referenced
this issue
Oct 25, 2024
The `as num` cast existed before the migration, but in the wrong place so the overall expression was still `dynamic`. Implicit casts from `dynamic` are still allowed, so it wasn't flagged that the cast was in the wrong place - disabling implicit casts from dynamic makes it more obvious that there is a problem, but doesn't fix the entire issue. In addition to the cast being in the wrong place, it also was to the wrong type. Casting to `num` instead of `num?` does not surface any warnings because it's valid to pass the `num` to an argument wanting `num?`. This was not surfaced originally due to a bug in the VM which causes the opt-in state of a package in the experiment allow list to _not_ control the soundness when executing. Add explicit opt in test runs for now. dart-lang/sdk#43243
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
legacy-area-front-end
Legacy: Use area-dart-model instead.
NNBD
Issues related to NNBD Release
P2
A bug or feature request we're likely to work on
type-bug
Incorrect behavior (everything from a crash to more subtle misbehavior)
The allow list signals that any file within a package (including outside of it's
lib/
) may use the non-nullable experiment. This is working correctly in the CFE - the code is parsed as opted in.This is not working correctly to choose whether to run with sound null safety or not. The intended behavior is that if the entrypoint library is opted in, then run with sound null safety. This was the behavior before. With the latest dev SDK the actual behavior is that
--enable-experiment=non-nullable
is still required.The text was updated successfully, but these errors were encountered: