Support calling methods with ByRef-like type parameters in PowerShell, as long as the argument specified for the parameter can be implicitly/explicitly converted to the ByRef-like type.
We cannot create an instance of a ByRef-like type in PowerShell, but there are types that can be implicitly or explicitly converted to ByRef-like types, such as `T[] -> Span<T>`, `T[] -> ReadOnlySpan<T>`, `String -> ReadOnlySpan<T>`. `ArraySegment<T> -> Span<T>`, `ArraySegment<T> -> ReadOnlySpan<T>`. With changes in this PR, we can call methods with ByRef-like parameter types by providing the arguments of the types that can be cast to the target ByRef-like type.
**What is enabled?**
1. Invoking methods that have ByRef-like parameters, but the return type is not ByRef-like.
2. Invoking constructors with ByRef-like parameters via `[target-type]::new` syntax, but the `target-type` is not ByRef-like.
3. Accessing indexers that have ByRef-like parameters, but the return type is not ByRef-like.
Provide a tab completion attribute (ArgumentEncodingCompletionsAttribute) for an Encoding parameter.
This PR should fix the duplicated code warning in CodeFactor
The variable was set to empty (meaning to delete the variable) in the non-preview case and the build fails.
The fix avoids setting the variable to empty
The variable was set to empty (meaning to delete the variable) in the non-preview case and the build fails.
The fix avoids setting the variable to empty
Add the functionality to build a framework dependent (shared framework) package for PowerShell.
The changes create two packages, one for Windows and other for Linux, due to #if code.
Add the functionality to build a framework dependent (shared framework) package for PowerShell.
The changes create two packages, one for Windows and other for Linux, due to #if code.
This change updates ModuleIntrinsics.GetModulePath to handle the case where the Windows PowerShell module path is already in the environment's PSModulePath or when launched from a different version of PowerShell.
Previously, GetModulePath would append $PSHOME\Modules to the PSModulePath after removing the path for the launching version without considering the Windows PowerShell module path. The result, was the Windows PowerShell modules were found first and loaded incompatible modules; such as the built-in modules.
The change detects the Windows PowerShell module path and inserts $PSHOME\Modules path before it. The new test simulates launching from a different version of pwsh that has already added the Windows PowerShell module path.
Fixes#7679
Add daily build non-windows platforms
- Also, make the [Feature] tag work in VSTS for non-windows
- Also, add a way to force feature tests to run
- Also, fix an issue where `-workingdirectory` didn't work when running async
Fixes underlying problem of #3341. Related: #2881
When multiple versions (e.g. RTM and preview) of PowerShell are installed via the MSI and one is being uninstalled, then the start menu shortcut does not get removed due to the shortcut component being not unique per version. This also applies to an upgrade scenario. Therefore use an auto-generated Guid (`*`)
Add daily build non-windows platforms
- Also, make the [Feature] tag work in VSTS for non-windows
- Also, add a way to force feature tests to run
- Also, fix an issue where `-workingdirectory` didn't work when running async
Fixes underlying problem of #3341. Related: #2881
When multiple versions (e.g. RTM and preview) of PowerShell are installed via the MSI and one is being uninstalled, then the start menu shortcut does not get removed due to the shortcut component being not unique per version. This also applies to an upgrade scenario. Therefore use an auto-generated Guid (`*`)
