Skip to content

Support Roslyn 1.x/2.x compiler configurations in tests on non-Windows - #3914

Merged
siegfriedpammer merged 2 commits into
masterfrom
linux-test-matrix
Jul 27, 2026
Merged

siegfriedpammer merged 2 commits into
masterfrom
linux-test-matrix

Conversation

@siegfriedpammer

@siegfriedpammer siegfriedpammer commented Jul 26, 2026

Copy link
Copy Markdown
Member

Enables the Roslyn 1.3.2 and 2.10.0 compiler configurations of the decompiler test matrix on non-Windows platforms, and makes the vbc 2.10 / netcore-2.2 combination compile there:

  • Roslyn 2.10.0 runs via the dotnet-hosted Microsoft.NETCore.Compilers sibling package (tools/bincore/csc.dll, --roll-forward LatestMajor).
  • Roslyn 1.3.2 runs through mono; since the native DiaSymReader is unavailable there, GeneratePdb requests portable PDBs on non-Windows (Roslyn 2.x+ already falls back on its own). The 1.3.2 configurations stay in the matrix even when Mono is missing from the PATH and report the missing runtime via Assert.Ignore at compile time, so a box or CI image that loses Mono shows skipped tests instead of a silently smaller matrix.
  • vbc 2.10 with the netcore-2.2 reference set needs the C#-side reference list (vbc does not follow type forwards for special types) and the legacy desktop Microsoft.VisualBasic.dll as -vbruntime (no Microsoft.VisualBasic.Core.dll before .NET Core 3.0). Referencing the target framework's own Microsoft.VisualBasic facade alongside that is a BC32210 identity conflict, so it is dropped from the reference list. Two VBPretty fixtures (Issue2192, VBNonGenericForEach) produce different output under the substituted VB runtime and are ignored on non-Windows for the netcore-2.2 configuration, with a comment explaining why.
  • mcs stays excluded from the non-Windows matrix: the bundled mcs 2.6.4 needs the Reflection.Emit COMPILER_ACCESS mode that current Mono runtimes no longer implement.

Verified on Linux (Fedora, mono 6.x): full ICSharpCode.Decompiler.Tests suite passes with the enabled matrix (3006 passed / 0 failed / 42 skipped); the VBPretty suite goes from 18 failures (all UseRoslyn2_10_0) to green. Windows behavior is unchanged.

Follow-up (separate ILSpy-tests bump): add Microsoft.NETCore.Compilers-2.10.0.nupkg to ILSpy-tests/nuget so the non-Windows fetch stays offline-capable; it currently falls back to nuget.org.

This PR was prepared by an AI agent (Claude) on behalf of @siegfriedpammer.

🤖 Generated with Claude Code

Copilot AI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

This PR expands the decompiler test compiler-matrix to support Roslyn 1.x/2.x configurations on non-Windows hosts by switching Roslyn 2.10 to the dotnet-hosted toolset, optionally enabling Roslyn 1.3 under Mono, and adjusting VB and PDB handling to work cross-platform.

Changes:

  • Fetch Roslyn 2.10 from Microsoft.NETCore.Compilers on non-Windows, add dotnet --roll-forward LatestMajor, and run .exe compilers via mono when applicable.
  • Adjust VB compilation references/runtime handling for the non-Windows netcoreapp2.2 configuration, and skip two VBPretty fixtures whose output differs under the substituted runtime.
  • Request portable PDBs for Roslyn on non-Windows and tweak the reference-assembly list for netcoreapp2.2.

Reviewed changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated 1 comment.

File Description
ICSharpCode.Decompiler.Tests/VBPrettyTestRunner.cs Skips two VBPretty tests on non-Windows Roslyn 2.10 + non-net40 due to VB runtime substitution affecting output.
ICSharpCode.Decompiler.Tests/Helpers/Tester.VB.cs Updates VB reference selection and -vbruntime handling for non-Windows netcoreapp2.2 to avoid identity conflicts and missing runtime assemblies.
ICSharpCode.Decompiler.Tests/Helpers/Tester.cs Adds non-Windows Roslyn 2.10 toolset selection, Mono detection, cross-platform compiler wrapping, portable PDB selection, and reference list tweaks.
ICSharpCode.Decompiler.Tests/Helpers/RoslynToolset.cs Improves compiler-path selection to support both dotnet-hosted and Mono-hosted Roslyn toolsets on non-Windows.
Comments suppressed due to low confidence (1)

ICSharpCode.Decompiler.Tests/Helpers/Tester.cs:205

  • This XML doc says Roslyn 1.x/2.x and mcs are removed on non-Windows unless Mono is available, but SupportedOnCurrentPlatform currently always excludes mcs and does not require Mono for Roslyn 2.10 (it runs dotnet-hosted). Please update the comment to match the actual filtering logic.
		/// depend on Windows-only tools or runtimes are removed: the legacy (pre-Roslyn) csc/vbc
		/// and Force32Bit (requires a 32-bit runtime) always; Roslyn 1.x/2.x (their packages only
		/// ship .NET Framework binaries) and mcs unless a Mono runtime is available to host them.

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

Comment thread ICSharpCode.Decompiler.Tests/Helpers/Tester.cs Outdated
The Roslyn 1.3.2 and 2.10.0 configurations were excluded from the
compiler matrix on non-Windows platforms because Microsoft.Net.Compilers
only ships .NET Framework executables. Both can be enabled:

- Roslyn 2.10.0 has a dotnet-hosted sibling package,
  Microsoft.NETCore.Compilers, whose tools/bincore/csc.dll runs on the
  installed runtime with --roll-forward LatestMajor (its runtimeconfig
  pins the out-of-support .NET Core 2.0). Fetched on non-Windows into
  the version's tools/bincore directory; GetCSharpCompiler probes for a
  direct csc.dll next to the installed path in addition to the
  bincore/ subfolder layout of the newer toolset packages.
- Roslyn 1.3.2 has no .NET build; when a mono executable is found on
  the PATH, it is kept in the matrix and WrapCompiler hosts the .exe
  compilers through mono. Because the native DiaSymReader needed for
  Windows PDBs is unavailable there, GeneratePdb requests portable
  PDBs on non-Windows (Roslyn 2.x+ falls back on its own, 1.x needs
  the explicit -debug:portable).

The mcs configurations stay excluded: the bundled mcs 2.6.4 needs the
Reflection.Emit COMPILER_ACCESS mode that current Mono runtimes no
longer implement. Old-compiler configurations also stay excluded from
correctness-style fixtures: their output targets .NET Framework or
.NET Core 2.2, which the runners cannot execute here.
Microsoft.NETCore.Compilers-2.10.0.nupkg should be added to
ILSpy-tests/nuget to keep the fetch offline-capable.

Assisted-by: Claude:claude-fable-5:Claude Code
The netcore-2.2 reference set consists of the shared framework's facade
assemblies split across many files, and vbc only binds special types
like System.Void from an assembly that defines them rather than
following type forwards, so without an implicit SDK it needs the same
reference list as the C# side. The VB runtime must come from the legacy
reference set: before .NET Core 3.0 there is no
Microsoft.VisualBasic.Core.dll and the core build of the VB runtime is
a trimmed-down subset (no UBound etc.). Referencing the target
framework's own Microsoft.VisualBasic facade alongside that -vbruntime
choice is a BC32210 identity conflict, so it is dropped from both the
default reference list and the ReferenceVisualBasic flag handling.
All of this applies only where vbc runs without its implicit desktop
SDK path, i.e. off Windows; on Windows vbc.exe keeps the plain
reference list that already worked.

Assisted-by: Claude:claude-fable-5:Claude Code
@siegfriedpammer
siegfriedpammer merged commit ecc1583 into master Jul 27, 2026
13 checks passed
@siegfriedpammer
siegfriedpammer deleted the linux-test-matrix branch July 27, 2026 16:25
siegfriedpammer added a commit that referenced this pull request Jul 31, 2026
The dotnet-hosted Roslyn 2.10 build cannot start its VBCSCompiler server
under a current dotnet host, so with /shared every test compilation first
waited out the client's full 20-second new-server connection timeout
before falling back to a sub-second in-process compile. Since the 2.10
configurations were enabled on non-Windows (#3914), that added ~29
minutes to the Linux CI job and ~43 minutes on macOS: ~340 affected
tests at ~21s each, versus ~0.2s for the toolsets whose server works.

Assisted-by: Claude:claude-fable-5:Claude Code
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants