Is it possible to use an analyzer plugin to override an IDE's "go to definition" ?

[Remi Rousselet]

Hello

I do not know much about the capabilities of a custom analyzer plugin, so I am asking this question here to make sure that what I want to achieve is feasible:

Can an analyzer plugin override the default "go-to definition" for a specific element, such that it redirects to something different voluntarily?

I have a code-generator, and I would that that when users use "go-to definition" on one of the generated classes, it redirects to what was user-defined instead of the generated code.

[Brian Wilkerson]

Can an analyzer plugin override the default "go-to definition" for a specific element, such that it redirects to something different voluntarily?

No, not as currently designed. The plugin support was designed to allow plugins to add results, not to allow them to replace results. For example, a plugin can produce new diagnostics that are specific to users of a package, but they can't remove diagnostics produced by the server. They could provide navigation for regions that server does not provide navigation for, but cannot change what server would produce.

I have a code-generator, and I would that that when users use "go-to definition" on one of the generated classes, it redirects to what was user-defined instead of the generated code.

I really like that idea. It seems to me, though, that it would be better to provide support for this in server directly so that all code generators could take advantage of it without requiring every author of a code generator to also author a plugin.

One possible way to do that would be to define an annotation that code generators could emit that would tell the server that navigation to that element should be redirected to a different location. Perhaps something like

@RedirectNavigation('relative/path/to/target', offsetInTarget)

void someGeneratedMethod() { ... }

Would that work for your use case? What do you think?

--
You received this message because you are subscribed to the Google Groups "Dart Analyzer Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to analyzer-discu...@dartlang.org.
To view this discussion on the web visit https://groups.google.com/a/dartlang.org/d/msgid/analyzer-discuss/88a27ee9-dca1-4565-a92f-ddc48b0af87e%40dartlang.org.

[Remi Rousselet]

 It seems to me, though, that it would be better to provide support for this in server directly so that all code generators could take advantage of it without requiring every author of a code generator to also author a plugin.

Agreed! I myself have multiple code-generators that needs to do this

Although I'm not too sure about the propose decorator. Using an offset to determine where the navigation is redirected would likely "break" the cache mecanism of code-generators. I can see that offset needing an update even when the code-generator doesn't need to run.

I would suggest instead something similar to dartdoc:

@RedirectNavigation('package:my_package/file.dart', 'MyClass.property')

           Object someGeneratedProperty; 

To unsubscribe from this group and stop receiving emails from it, send an email to analyzer...@dartlang.org.

[Brian Wilkerson]

You're right. I hadn't thought through all the implications.

I've opened an issue so that we can get a wider audience to discuss the proposal: https://github.com/dart-lang/sdk/issues/40730.

To unsubscribe from this group and stop receiving emails from it, send an email to analyzer-discu...@dartlang.org.
To view this discussion on the web visit https://groups.google.com/a/dartlang.org/d/msgid/analyzer-discuss/19ce176a-ce18-41b9-9062-2dd91df973b3%40dartlang.org.