[DAS] Adds more information to type parameter hovers
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Auto-Submit | +1 |
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Oh, I missed the `analyzer` change, so I'll add Konstantin too, and you can choose whoever reviews this. Thanks!
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
<field name="containingInstanceDescription" optional="true">If we did make changes here, there's a changelog section (either here, or in the common_types file?) that should be updated.
/// "containingClassDescription": optional StringI think removing/renaming this is a breaking change to the legacy protocol (it's marked as optional so not breaking in the sense of breaking the protocol, but would prevent the data that was in it previously from being shown).
I don't know if IntelliJ is still using this though - I did find it referenced in a change here:
https://github.com/flutter/dart-intellij-third-party/commit/20004620ae97ea70d4485d56a63f2d51a258cba4
But that file doesn't seem to exist now, so I'm not sure what that means.
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
<field name="containingInstanceDescription" optional="true">If we did make changes here, there's a changelog section (either here, or in the common_types file?) that should be updated.
I'll look for it, thanks!
/// "containingClassDescription": optional StringI think removing/renaming this is a breaking change to the legacy protocol (it's marked as optional so not breaking in the sense of breaking the protocol, but would prevent the data that was in it previously from being shown).
I don't know if IntelliJ is still using this though - I did find it referenced in a change here:
https://github.com/flutter/dart-intellij-third-party/commit/20004620ae97ea70d4485d56a63f2d51a258cba4
But that file doesn't seem to exist now, so I'm not sure what that means.
This rename is merely a suggestion. If you think this would break things, I can easily roll back.
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Declared in `f` in _package:test/main.dart_.''';What follows is me thinking out loud (as it were), not a request for changes.
I understand the value of including information about where a type parameter is defined because they can come from multiple declarations. It's less clear to me that it's helpful for things like local variables, though I suppose for deeply nested local functions (which should almost never be used) it might be useful when referencing a variable from an outer scope. Including the package name for local variables seems like noise.
In the type parameter case it would probably be better to identify the kind of the element rather than just the name. For example "the class `C`" or "the method `m` in the class `C`". Not sure it's worth the extra effort though.
Declared in `<unnamed>` in `foo` in _package:test/main.dart_.''';That's not very helpful, but then it's a local variable so I'm not convinced any of the extra text is useful. It wouldn't be any more helpful, but would read better, to say "a closure" (without the backticks, of course).
<field name="containingInstanceDescription" optional="true">Felipe MorschelIf we did make changes here, there's a changelog section (either here, or in the common_types file?) that should be updated.
I'll look for it, thanks!
I consider this rename to be a breaking change, despite the fact that the field is marked 'optional'. The IDE plugin shouldn't fail as a result of the field not being defined, but the UX will be negatively impacted. Please revert the name change. (The updates to the description are fine.)
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Auto-Submit | +1 |
Declared in `f` in _package:test/main.dart_.''';What follows is me thinking out loud (as it were), not a request for changes.
I understand the value of including information about where a type parameter is defined because they can come from multiple declarations. It's less clear to me that it's helpful for things like local variables, though I suppose for deeply nested local functions (which should almost never be used) it might be useful when referencing a variable from an outer scope. Including the package name for local variables seems like noise.
In the type parameter case it would probably be better to identify the kind of the element rather than just the name. For example "the class `C`" or "the method `m` in the class `C`". Not sure it's worth the extra effort though.
"the class `C`" or "the method `m` in the class `C`"
I'd love to have this. I didn't just do it because I wasn't sure how the class reference was used by IntelliJ (legacy). I'll do it, and if you can think of a case where this can be wrong, I can undo.
Including the package name for local variables seems like noise.
I agree, but it does so when it gets to the class by default, so special-casing that doesn't seem that important. And this would help if something like https://github.com/dart-lang/language/issues/67#issuecomment-4006650906 were ever implemented.
Declared in `<unnamed>` in `foo` in _package:test/main.dart_.''';That's not very helpful, but then it's a local variable so I'm not convinced any of the extra text is useful. It wouldn't be any more helpful, but would read better, to say "a closure" (without the backticks, of course).
I can wrap that too. This is the displayName of the element.
<field name="containingInstanceDescription" optional="true">Felipe MorschelIf we did make changes here, there's a changelog section (either here, or in the common_types file?) that should be updated.
Brian WilkersonI'll look for it, thanks!
I consider this rename to be a breaking change, despite the fact that the field is marked 'optional'. The IDE plugin shouldn't fail as a result of the field not being defined, but the UX will be negatively impacted. Please revert the name change. (The updates to the description are fine.)
I'll undo it and add the new field to the changelog. Thanks!
/// "containingClassDescription": optional StringFelipe MorschelI think removing/renaming this is a breaking change to the legacy protocol (it's marked as optional so not breaking in the sense of breaking the protocol, but would prevent the data that was in it previously from being shown).
I don't know if IntelliJ is still using this though - I did find it referenced in a change here:
https://github.com/flutter/dart-intellij-third-party/commit/20004620ae97ea70d4485d56a63f2d51a258cba4
But that file doesn't seem to exist now, so I'm not sure what that means.
This rename is merely a suggestion. If you think this would break things, I can easily roll back.
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Auto-Submit | +1 |
await assertNullHover(content);After I created `test_typeParameter_declaration`, this one fails. What would you expect from this declaration? Should I special-case the `name` being `_`?
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
await assertNullHover(content);After I created `test_typeParameter_declaration`, this one fails. What would you expect from this declaration? Should I special-case the `name` being `_`?
After I created test_typeParameter_declaration, this one fails.
Adding one test shouldn't be able to effect any other tests. Are you sure you didn't change anything else?
What would you expect from this declaration?
For hover? I don't know. I don't think there's anything useful to say, so we might want to just not produce a hover here, or for any wildcard.
But we should consider having a diagnostic (probably a lint) telling the user to remove the type parameter. There's no value that I can think of for using a wildcard as a type parameter.
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Auto-Submit | +1 |
await assertNullHover(content);Brian WilkersonAfter I created `test_typeParameter_declaration`, this one fails. What would you expect from this declaration? Should I special-case the `name` being `_`?
After I created test_typeParameter_declaration, this one fails.
Adding one test shouldn't be able to effect any other tests. Are you sure you didn't change anything else?
What would you expect from this declaration?
For hover? I don't know. I don't think there's anything useful to say, so we might want to just not produce a hover here, or for any wildcard.
But we should consider having a diagnostic (probably a lint) telling the user to remove the type parameter. There's no value that I can think of for using a wildcard as a type parameter.
Adding one test shouldn't be able to effect any other tests. Are you sure you didn't change anything else?
Oh, yes, I changed more code to make it pass, because we simply weren't producing any hover at the declaration site. I should've been clearer.
I'll special-case for wildcards then.
We already have `no_wildcard_variable_uses`, but it doesn't trigger for type parameters.
I've opened https://github.com/dart-lang/sdk/issues/63831.
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Auto-Submit | +1 |
await assertNullHover(content);Brian WilkersonAfter I created `test_typeParameter_declaration`, this one fails. What would you expect from this declaration? Should I special-case the `name` being `_`?
FMorschelAfter I created test_typeParameter_declaration, this one fails.
Adding one test shouldn't be able to effect any other tests. Are you sure you didn't change anything else?
What would you expect from this declaration?
For hover? I don't know. I don't think there's anything useful to say, so we might want to just not produce a hover here, or for any wildcard.
But we should consider having a diagnostic (probably a lint) telling the user to remove the type parameter. There's no value that I can think of for using a wildcard as a type parameter.
Adding one test shouldn't be able to effect any other tests. Are you sure you didn't change anything else?
Oh, yes, I changed more code to make it pass, because we simply weren't producing any hover at the declaration site. I should've been clearer.
I'll special-case for wildcards then.
We already have `no_wildcard_variable_uses`, but it doesn't trigger for type parameters.
I've opened https://github.com/dart-lang/sdk/issues/63831.
Done
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
<field name="containingInstanceDescription" optional="true">If we did make changes here, there's a changelog section (either here, or in the common_types file?) that should be updated.
Brian WilkersonI'll look for it, thanks!
I consider this rename to be a breaking change, despite the fact that the field is marked 'optional'. The IDE plugin shouldn't fail as a result of the field not being defined, but the UX will be negatively impacted. Please revert the name change. (The updates to the description are fine.)
I'll undo it and add the new field to the changelog. Thanks!
If I'm looking at this correctly, this still contains the rename that could be breaking to legacy clients?
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Code-Review | +1 |
| Commit-Queue | +1 |
<field name="containingInstanceDescription" optional="true">FMorschelIf we did make changes here, there's a changelog section (either here, or in the common_types file?) that should be updated.
Brian WilkersonI'll look for it, thanks!
FMorschelI consider this rename to be a breaking change, despite the fact that the field is marked 'optional'. The IDE plugin shouldn't fail as a result of the field not being defined, but the UX will be negatively impacted. Please revert the name change. (The updates to the description are fine.)
Danny TuppenyI'll undo it and add the new field to the changelog. Thanks!
If I'm looking at this correctly, this still contains the rename that could be breaking to legacy clients?
I don't think so. The 'undo' consisted of adding a new field with the new name rather than renaming an existing field to the new name. It appears that the old field is still being set to the old value, so there shouldn't be any degradation.
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Auto-Submit | +1 |
<field name="containingInstanceDescription" optional="true">FMorschelIf we did make changes here, there's a changelog section (either here, or in the common_types file?) that should be updated.
Brian WilkersonI'll look for it, thanks!
FMorschelI consider this rename to be a breaking change, despite the fact that the field is marked 'optional'. The IDE plugin shouldn't fail as a result of the field not being defined, but the UX will be negatively impacted. Please revert the name change. (The updates to the description are fine.)
Danny TuppenyI'll undo it and add the new field to the changelog. Thanks!
Brian WilkersonIf I'm looking at this correctly, this still contains the rename that could be breaking to legacy clients?
I don't think so. The 'undo' consisted of adding a new field with the new name rather than renaming an existing field to the new name. It appears that the old field is still being set to the old value, so there shouldn't be any degradation.
I've sent a new patchset, but I didn't respond to this thread (forgot, sorry). There was something incorrect with my previous changes. But it is fixed now.
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Auto-Submit | +1 |
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Auto-Submit | +1 |
Everything fixed. Thanks for the bots!
Oh, a separate file with the same name elsewhere still had a problem. Now things are truly handled. Sorry for the false-positive.
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |