| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
Sorry, something went wrong.
|
Hmm.... did adding this rule break the tests for AvoidAssignmentToAutomaticVariables? At a glance it looks like those tests need to use IncludeRules rather than ExcluedRules, but I have no idea why that would only become a problem now. |
Sorry, something went wrong.
…the new rule as the parameter is not used in those tests
|
Those tests have function definitions that do not use their parameters, I simply excluded this rule for those tests. It's always a difficult debate whether the tests should test the rules individually or run all rules. There's pros and cons against either but James suggested to run all rules if possible because it provides better integration coverage, especially due to PSSA's multi threaded nature where complex things can happen if all rules execute at once |
Sorry, something went wrong.
…ToList() and minor style tweaks (Linq variable naming and trailing whitespace trim)
There was a problem hiding this comment.
I fixed the other test failures that were not your fault and made some small tweaks. Very happy with this PR and one of the main reasons why I am so eager to come back and get this PR merged is because I am really looking forward to using it
Sorry, something went wrong.
Thanks for the fixes. I'm eager to get this in there as well! |
Sorry, something went wrong.
| { | ||
| // compare the list of variables to the parameter name | ||
| // there should be at least two matches of the variable name since the parameter declaration counts as one | ||
| int matchCount = variables |
There was a problem hiding this comment.
At this point, the algorithm becomes O(n^2) in the number of parameters, which is undesirable.
Instead, it should be possible to do the following:
Sorry, something went wrong.
There was a problem hiding this comment.
Rob Holt (@rjmholt) Forgive me, but I'm failing to see how that will reduce the complexity. Isn't the current code doing essentially what you've described?
Sorry, something went wrong.
There was a problem hiding this comment.
It almost does, but currently:
Sorry, something went wrong.
There was a problem hiding this comment.
Yeah, it's definitely case-sensitive at the moment. I'll take a look at implementing the hashset - I think I can come up with something. Thanks!
Sorry, something went wrong.
|
Matt McNabb (@mattmcnabb) It seems we have a merge conflict here (probably just a simple one like the number of rules), please resolve |
Sorry, something went wrong.
|
Matt McNabb (@mattmcnabb) In your last commit, you resolved the merge conflict by taking HEAD, therefore removing your changes. I've done this for you in your branch |
Sorry, something went wrong.
well that was rookie! |
Sorry, something went wrong.
|
Rob Holt (@rjmholt) Matt McNabb (@mattmcnabb) I pushed one last commit to use .OrderBy and convert it to a dictionary to get a dictionary of the variable count so that we count only once and finding the variable count then in just O(1) after the expense of OrderBy. Given that the number of parameters is only between 1 and 10 in 95% of the cases, I am not sure this is really worth it but probably helps in extreme cases where there are much more auto-generated parameters. What do you think? |
Sorry, something went wrong.
|
Close and re-open to rerun ci |
Sorry, something went wrong.
There was a problem hiding this comment.
Code looks good. Just left a comment on the test, but it's an edge case so not blocking.
Sorry, something went wrong.
|
|
||
| It "has no violations when parameter is called in child scope" -skip { | ||
| $ScriptDefinition = 'function Param { param ($Param1) function Child { $Param1 } }' | ||
| $ScriptDefinition = 'function foo { param ($Param1) function Child { $Param1 } }' |
There was a problem hiding this comment.
I would think of this as a violation. Since PowerShell has dynamic, rather than lexical, scope, Child's $Param1 reference is not guaranteed to be foo's $Param1 parameter.
Sorry, something went wrong.
There was a problem hiding this comment.
I'd rather avoid violations that are going to be false positives in most cases in order to avoid similar problems to PSUseDeclaredVarsMoreThanAssignments
Sorry, something went wrong.
There was a problem hiding this comment.
I think fair enough we want to not emit when at the boundary of our heuristic. Ideally we'd change this to an actual false case, but it's not that important.
Sorry, something went wrong.
| IDictionary<string, int> variableCount = scriptBlockAst.FindAll(oneAst => oneAst is VariableExpressionAst, false) | ||
| .Select(variableExpressionAst => ((VariableExpressionAst)variableExpressionAst).VariablePath.UserPath) | ||
| .GroupBy(variableName => variableName, StringComparer.OrdinalIgnoreCase) | ||
| .ToDictionary(variableName => variableName.Key, variableName => variableName.Count(), StringComparer.OrdinalIgnoreCase); |
There was a problem hiding this comment.
Rob Holt (@rjmholt) Your recently added complex.psm1 test actually caught an edge case that happened when I first added StringComparer.OrdinalIgnoreCase only on .ToDictionary, which caused items of different cases (due to groupby originally being case sensitive) to to be added to the case insensitive dictionary, which then gave the error that the same item had already been added. Therefore I had to add it to GroupBy as well. Chapeau 👏
Sorry, something went wrong.
There was a problem hiding this comment.
Makes me think that PowerShell and other PowerShell tools should have a few real-world test cases too
Sorry, something went wrong.
|
Well, it looks like I'm no longer needed here... I'ma head to bed now - let me know if you guys need anything 🤣 |
Sorry, something went wrong.
|
Christoph Bergmeister (@bergmeister) Rob Holt (@rjmholt) thanks for the fixes on this! I wasn't able to devote much time to reviewing this after the start of the new year. |
Sorry, something went wrong.
| Back | FazBrowse Home | New Git URL |
PR Summary
This PR adds a new rule to detect declared parameters that are not used in the body of the script, function or scriptblock where they are declared. Conversation around this is in #1381.
I've added tests to cover the basic scenarios this will cover, but there may be some cases not covered yet. Some issues to discuss are:
If these are not major issues then this may be ready for merge.
PR Checklist