Closed fourpastmidnight closed 1 year ago
Thanks @fourpastmidnight for taking the time to spend this issue, and for providing such detailed information. PowerShell (rather than PSSA) does the parsing, and applies the attribute accordingly, because there is no param statement what you are seeing is the PowerShell expected behavior. Unfortunately this is not something we can solve for right now on the PSSA level-- PowerShell would need to solve this. The workaround is to use an empty param block (as you did). Thanks!
@SydneyhSmith Thanks for confirming that this is a PowerShell parsing "issue" (at least, a parsing ambiguity with respect to how attributes are applied in PowerShell).
Overview
I was able to successfully suppress the violation of PSUseSingularNouns for two functions within a script using the
SuppressMessageAttribute
. But a third function will not suppress even with the presence of theSuppressMessageAttribute
.Steps to reproduce
Use a PSScriptAnalyzer configuration file with the following contents:
Use the following contents for a script file to be analyzed with PSScriptAnalyzer.
PSScriptAnalyzer returns a violation of the PSUseSingularNouns rule for the last function in the script file above even though a suppression attribute exists. And of course, I tried several variations with no success.
It took me quite a while to spot this since I'm so familiar with the code I'm working on. But notice that the last function DOES NOT declare a
Param ( )
block! Once I added an emptyParam ( )
block, no more violations were reported.I do not believe this is expected behavior because unless your function requires parameters (or simply, doesn't name them), none of my resources say that the
Param ( )
block is required for advanced functions. Additionally, it looks like PowerShell may be parsing theSuppressMessageAttribute
as decorating theBegin { }
block instead of being a "decorator of" the enclosing function.As an aside, it has always bothered me how attributes for functions are placed inside the function declaration, instead of directly above it as it's done in C#. So, if anything, it looks like a PowerShell parser ambiguity here. Does the attribute decorate the enclosing function, or the block within? Adding a
Param ( )
block to the function, it would seem, resolves the parser ambiguity. I even tried putting the[CmdletBinding()]
attribute declaration below theSuppressMessageAttribute
declaration, but the unexpected behavior remains.Now that I think about this, this issue probably does not belong on the PSScriptAnalyzer repo, but with the PowerShell repo, proper. Let me know if I should post this issue on that repository instead, as it's most likely that the PSScriptAnalyzer team can do anything to PSScriptAnalyzer to "fix" this.
Expected behavior
I expect that if my function does not need parameters, the
Param ( )
block can be omitted and that theSuppressMessageAttribute
would still be associated with the function as it is for all other PowerShell functions so that the PSUseSingularNouns rule is suppressed on the affected function.Actual behavior
PSScriptAnalyzer does not suppress this rule and emits a diagnostic record for the affected function. I suspect the attribute is not "decorating" the right block during parsing--being applied to the
Begin { }
block rather than the enclosing function.Environment data