X Tutup
The Wayback Machine - https://web.archive.org/web/20200918094433/https://github.com/PowerShell/PSScriptAnalyzer/pull/957
Skip to content
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

Allow TypeNotFound parser errors #957

Merged

Conversation

@bergmeister
Copy link
Collaborator

bergmeister commented Mar 31, 2018

PR Summary

Fixes #850
Some Types can not be known in some cases (e.g. due to using statements because the parser does not load anything by design), therefore those TypeNotFound parser errors are being ignored, since the AST can still be parsed.
Thanks to @rjmholt for helping with parser related questions.

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 PR NA.

  • PR has a meaningful title
    • Use the present tense and imperative mood when describing your changes
  • Summarized changes
  • User facing documentation needed
  • Change is not breaking
  • Make sure you've added a new test if existing tests do not effectively test the code changed
  • 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
@bergmeister bergmeister self-assigned this Mar 31, 2018
@bergmeister bergmeister added this to the 1.17 milestone Mar 31, 2018
@bergmeister bergmeister requested a review from JamesWTruher Mar 31, 2018
@@ -1644,6 +1646,31 @@ private static Encoding GetFileEncoding(string path)
}
}

/// <summary>
/// Inspects Parse errors and removes TypeNotFound errors that can be ignored that can be due to types that are not known yet (e.g. due to 'using' statements)

This comment has been minimized.

@kalgiz

kalgiz Apr 5, 2018 Contributor

Mistake in sentence.

Maybe something like:
/// Inspects Parse errors and removes TypeNotFound errors that can be ignored since some types are not known yet (e.g. due to 'using' statements)

It "does not throw and detect one expected warning after the parse error has occured when using -ScriptDefintion parameter set" {
$warnings = Invoke-ScriptAnalyzer -ScriptDefinition $script
$warnings.Count | Should -Be 1 -Because 'PSSA should analyze the whole script after the parse error on [IStorageContext] and find the AvoidAlias warning due to gci'
}

This comment has been minimized.

@kalgiz

kalgiz Apr 5, 2018 Contributor

Maybe we should check this warning is from rule 'AvoidAliases' directly?

Set-Content $testFilePath -value $script
It "does not throw and detect one expected warning after the parse error has occured when using -Path parameter set" {
$warnings = Invoke-ScriptAnalyzer -Path $testFilePath
$warnings.Count | Should -Be 1 -Because 'PSSA should analyze the whole script after the parse error on [IStorageContext] and find the AvoidAlias warning due to gci'

This comment has been minimized.

@kalgiz

kalgiz Apr 5, 2018 Contributor

Same as above.

@kalgiz
kalgiz approved these changes Apr 5, 2018
bergmeister added 2 commits Apr 5, 2018
…nalyzer into AllowTypeNotFoundParserErrors
…nalyzer into AllowTypeNotFoundParserErrors
Copy link
Member

JamesWTruher left a comment

i think it's close, but we need a bit more discussion on this because I think it might be overreaching a bit.

else
{
this.outputWriter.WriteVerbose(
$"Ignoring 'TypeNotFound' parse error on type {parseError.Extent}, which is likely due to the type not being knowm due to e.g. 'using' statements. Parse error message was '{parseError.Message}'.");

This comment has been minimized.

@JamesWTruher

JamesWTruher Apr 9, 2018 Member

should this be a resource rather than a static string?

using namespace Microsoft.Azure.Commands.ResourceManager.Cmdlets.SdkModels
using namespace Microsoft.Azure.Commands.Common.Authentication.Abstractions
Import-Module "AzureRm"
class MyClass { [IStorageContext]$StorageContext } # This will result in a parser error due to [IStorageContext] type that comes from the using stetement but is not known at parse time

This comment has been minimized.

@JamesWTruher

JamesWTruher Apr 9, 2018 Member

typo - stetement should be statement.

It "does not throw and detect one expected warning after the parse error has occured when using -ScriptDefintion parameter set" {
$warnings = Invoke-ScriptAnalyzer -ScriptDefinition $script
$warnings.Count | Should -Be 1 -Because $assertionMessage
$warnings.RuleName | Should -Be 'PSAvoidUsingCmdletAliases' -Because $assertionMessage

This comment has been minimized.

@JamesWTruher

JamesWTruher Apr 9, 2018 Member

I know that there a bunch of these sorts of tests which check the message, but I'm not a fan. If we want to have tests for the message catalog, we can do that explicitly. Is there another way to check this? Checking a rulename is not subject to localization.

This comment has been minimized.

@bergmeister

bergmeister Apr 9, 2018 Author Collaborator

This is just checking for the rule type/name, not the message itself, the -Because operator is for specifying additional details in the assertion message why the test was expected to fail if it fails, not an assertion.

@@ -1522,16 +1522,18 @@ public IEnumerable<DiagnosticRecord> AnalyzeScriptDefinition(string scriptDefini
return null;
}

if (errors != null && errors.Length > 0)
var relevantParseErrors = RemoveTypeNotFoundParseErrors(errors);

This comment has been minimized.

@JamesWTruher

JamesWTruher Apr 9, 2018 Member

Should there be an escape hatch here? Is there a scenario where a user would like to see all of the parse errors? I have a feeling that this rule is actually useful (as it catches type errors like [System.Stirng]).

This comment has been minimized.

@bergmeister

bergmeister Apr 9, 2018 Author Collaborator

I see, good point. Maybe rather output a warning instead of a verbose message? Or even return a non-terminating error?
@tylerl0706 Does VSCode\PowerShellEditorServices do its own parsing or is it the PSSA errors that we see in the editor when the type is unknown/invalid?

This comment has been minimized.

@bergmeister

bergmeister Apr 10, 2018 Author Collaborator

I changed it to output a warning for the moment.

This comment has been minimized.

@edyoung

edyoung Apr 10, 2018 Contributor

The errors aren't terminating anyway, except that when you get too many of them PSSA gives up. When scanning some of the Azure packages for the gallery (https://dtlgalleryint.cloudapp.net/packages/AzSKStaging/3.1.2 is an example), we get about 4000 errors like this, so I'd really welcome some option to suppress them.

This comment has been minimized.

@bergmeister

bergmeister Apr 10, 2018 Author Collaborator

@edyoung Do you get other errors apart from the TypeNotFound error as well? This PR removes all of them and only outputs them as a warning instead. Yes, when there are more than 10 non-TypeNotFound, then PSSA will throw a terminating error. Maybe an environment variable to tweak this magic value? I cannot download your referenced module because it is not in the public PSGallery, sorry.

This comment has been minimized.

@edyoung

edyoung Apr 11, 2018 Contributor

I think it's fine to terminate parsing after 10 errors, but TypeNotFound issues not treated as errors shouldn't count towards that limit. Right now those are the only messages I get for that package but in general there will be other errors.

Actually you should be able to download that package if you like:

Register-PSRepository -Name GalleryRolling -SourceLocation https://dtlgalleryint.cloudapp.net/api/v2/ 
Save-Module -Repository GalleryRolling -Name AzSKStaging -AllowPreRelease -Path whatever

This comment has been minimized.

@edyoung

edyoung Apr 11, 2018 Contributor

I tried it with your branch, and the errors are converted to warnings as expected.

This comment has been minimized.

@bergmeister

bergmeister Apr 11, 2018 Author Collaborator

Yes, TypeNotFound does not count towards that limit, this PR changes it to exactly that, only a warning (like Write-Warning not a rule violation) is emitted to the console host. Thanks for the snippet.

This comment has been minimized.

@JamesWTruher

JamesWTruher Apr 11, 2018 Member

the problem with warnings/errors/et al, is that they're missed in output. Would an Information diagnostic record be ok? That way, they would be part of the output, but can easily be suppressed.

@JamesWTruher JamesWTruher merged commit ac22b0e into PowerShell:development May 11, 2018
2 checks passed
2 checks passed
continuous-integration/appveyor/pr AppVeyor build succeeded
Details
license/cla All CLA requirements met.
Details
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked issues

Successfully merging this pull request may close these issues.

4 participants
You can’t perform that action at this time.
X Tutup