Repository navigation
Method calls on unresolved/invalid variables are coloured inconsistently #3412
Description
Describe the bug
Extension method color depends on list type.
To Reproduce
void main() {
var list = <dynamic>[1, 2, 3];
list[0].equals(1); // <- blue
var list2 = <int>[1, 2, 3];
list2[0].equals(1); // <- yellow
}
extension ExpectExtension on Object? {
void equals(Object? value) {
assert(this == value);
}
}Expected behavior
Same colors.
Screenshots
Versions (please complete the following information):
- VS Code version: 1.57.0
- Dart extension version: v3.23.0
- Dart/Flutter SDK version: 2.14.0-152.0.dev
Activity
[-]Extension method color depends on list type.[/-][+]Methods called on `dynamic` are not coloured as methods[/+]DanTup commentedon Jun 17, 2021
Thanks for the report! This appears to be due to the
dynamic- all members are coloured as variables even when they're invocations:DanTup commentedon Jun 17, 2021
I've a fix out for review at https://dart-review.googlesource.com/c/sdk/+/203940/. With that, it looks like this:
The fix is in the Dart SDK, so after merging, it'll show up in a future Dart/Flutter SDK release (rather than a VS Code extension release).
[-]Methods called on `dynamic` are not coloured as methods[/-][+]Methods called on `dynamic` are not coloured correctly[/+]DanTup commentedon Jun 17, 2021
After some back and forth, I'm no longer certain this is a bug (or at least, the originally described bug). There were some weird inconsistencies after making this change when it came to invalid code. Invalid methods are intended not to be coloured. Given the code:
The first
foois known to be invalid and should be uncoloured. The secondfoois unresolved (we don't know what type it is). It seems incorrect to colour the second one like a method but the first one uncoloured.So I think for consistency we should fix both unresolved and invalid members to be uncoloured (this was already sort-of happening for some, but the textmate grammar was filling them in and hiding this). This means methods that are definitely wrong or might be wrong (eg. the compiler can't validate them, and you also can't "jump to definition" etc.) will be uncoloured, like this:
If there is sufficient desire to colour unknown and unresolved methods like normal resolved methods, this may be something to look at - although it does mean that known invalid methods (eg. you try to call
fooon an int) would also be coloured - making the highlighting a little less semantic.[analysis_server] Improve coloring of invalid/unresolved methods in L…
[-]Methods called on `dynamic` are not coloured correctly[/-][+]Method calls on unresolved/invalid variables are coloured inconsistently[/+]DanTup commentedon Jun 28, 2021
I repurposed this slightly to better match the new behaviour - that is, unresolved/invalid types will be left uncoloured (note: this requires an SDK update).
This means dynamic items will still be uncoloured (which was the original complaint), but with semantic tokens I think this makes sense - the compiler is unable to resolve them and leaving them coloured is a good indicator of that.
If you want the original regex-based colouring, you can disable semantic tokens (using the
editor.semanticHighlighting.enabledsetting). Generally, I'd try to avoid usingdynamicwhere possible though - it's easy to create code that would be easy to make fail at runtime without any analysis errors.Hope this makes sense!