You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Intellisense for nullable types does not display the null postfix operator #3174
Describe the bug
While working in a null safe dart project, if you start to type out a member from a class like fooClass., the intellisense popup does not display the null postfix operator:
Notice the type is LiveForexQuote.
But hovering over the member, then the correct type (nullable) is shown:
To Reproduce
Steps to reproduce the behavior:
Create a nullable variable in a class
Start typing to dereference that nullable class member
Intellisense won't show the null postfix operator.
Expected behavior
Should show the null postfix operator like when you hover over it after typing it in.
Versions (please complete the following information):
final withNullability = element.returnType.element?.declaration?.library?.isNonNullableByDefault ??false;
return element.returnType.getDisplayString(withNullability: withNullability);
It seems to handle this, but it leaves me with some questions:
Which library should be used to determine whether to show it (here I'm using the library that declares the return type - I don't know if that's correct (I think hovers might be always using the source library?)
If the library declaring the type works, could it be handled inside getDisplayString since it can access element?.declaration?.library?.isNonNullableByDefault directly?
Which library should be used to determine whether to show it ...
Good question. I'm not sure what users want to see, but we've been using the principle that we should show the type that something has in the location at which it is referenced. If a top-level variable int? x; is declared in an opted in library, but is referenced from an opted out library, then we don't show the nullability marker. This matches what the spec says, and in the absence of evidence that that's wrong, it seems like a reasonable default.
Activity
DanTup commentedon Apr 26, 2021
@bwilkerson this appears to be because
DartType.getDisplayStringcalls that assume non-null here:https://github.com/dart-lang/sdk/blob/b10a592341bec4a00379d5c674a417b6b8c781a6/pkg/analysis_server/lib/src/protocol_server.dart#L57-L75
If I change them to something like:
It seems to handle this, but it leaves me with some questions:
getDisplayStringsince it can accesselement?.declaration?.library?.isNonNullableByDefaultdirectly?bwilkerson commentedon Apr 26, 2021
Good question. I'm not sure what users want to see, but we've been using the principle that we should show the type that something has in the location at which it is referenced. If a top-level variable
int? x;is declared in an opted in library, but is referenced from an opted out library, then we don't show the nullability marker. This matches what the spec says, and in the absence of evidence that that's wrong, it seems like a reasonable default.DanTup commentedon Apr 27, 2021
Sounds good to me - I've opened https://dart-review.googlesource.com/c/sdk/+/197042/.
DanTup commentedon Apr 27, 2021
Fixed by dart-lang/sdk@115a758.