✨ add fallbacks for when workspace/symbol isn't giving us what we need #304
Conversation
… need Signed-off-by: Fabian von Feilitzsch <[email protected]>
Signed-off-by: Fabian von Feilitzsch <[email protected]>
| @@ -35,4 +35,22 @@ func main() { | |||
| s := provider.NewServer(client, *port, log) | |||
| ctx := context.TODO() | |||
| s.Start(ctx) | |||
| // serviceClient, err := client.Init(ctx, log, provider.InitConfig{ | |||
There was a problem hiding this comment.
We should remove this, but being able to run the provider directly has been really nice for debugging. Maybe should add a debug subcommand or something for this.
There was a problem hiding this comment.
make it a hidden subcommand in the main binary?
There was a problem hiding this comment.
I don't think it can work in the main binary, would have to be in the provider binaries since the communication between the two is over RPC. Here you can delve debug / see the print statements.
Side note, we really should be capturing the stdout from these providers and presenting them to the users, I don't think we do currently (right?)
There was a problem hiding this comment.
Not in a real way, There is the plumbing to do it though
We have one set of questions with that, though,
- Do we print it out as it happens, or do we bunch them together once a given evaluation is finished
- Are there log levels that need to be returned, is this a verbosity thing where we only print on high levels?
Let me know if you want me to take a stab at it. @pranavgaikwad I am out of the loop on what is important now.
There was a problem hiding this comment.
I think we should print them as they happen, I wouldn't necessarily bother with verbosity levels as a first-class thing since a provider can always implement verbosity levels through providerSpecificConfig. So we'd just want to log with an identifier that lets you know which provider name is logging and do it in real time so that hangs/etc can be debugged
There was a problem hiding this comment.
I think if you wanted to take a stab at it it would be a huge boon to developing providers. such a PITA right now
There was a problem hiding this comment.
@shawn-hurley @fabianvf let me know if this sums up the work #312
| @@ -75,29 +79,119 @@ func (p *genericServiceClient) Evaluate(cap string, conditionInfo []byte) (provi | |||
| } | |||
|
|
|||
| func (p *genericServiceClient) GetAllSymbols(query string) []protocol.WorkspaceSymbol { | |||
| logger, err := os.OpenFile("golang-provider.log", | |||
There was a problem hiding this comment.
Should be removed, this was just for debugging when running from analyzer-lsp
fabianvf
changed the title
Signed-off-by: Fabian von Feilitzsch <[email protected]>
Signed-off-by: Fabian von Feilitzsch <[email protected]>
fabianvf
force-pushed
the
workspace-symbol-fallbacks
branch
from
c33c8ca
to
1b05c0b
Compare
fabianvf
changed the title
| - message: 'golang apiextensions/v1/customresourcedefinitions found {{file}}:{{lineNumber}}' | ||
| ruleID: go-lang-ref-001 | ||
| when: | ||
| go.referenced: | ||
| pattern: "v1beta1.CustomResourceDefinition" | ||
| pattern: ".*v1beta1.CustomResourceDefinition" |
There was a problem hiding this comment.
This should make it trigger the fallback
This is currently failing with Go for... some reason. It can't load packages anymore?This is probably going to be hideously slow on large projects, the directory tree search will need to be parallelized before this is a feasible approach