Report diagnostics for unused "using" and "import" so that they will be shown properly in ide

[RodgeFu]

When "using" and "import" are not needed, dim them and provide quickfix in IDE.

related issues:
#3373 , #4861

[azure-sdk]

All changed packages have been documented.

• ✅ @typespec/compiler
• ✅ @typespec/http-specs
• ✅ @typespec/rest

Show changes

@typespec/compiler - feature ✏️

Support diagnostics for unused import and using statements

@typespec/http-specs - fix ✏️

Remove unnecessary "import" and "using" from tsp code

@typespec/rest - internal ✏️

Update test code to handle diagnostics for unnecessary code

[azure-sdk]

You can try these changes here

🛝 Playground	🌐 Website	📚 Next docs

[RodgeFu]

@timotheeguerin , @chrisradek , I tried to check the project part code and can't find a way to identify the references as commented here. Please let me know if there is some way I missed to count them considering my knowledge in compiler is still limited. thanks.

[chrisradek]

Nit: Should this be named unused? Does it make sense to have import/using - specific messages?

I prefer unused over unnecessary since the latter has a subjective connotation, and at least in TS, unused is common for linter rules.

[RodgeFu]

I am fine with "unused", update "unnecessary" to "unused-import" and "unused-using". thanks.

[chrisradek]

Question that might need input from others:

Do we want the unused import/using to show up as a trace diagnostic when running the compiler? It's a little surprising to see it as a trace without enabling tracing. The TypeScript compiler has a few flags for enabling some "unused" checks which then treats them as errors - wonder if we want to do something similar here.

[RodgeFu]

Question that might need input from others:

Do we want the unused import/using to show up as a trace diagnostic when running the compiler? It's a little surprising to see it as a trace without enabling tracing. The TypeScript compiler has a few flags for enabling some "unused" checks which then treats them as errors - wonder if we want to do something similar here.

They are logged as "trace" because I can't find a better loglevel to log them. I think they are definitely not "error" or "warning". Please feel free to suggest if there is a better way to log them.

I am not quite sure I understand the "flags" part correctly, do you mean something like compilerOption? How would it help on the trace? Or do you mean only reporting these diagnostics when some compiler option (i.e. "designTimeBuild") is on?

[RodgeFu]

Talked offline and we are not able to 100% determine whether an import is used because user may modify the tree in their lib or emitters, so I will

• extract the unused-using part and file another PR for it
• do some investigation to see whether we can express these unused-import information in a more accurate way which is still very useful to end user in most case (Or if we have type-only lib supported, then we should not have this problem)

close this PR and the issues are still open to track the 2 actions above.