rust-analyzer cannot jump to the definition of components or attributes used inside of html!() macros

Problem
When hovering and ctrl-clicking a component inside of an html!() macro it doesn't pull up the definition of the component, instead it gives a laundry list of uses which seemingly includes many of the items used inside of the macro (see among other things references to core and std):

Steps To Reproduce
Steps to reproduce the behavior:

1. Take any yew project.
2. ctrl-click on any component inside of an html!() macro.

Expected behavior
You should jump to the component.

Environment:

• Yew version: master
• Rust version: 1.89.0

Cause

The root cause of this is the spans being produced by the macro. Yew makes heavy used of respanning methods such as quote_spanned! and parse_quote_spanned!. Judging by the test cases (and running some of them) this is to improve ergonomics in error reporting.

Unfortunately this has the effect of the relevant identifier being hovered over having the span of presumably a much wider expression than the scope of the identifier, which confuses rust-analyzer.

I have a branch where I removed all respanning methods, and there I can jump to the definition of components, feel free to try it out: https://github.com/udoprog/yew/tree/remove-spans.

This is what I get with my branch (it cleanly jumps to the definition when clicked):

In my branch, jumping to attributes almost works as well. It currently uses two definitions which seems to confuse rust-analyzer:

In my mind, this is an important use case than improving error diagnostics, jumping to definition is something I attempt all the time, which is what caused me to investigate the issue and write this bug report.

Thank you!

Start by comparing the current macro span behavior with the remove-spans branch linked in the issue, focusing on quote_spanned! and parse_quote_spanned! usage in html!(). Reproduce component and attribute navigation in a Yew project with rust-analyzer. Done means components jump to their definitions and attributes resolve correctly without losing the error-reporting behavior the respanning was intended to provide.