Avoid using closure in Parser.SaveError

[daxian-dbw]

PR Summary

Avoid using closure in Parser.SaveError.

Context

Generally, Parser.SaveError shouldn't be called too frequently in production, because the script running in production should have been correct and generate no parsing error.
However, I saw the following call stack in Azure Profiler Viewer for PowerShell Gallery-Prod service:

Parser.SaveError takes about 43.56% of the CPU activities in the web server process w3wp.exe, and the call originates from NuGetGallery.Views.ScriptParsingAndHighlighting!Parse

Given the finding, I took a look at the implementation of Parser.SaveError and notice that it's using closure and LINQ unnecessarily. Especially, the closure use will cause allocation every time this method is called.
As for why PowerShellGallery triggers so many parsing errors, it's because it's parsing non-powershell files using powershell parser, which is wrong and will be fixed.

PR Checklist

• PR has a meaningful title
  • Use the present tense and imperative mood when describing your changes
• Summarized changes
• Make sure all .h, .cpp, .cs, .ps1 and .psm1 files have the correct copyright header
• This PR is ready to merge and is not Work in Progress.
  • If the PR is work in progress, please add the prefix WIP: or [ WIP ] to the beginning of the title (the WIP bot will keep its status check at Pending while the prefix is present) and remove the prefix when the PR is ready.
• Breaking changes
  • None
  • OR
  • Experimental feature(s) needed
    • Experimental feature name(s):
• User-facing changes
  • Not Applicable
  • OR
  • Documentation needed
    • Issue filed:
• Testing - New and feature
  • N/A or can only be tested interactively
  • OR
  • Make sure you've added a new test if existing tests do not effectively test the code changed
• Tooling
  • I have considered the user experience from a tooling perspective and don't believe tooling will be impacted.
  • OR
  • I have considered the user experience from a tooling perspective and enumerated concerns in the summary. This may include:
    • Impact on PowerShell Editor Services which is used in the PowerShell extension for VSCode (which runs in a different PS Host).
    • Impact on Completions (both in the console and in editors) - one of PowerShell's most powerful features.
    • Impact on PSScriptAnalyzer (which provides linting & formatting in the editor extensions).
    • Impact on EditorSyntax (which provides syntax highlighting with in VSCode, GitHub, and many other editors).

[adityapatwardhan]

@PoshChan Please remind me in 4 hours.

[ghost]

Hello @adityapatwardhan!

Because this pull request has the AutoMerge label, I will be glad to assist with helping to merge this pull request once all check-in policies pass.

Do note that I've been instructed to only help merge pull requests of this repository that have been opened for at least 24 hours, a condition that will be fulfilled in about 4 hours 7 minutes. No worries though, I will be back when the time is right! 😉

p.s. you can customize the way I help with merging this pull request, such as holding this pull request until a specific person approves. Simply @mention me (@msftbot) and give me an instruction to get started! Learn more here.

[PoshChan]

@adityapatwardhan, this is the reminder you requested 4 hours. ago

[ghost]

🎉v7.0.0-preview.6 has been released which incorporates this pull request.:tada:

Handy links:

• Release Notes