-
Notifications
You must be signed in to change notification settings - Fork 382
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
WIP: add UseCompatibleTypes Rule, including related resources. Refactor UseCompatibleCmdlets Rule. #960
Conversation
Thanks for your work and welcome to PSSA! Some quick things that I found when scanning the changes: The command data files are of version 6.0.1 and not 6.0.2. The osx file should use the word macos instead of osx, see recently merged PR #947 for why. Also have a look at my current PR #954 (I'm OK to close or modify mine instead) |
e3c35d9
to
4eb3ae4
Compare
@MiaRomero Please update your branch and resolve merge conflicts |
… compatibleTypes rules
fbb6853
to
4ccf4e4
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Did a preliminary review pass -- generally looks good, but I've left some comments
/// </summary> | ||
public string GetSourceName() | ||
// Name of known issues list file. | ||
private readonly string knownIssuesFileName = "knownCmdletIssues.json"; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd move all the readonly
private vars to the top in their own group
if (!IsInitialized) | ||
{ | ||
Initialize(); | ||
} | ||
|
||
if (hasInitializationError) | ||
{ | ||
yield break; | ||
Console.WriteLine("There was an error running the UseCompatibleCmdlets Rule. Please check the error log in the Settings file for more info."); | ||
return new DiagnosticRecord[0]; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This should be a static variable ideally to prevent new allocations on failure.
{ | ||
return AstVisitAction.SkipChildren; | ||
return new DiagnosticRecord[0]; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same thing about the static variable
var commandName = commandAst.GetCommandName(); | ||
if (commandName == null) | ||
// If we have no cmdlets to check, we can exit from this rule. | ||
if (commandAsts.Count() == 0) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd move this check up to be right under the commandAsts
so it fails early
yield return dr; | ||
} | ||
} | ||
customCommands = new List<string>(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We seem to do diagnosticRecords.Clear()
but also customCommands = new List<string>()
.
I don't exactly agree with the prevailing style of this class, but in its spirit maybe we need to:
- Make all the collection fields readonly
- Have a
Clear()
method that clears all the collections that should be empty when a rule runs
The ideal way I would do this would be to:
- Get rid of the
Initialize()
method - Put initialisation into the constructor or as lazy fields
But that might be too far.
But we should try and be consistent about:
- Having collections as private fields vs local variables
- Using
Clear()
vs reassigning an empty collection - Having readonly fields where it makes sense
I say all this because I think dealing with customCommands
should be moved down to the loop that adds elements to it, but if we move the early exit up then we might have a dirty collection
string settingsPath = Settings.GetShippedSettingsDirectory(); | ||
|
||
if (String.IsNullOrEmpty(settingsPath)) | ||
{ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If this happens, the failure will be silent?
{ | ||
string name = type.Name.ToString(); | ||
string nameSpace = type.Namespace.ToString(); | ||
string fullName = nameSpace + "." + name; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The namespace of the type might be empty, in which case the .
will not be correct. Also, if the type is nested, the full type name will be different
dynamic typeList = deserializedObject.Types; | ||
foreach (dynamic type in typeList) | ||
{ | ||
string name = type.Name.ToString(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These should already be strings -- it might be a case of casting them rather than calling ToString()
? Unless there's something occuring in deserialisation?
List<fullTypeNameObject> fullNameObjectList = new List<fullTypeNameObject>(); | ||
|
||
// Check to see if our object is a CommandAst. | ||
if (typeObject is CommandAst) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A large nested if
statement like this should be refactorable with return
s hopefully
{ | ||
string name; | ||
ScriptBlock script; | ||
// Create a TypeExpressionAst from the CommandElementAst |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There might be a better way to do this -- I'll look into it
@rjmholt All the added/removed/renamed JSON files should probably be reverted as this PR was created before I added the proper ones for 6.0.2. The ones for 6.1 should only be added once 6.1 goes GA |
I'm closing this now as #1133 was taken |
PR Summary
Add UseCompatibleTypes rule which checks for compatibility with a specified version of PowerShell on a specified platform. Refactor UseCompatibleCmdlets to be similar since both use the same resources.
Need:
updated type/cmdlet dictionaries for Core 6.0.2
rule documentation
PR Checklist
Note: Tick the boxes below that apply to this pull request by putting an
x
between the square brackets. Please mark anything not applicable to this PRNA
.WIP:
to the beginning of the title and remove the prefix when the PR is ready