Implement location link for type inlay hints by HKalbasi · Pull Request #13699 ·...
source link: https://github.com/rust-lang/rust-analyzer/pull/13699
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
Implement location link for type inlay hints #13699
Conversation
fix #11701
This actually doesn't work due a problem in vscode: microsoft/vscode#167564
changelog note: The vscode issue is now fixed, but won't land until the january release, so the feature is disabled serverside for VSCode until then
added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label
Contributor
Author
HKalbasi commented Nov 29, 2022
@rustbot blocked |
added S-blocked Status: marked as blocked ❌ on something else such as an RFC or other implementation work.
and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties.
labels
Collaborator
bors commented Dec 20, 2022
The latest upstream changes (presumably #13804) made this pull request unmergeable. Please resolve the merge conflicts. |
Contributor
Author
HKalbasi commented Dec 20, 2022
The vscode issue is now fixed, but if I understand correctly it will be included in January release, not next release. |
Member
Veykril commented Dec 21, 2022
Since it won't release until the january release I think we have two options, wait with merging this PR, or check the vscode client version on the server to conditionally enable the link part of this PR as VSCode tells its version in the |
// FIXME: This is here since it is input of a method in `HirWrite` |
||
// and things outside of hir need to implement that trait. We probably |
||
// should move whole `hir_ty::display` to this crate so we will become |
||
// able to use `ModuleDef` or `Definition` instead of `ModuleDefId`. |
I think in general we want to have proper visitors for various things at some point, since the HirWrite
interface is tailored to IDE purposes right now and shouldn't really be part of hir-ty either.
I think we should have something in hir-ty that basically turns a type into a tree that directly maps to surface syntax, but still uses IDs instead of names. That representation could then be consumed by the IDE crates
Contributor
Author
HKalbasi commented Dec 21, 2022
I think it is not necessary, since it wouldn't cause crash or anything like that, it just doesn't do its job. |
Member
Veykril commented Dec 21, 2022
I know but I imagine people will start reporting this as a bug. Though maybe its fine if we note this down in the changelog that it current VSCode has a bug there. |
Member
Veykril commented Dec 21, 2022
Thanks! |
Collaborator
bors commented Dec 21, 2022
Collaborator
bors commented Dec 21, 2022
Collaborator
bors commented Dec 21, 2022
Test successful - checks-actions |
if let Some(client) = client_info { |
||
if client.name.contains("Code") || client.name.contains("Codium") { |
||
if let Some(version) = &client.version { |
||
if version.as_str() < "1.76" { |
Shouldn't this be 1.75? 1.74 is the November release, they skip December, and 1.75 comes out in January.
Contributor
Author
HKalbasi Dec 26, 2022
You are right. I wasn't aware that they will skip december release entirely.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
No one assigned
None yet
No milestone
Successfully merging this pull request may close these issues.
Recommend
About Joyk
Aggregate valuable and interesting links.
Joyk means Joy of geeK