ForeEach-Object -Parallel using variable processing walks the script block AST to determine if the using variable was defined in the current scope, and does this by tracking the number of 'ForEach-Object -Parallel' commands in the call chain.
However, the provided script block is different, depending on whether it is passed in as a variable or via parameter binding.
$myScript = '"Hello!"'
1 | ForEach-Object -Parallel ([scriptblock]::Create($myScript))
# Script block Ast does not contain the 'ForEach-Object' command in the call chain
1 | ForEach-Object -Parallel { "Hello!" }
# Script block Ast does contain the 'ForEach-Object' command in the call chain
This change takes into account the two forms of script blocks
Major changes are:
- Make all commands return 'ConfirmImpact.None' if `SupportsShouldProcess` is not set to `true`.
- Update some cmdlets to explicitly use `ConfirmImpact.Low`.
- Update `DefaultCommands.Tests.ps1` to test for 'ConfirmImpact' level.
Consolidation of all Windows PowerShell work ported to PSCore6
* Added ps1 file import restriction. Refactored InvokeLanguageModeTestingSupportCmdlet to HelpersSecurity module
* JEA loop back fix. Debugger running commands in CL mode.
* Support for new AMSI codes. Changed to use AMSI buffer API. Unhandled exception fix.
* Fixes for module bugs while running in ConstrainedLanguage mode
* Untrusted input tracking work
* Configuration keyword bug fix, PSRP protocol version check for reconstruct reconnect, Sharing InitialSessionState in runspace pool.
* Restricted remote session in UMCI, Applocker detection collision, Help command exposing functions, Null reference exception fix.
* Added mitigation for debugger function exposure
Dynamic (DLR) objects work in some places today, but not others. This change expands that support to ForEach-Object, Where-Object and the family of cmdlets that use 'MshExpression' (Select-Object, etc.).
This change addresses both wildcard and non-wildcard cases. In wildcard cases, it uses the existing support of generating PSDynamicMember objects for names returned by GetDynamicMemberNames.
In non-wildcard cases, a dynamic property access is attempted whether or not the name shows up in GetDynamicMemberNames, but a truly "blind" access is only attempted if we see that the base object is an IDMOP. If the dynamic access fails, you'll get the same or a similar error experience as before ("The property 'Blarg' cannot be found", or no error at all, depending on the cmdlet and the strict mode setting).
The included test coverage includes a stub for the.ForEach operator--once people are happy with this change, I can continue by adding support there.
This change should allegedly also have positive perf impact, though in actual perf testing, although it does seem ever-so-slightly faster, I found it difficult to measure much difference at all.
Based on standard practices, we need to have a copyright and license notice at the top of each source file. Removed existing copyrights and updated/added copyright notices for .h, .cpp, .cs, .ps1, and .psm1 files.
Updated module manifests for consistency to have Author = "PowerShell" and Company = "Microsoft Corporation". Removed multiple line breaks.
Separate PR coming to update contribution document for new source files: #6140
Manually reviewed each change.
Fix#6073
Our private implementation of FailFast was likely introduced
when each individual application needed it's own code to
get Watson reports. The CLR takes care of this for us now,
so we don't need our implementation.
Our method CheckForSevereException was also introduced in
the early days of the CLR - the exceptions it was checking
for aren't actually raised the CLR anymore, they just FailFast.
I removed them as there is a tiny bit of overhead (in code size)
and also in the generated code, e.g. dynamic sites called the method.
This exception is no longer used by PowerShell, so it has been removed.
It is a public api, so removing it risks breaking somebody. Nobody has any reason
to catch or throw this exception, so it seems safe to remove, but I decided to
be conservative and keep it for Windows PowerShell. It seems safe enough to remove
in Nano.
Dongbo Wang