New rule: AvoidOverwritingBuiltInCmdlets

[thomasrayner]

PR Summary

Addresses #1023 .

This rule (PSAvoidOverwritingBuiltInCmdlets) looks for FunctionDefinitionAsts that have the same name as a cmdlet that comes with PowerShell. This rule leverages the JSON files which contain information on all the cmdlets for PS 3, 4, 5, and 6 (and presumably 7 later) that already ship with PSScriptAnalzyer.

I've edited GetScriptAnalyzerRule.tests.ps1 to reflect the addition of this new rule, but suspect that if the other rule I recently created a PR for is merged before this one, that I'll need to edit that test again.

PR Checklist

• PR has a meaningful title
  • Use the present tense and imperative mood when describing your changes
• Summarized changes
• Change is not breaking
• Make sure all .cs, .ps1 and .psm1 files have the correct copyright header
• Make sure you've added a new test if existing tests do not effectively test the code changed and/or updated documentation
• This PR is ready to merge and is not Work in Progress.
  • If the PR is work in progress, please add the prefix WIP: to the beginning of the title and remove the prefix when the PR is ready.

[thomasrayner]

It appears that a whole bunch of tests are busted but I'm not sure it's a result of the changes in this PR, however, I haven't dug that deep into them on the assumption that this is already known.

[bergmeister]

Please look into the test failures, they are definitely caused by your code as I see a lot of exceptions of type ArgumentNullException that likely comes from your rule as it is being run by default. What kind of performance impact does running this rule by default have (cold and warm run)? I've just merged your other PR, so please resolve the merge conflict as well (and you probably need to re-generate the resource strings as well).
The JSON files that you use are from an old compatibility rule, it is probably OK for this use case but maybe @rjmholt can make a statement whether his compatibility profiles contain more commands? They are here btw: https://github.com/PowerShell/PSScriptAnalyzer/tree/master/PSCompatibilityCollector/profiles

[rjmholt]

@rjmholt can make a statement whether his compatibility profiles contain more commands?

If it's just builtin commands, I would imagine the old profiles have the same information (a list of those commands).

Depending on the full compatibility profiles would be a resource drain. In a case like this, since you only need a list, either using those old profiles or just storing a list in the rule's code will probably suffice for now.

[rjmholt]

Ah but I just saw it's a configuration thing... Hmmm, not sure what the right answer is there, since it's public, so we don't want to break it in future. Those old profiles aren't about to get any updates as far as I know, so it's not ideal to depend on them publicly.

It might be that it's time to solve the question of how to specify a PowerShell platform nicely...

[bergmeister]

The reason why those old command data files contain less cmdlets is because of the way they are generated here: https://github.com/PowerShell/PSScriptAnalyzer/blob/master/Utils/New-CommandDataFile.ps1

[thomasrayner]

Obviously I've got more to do here, like dig into those test failures, but I wanted to get some of these changes back to you folks to discuss.

[thomasrayner]

I took a shot at fixing the test errors that were definitely my fault 😂, contrary to my original thought. The four remaining tests that fail are for the UseCompatibleCommands rule test, and only appear to occur on the Ubuntu test env.

[bergmeister]

@thomasrayner Thanks, I will look at the PR this weekend. You are right, the 4 failing Ubuntu tests are a new integration failure on master caused by the last merged PR #1331 (@rjmholt please fix them please). The sporadically failing test around runspace disposal, you can ignore as well (the maximum number needs increasing).
Most of it looks ok but I can already tell you we'll need to have a conversation around that test process stuff (sorry, but just wrong on so many levels IMHO). First of all, the user should be explicit in the settings and second, this is how you can determine in which version of PowerShell you are currently running in order to determine a useful default

bool runningInPowerShellCore = false;
#if CORECLR
runningInPowerShellCore = true;
#endif

[thomasrayner]

Well, I'm not sure how I missed that, but I'm looking forward to changing it 😁

[bergmeister]

Just some minor comments to be discussed but otherwise I'm pretty happy with it and I've done a quick performance test and can say that this does not seem to have an impact on PSSA performance despite it being enabled by default

[bergmeister]

Some more minor comments but after that I'm happy to sign it off. What do you think @rjmholt

[bergmeister]

I'm happy, what about you @rjmholt ?

[bergmeister]

I'm happy, what about you @rjmholt ? I'd merge it if you're happy.
You don't need to do a full review, just checking you're happy with it on a high level.

[rjmholt]

LGTM

[bergmeister]

Still looks good to me, I resolved the merge conflict. The test failures on Ubuntu are new in master as well @rjmholt ...