-
Notifications
You must be signed in to change notification settings - Fork 376
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Stabilize go call analysis and make it default behavior #513
Comments
@hogo6002 this is another potential starter project for you. @another-rex WDYT? |
Could we have the flags take a comma list of langs, with the presence of a flag meaning "all"? e.g.
And then the same again for experimental. I know it seems a bit verbose but I think logically that should be very straightforward to determine - I think something like:
That's rough pseudo code - I think really the more fiddly bit is probably handling the actual flag parsing to handle what's typically mapped to a bool; so I've used |
That makes sense, and it provides more control to the user than just separating experimental and non experimental languages for call analysis. I think we can retire the experimental-call-analysis flag and just have the --call-analysis flag, with supported languages being enabled by default, and documenting which languages are still experimental. I'm still debating whether just passing |
Hi Gareth, I agree with your design that we should set call analysis per language. I made some changes based on my understanding. Feel free to leave any comments. So far, we only have call analysis for rust and go. Call analysis for go is stable/non-experimental, so we want to make it runs as default.
Then, as you mentioned, we have two flags to represent if call analysis is enabled. But I think non-experimental call analysis should always be running unless we disable it. Also, I don't think we can pass
|
you should be able to do it using the `GenericFlag` - the trick is you need to implement `IsBoolFlag` which is effectively "does this flag require a value to be provided?"
Result:
However thinking about it since the whole point is to have it enabled by default I actually don't think we need this because we should expect people will only be providing I think it's probably worth talking about what the short term plans are for call analysis: do you expect there will be a large number of languages landing in the next 6 months? if not then frankly this is probably not worth much effort right now so I'd just go with having Part of why I say this is that I realised two additional things:
Both of these really only matter if the plan is to have a number of languages supported in different states, and they should not be breaking to add in future. I guess in saying that we could also just go with |
+1
The vast majority of use cases will only be scanning one or 2 languages at a time, so I don't think this is something to be concerned about. So happy to go with the array-based flags.
I do quite like the Let's go with this:
each of which can specify the language to enable/disable, and an additional entry This should result in the behavior you already have @hogo6002, just using StringSlice instead of string so when additional languages are supported you can specify multiple flags like EDIT: Changed |
Fix issue #513 - Replace `experimental-call-analysis` with `call-analysis`. (`--call-analysis=all`, `--call-analysis=rust`) - Adding a `--no-call-analysis` to disable call analysis. (`--no-call-analysis=all`, `--no-call-analysis=go`). This overrides `call-analysis`. - Delete `call-analysis` from `experimental-config` in result report. - Call analysis for non-experimental languages (e.g. go) is auto enabled.
Go call analysis should be the default behavior if the go toolchain is detected.
TODO:
Figure out the best way to organize call graph analysis flags to allow disabling/enabling, and experimental-ness on a per language level.
The text was updated successfully, but these errors were encountered: