If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/dotnet/roslyn shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

GO — Healthy across the board

• Last commit 1d ago
• 13 active contributors
• Distributed ownership (top contributor 47% of recent commits)
• MIT licensed
• CI configured
• Tests present

_{Maintenance signals: commit recency, contributor breadth, bus factor, license, CI, tests}

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live dotnet/roslyn repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/dotnet/roslyn.

What it runs against: a local clone of dotnet/roslyn — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in dotnet/roslyn | Confirms the artifact applies here, not a fork | | 2 | License is still MIT | Catches relicense before you depend on it | | 3 | Default branch main exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 31 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of dotnet/roslyn. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/dotnet/roslyn.git
#   cd roslyn
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of dotnet/roslyn and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "dotnet/roslyn(\\.git)?\\b" \\
  && ok "origin remote is dotnet/roslyn" \\
  || miss "origin remote is not dotnet/roslyn (artifact may be from a fork)"

# 2. License matches what RepoPilot saw
(grep -qiE "^(MIT)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"MIT\"" package.json 2>/dev/null) \\
  && ok "license is MIT" \\
  || miss "license drift — was MIT at generation time"

# 3. Default branch
git rev-parse --verify main >/dev/null 2>&1 \\
  && ok "default branch main exists" \\
  || miss "default branch main no longer exists"

# 4. Critical files exist
test -f "Directory.Build.props" \\
  && ok "Directory.Build.props" \\
  || miss "missing critical file: Directory.Build.props"
test -f "Directory.Packages.props" \\
  && ok "Directory.Packages.props" \\
  || miss "missing critical file: Directory.Packages.props"
test -f ".github/CODEOWNERS" \\
  && ok ".github/CODEOWNERS" \\
  || miss "missing critical file: .github/CODEOWNERS"
test -f "README.md" \\
  && ok "README.md" \\
  || miss "missing critical file: README.md"
test -f "CONTRIBUTING.md" \\
  && ok "CONTRIBUTING.md" \\
  || miss "missing critical file: CONTRIBUTING.md"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 31 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~1d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/dotnet/roslyn"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

Roslyn is the open-source .NET Compiler Platform providing production C# and Visual Basic compilers with rich code analysis APIs. It enables IDE features (like IntelliSense, refactoring, and diagnostics) and tooling by exposing the compiler's syntax trees, semantic analysis, and symbol information as public APIs that anyone can build upon. Monorepo structure: src/Compilers/ contains the core C# and VB compilers; src/Analyzers/ holds diagnostic rules; src/Features/ provides IDE services (completion, refactoring); src/LanguageServer/ implements LSP support; src/Workspaces/ abstracts project/solution metadata; .devcontainer/ enables repeatable setup; .azuredevops/ orchestrates CI across Windows/Linux.

C# and VB.NET developers building static analysis tools, IDE extensions, code generators, and linters. Core Roslyn team members and external contributors maintain the compiler itself; tool builders (analyzer authors, VS extension developers) consume the public APIs to inspect and transform code.

Highly mature and production-ready: this is the official Microsoft compiler for C# and Visual Basic since VS 2015. The repository has 244 MB of C# and 76 MB of VB.NET code, comprehensive CI/CD pipelines (.azuredevops/), and is actively maintained with frequent releases tied to .NET runtime cycles.

Low risk for consumption (the API surface is stable), but moderate risk for contribution: the compiler is security-critical infrastructure, so breaking changes are rare and review cycles are rigorous. The large codebase (300MB+ code) and intricate symbol resolution logic create a steep learning curve. Single-version dependency risk since it ships with .NET SDKs.

Active development aligned with C# language releases (currently tracking C# 13+). The .github/instructions/ folder indicates organized tracks for Compiler, IDE, and Razor features. Copilot integration setup (.github/copilot/) suggests AI-assisted code review. Azure DevOps dependabot automation (.azuredevops/dependabot.yml) shows continuous dependency management.

Clone and restore: git clone https://github.com/dotnet/roslyn && cd roslyn && dotnet build. Prerequisites: .NET SDK (version in global.json), Visual Studio or VS Code (devcontainer supported). See .devcontainer/restore-workspace.sh for automated setup.

Daily commands: Build and test: dotnet build src/Compilers/CSharp/csc/csc.csproj to compile csc.exe. Run tests: dotnet test src/Compilers/CSharp/Test/Syntax/ for unit tests. Integration tests via dotnet test on full src/Compilers/ tree. No dev server—this is a compiler, not a web app.

• Directory.Build.props — Master project properties file that controls compilation settings, package versions, and build behavior across all 600+ projects in the Roslyn solution.
• Directory.Packages.props — Central NuGet package version management for the entire repository—critical for understanding dependency versions and compatibility matrices.
• .github/CODEOWNERS — Defines code ownership and review requirements; essential for navigating PR review processes and understanding who maintains specific compiler components.
• README.md — Entry point documenting Roslyn as the .NET compiler platform with C# and VB analysis APIs; required reading for understanding project scope and contribution guidelines.
• CONTRIBUTING.md — Contribution guidelines covering PR process, coding standards, and workflow—mandatory for any code changes to the compiler or analyzer infrastructure.
• .editorconfig — Enforces coding style, formatting, and conventions across C# and VB compiler code; violations block PR merges in CI.
• Roslyn.slnx — Main solution manifest for the entire Roslyn compiler, analyzers, and IDE components—the entry point for loading the codebase in Visual Studio.

Add a New Diagnostic Analyzer Rule

1. Review analyzer-suggestion.md to understand the proposal template and requirements (.github/ISSUE_TEMPLATE/analyzer-suggestion.md)
2. Use the analyzer-codefix SKILL guide to understand the analyzer architecture and API surface (.github/skills/analyzer-codefix/SKILL.md)
3. Create a new analyzer class in the appropriate DiagnosticAnalyzer directory following the naming convention {RuleId}Analyzer.cs (.github/CODEOWNERS)
4. Implement the analyzer using the Roslyn semantic analysis APIs and register diagnostic rules with unique IDs (.github/instructions/Compiler.instructions.md)
5. Add corresponding code fix provider in {RuleId}CodeFixProvider.cs with automated fixes (.github/skills/analyzer-codefix/SKILL.md)
6. Add unit tests following existing test patterns in the analyzer test project (.github/CODEOWNERS)
7. Verify formatting and code style compliance via .editorconfig rules before submitting PR (.editorconfig)

Implement a New C# Language Feature

1. Review the new-compiler-feature SKILL guide to understand the compiler pipeline and feature implementation process (.github/skills/new-compiler-feature/SKILL.md)
2. Check Compiler.instructions.md for feature specification requirements and parser/lexer integration points (.github/instructions/Compiler.instructions.md)
3. Add lexer tokens and keywords to the C# language lexer if required (Roslyn.slnx)
4. Extend the C# parser to handle new syntax and generate appropriate syntax tree nodes (.github/instructions/Compiler.instructions.md)
5. Implement semantic binding and type checking in the binder for the new construct (.github/skills/new-compiler-feature/SKILL.md)
6. Add compiler tests (parsing, binding, code generation) to the language feature test suite (.github/CODEOWNERS)
7. Update IDE support in IDE.instructions.md for IntelliSense, refactoring, and other IDE features (.github/instructions/IDE.instructions.md)

Debug and Fix a Compiler or Analyzer Regression

1. Review the CI analysis SKILL guide to understand how to retrieve and analyze build logs and test failures (.github/skills/ci-analysis/SKILL.md)
2. Check pr-validation.yml to understand which tests were run and what diagnostics are available (.github/workflows/pr-validation.yml)
3. Use binlog-comparison.md reference to compare successful vs. failed compiler builds (.github/skills/ci-analysis/references/binlog-comparison.md)
4. Locate the failing component using CODEOWNERS to identify relevant maintainers and file organization (.github/CODEOWNERS)
5. Create a minimal reproduction test case following the test patterns in the relevant test project (.github/skills/integration-test-analysis/SKILL.md)
6. Fix the issue in the appropriate compiler or analyzer code file (.github/instructions/Compiler.instructions.md)
7. Verify the fix locally using Build.cmd, then submit PR for validation (Build.cmd)

Set Up Local Development Environment

1. Clone the repository and review CONTRIBUTING.md for development workflow requirements (CONTRIBUTING.md)
2. Use .devcontainer/devcontainer.json to set up a containerized dev environment or manually install prerequisites (.devcontainer/devcontainer.json)
3. Run Restore.cmd to restore NuGet packages and project dependencies as defined in Directory.Packages.props (Restore.cmd)
4. Load Roslyn.slnx in Visual Studio or use the appropriate .slnf filter for your component area (Roslyn.slnx)
5. Configure VS Code settings and extensions using .vscode/settings.json and .vscode/extensions.json if using VS Code (.vscode/settings.json)
6. Run Build.cmd to verify the build succeeds and all tests pass (Build.cmd)

• C# and Visual Basic (.NET languages) — Roslyn IS the compiler for these languages; written in C# to dogfood the language and align with .NET ecosystem
• Immutable data structures (syntax trees, semantic models) — Enable safe concurrent analysis, efficient incremental updates, and snapshot-based IDE responsiveness
• Azure DevOps Pipelines + GitHub Actions — Multi-platform CI/CD for Windows/Linux/macOS, integration with Microsoft's internal infrastructure and open-source best practices
• Language Server Protocol (LSP) — Standardized protocol for IDE integration across Visual Studio, VS Code, and other editors without reimplementing analysis
• .NET Framework + .NET Core — Support legacy desktop applications and modern cloud workloads; dual-target strategy ensures broad compatibility

• Monolithic repository with 600+ projects instead of split packages

  • Why: Enables tight coordination of compiler, analyzers, IDE, and Razor components; simplifies version alignment and integration testing
  • Consequence: Larger clone size and build times; slower CI feedback loop; requires stronger code review discipline

• Immutable syntax tree nodes prevent in-place mutation

  • Why: undefined
  • Consequence: undefined

Green/red tree immutability is non-obvious—syntax nodes are immutable; updating trees rebuilds parents. Symbol binding performs expensive semantic walks; caching via ConcurrentDictionary is critical. MSBuild integration in Workspaces requires proper project file setup to discover compilation contexts. Tests use snapshot files (.txt) for output comparison; regenerating snapshots requires manual review. DevContainer Dockerfile pins .NET SDK version; updating requires careful validation.

• Green and Red Trees — Roslyn's dual-tree immutable syntax model enables efficient incremental parsing and caching; understanding immutability and red-tree parent updates is essential for parser modifications
• SemanticModel and Symbol Binding — SemanticModel bridges syntax trees to semantic information (types, members); binder performs multi-pass resolution critical for IDE features like IntelliSense and refactoring
• Diagnostic Descriptors and Rules — Roslyn diagnostics (compiler errors, warnings, analyzer rules) follow a standardized ImmutableArray<DiagnosticDescriptor> pattern; understanding descriptor scoping and message formatting is required for adding new rules
• Workspaces API (Solution/Project/Document abstraction) — Decouples IDE tooling from low-level compilation; abstracts MSBuild project system so analyzers and refactorings work across VS, VS Code, and other clients
• Language Server Protocol (LSP) Integration — Roslyn's LSP bridge (src/LanguageServer/) enables the same compiler analysis across any editor supporting LSP; semantic tokens, diagnostics, and code actions flow through this protocol
• Incremental Generators and Source Generators — C# source generators (compile-time code generation via ISourceGenerator) run during compilation; understanding how generators hook into Roslyn's pipeline is critical for meta-programming and modern .NET tooling
• Recursive Descent Parsing and Precedence Climbing — Roslyn's parser (Parser.cs, Lexer.cs) uses recursive descent with operator precedence handling; understanding token lookahead and backtracking is essential for fixing parser bugs or adding syntax

• dotnet/csharplang — Separate repo for C# language design discussions and feature proposals; Roslyn implements accepted LDM decisions
• dotnet/vblang — Companion repo for Visual Basic language design; Roslyn is the production VB compiler
• dotnet/runtime — The .NET runtime that Roslyn compiles code for; runtime metadata and type system inform Roslyn's symbol binding
• microsoft/vs-streamline-clang-tools — Example of Roslyn API usage: integrates C++ analyzer patterns with C# compiler infrastructure
• dotnet/csharpier — Community code formatter built on Roslyn's syntax trees and SemanticModel; demonstrates public API leverage

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Add comprehensive skill documentation index and navigation

The .github/skills directory contains 9 specialized skills (analyzer-codefix, ci-analysis, code-review, etc.) with SKILL.md files and references, but there's no central index or navigation guide. New contributors struggle to discover which skill applies to their task. Creating a skills/README.md with a matrix of skills, use-cases, and prerequisites would dramatically improve onboarding for contributors working on compiler features, CI analysis, or IDE improvements.

• [ ] Create .github/skills/README.md with a table mapping each skill to: purpose, target audience, prerequisites, and link to SKILL.md
• [ ] Add decision tree or flowchart helping contributors identify relevant skills (e.g., 'Working on C# language feature?' → new-compiler-feature skill)
• [ ] Cross-reference skills from .github/instructions/*.md files (Compiler.instructions.md, IDE.instructions.md, Razor.instructions.md) to relevant skills
• [ ] Document any dependencies between skills (e.g., ci-analysis → binlog-comparison reference)

Add missing Copilot instructions for Compiler domain

The .github/copilot-instructions.md and .github/copilot/settings.json exist as entry points, but there's no compiler-specific Copilot instruction file parallel to the existing .github/instructions/Compiler.instructions.md. Given that Roslyn is a compiler project with complex semantic analysis, adding copilot-compiler-instructions.md would help AI-assisted code generation for compiler-related PRs (syntax trees, symbol analysis, diagnostics).

• [ ] Create .github/copilot-compiler-instructions.md with patterns for: working with SyntaxTree/SyntaxNode APIs, writing analyzers, symbol table lookups, and diagnostic generation
• [ ] Reference existing .github/instructions/Compiler.instructions.md for context and domain-specific patterns
• [ ] Include examples of common compiler tasks (e.g., 'How to add a new diagnostic', 'How to implement syntax analysis for a feature')
• [ ] Update .github/copilot/settings.json to include reference to new compiler instructions

Document devcontainer setup troubleshooting and validation

.devcontainer/Dockerfile and devcontainer.json exist, and there's a restore-workspace.sh script, but no troubleshooting guide or validation checklist for contributors using devcontainers. Roslyn's complex build system (multiple languages, SDKs, dependencies) makes devcontainer setup fragile. Adding .devcontainer/TROUBLESHOOTING.md and a validation script would reduce setup failures for new contributors using Docker-based development.

• [ ] Create .devcontainer/TROUBLESHOOTING.md documenting: common setup failures (Docker daemon issues, permission errors, disk space), SDK version mismatches, and Windows vs Linux container gotchas
• [ ] Create .devcontainer/validate-setup.sh script that checks: Docker daemon running, .NET SDK versions, Git config, workspace permissions, and devinit.json requirements
• [ ] Update .devcontainer/README.md (or create if missing) with link to TROUBLESHOOTING.md and instructions to run validate-setup.sh post-init
• [ ] Document in devinit.json comments which tools are optional vs required for different contributor workflows (compiler-only vs IDE-only)

• Add missing unit tests for edge cases in src/Compilers/CSharp/Portable/Syntax/Parser.cs for recent C# 13 nullable reference annotation syntax.
• Implement a new diagnostic analyzer in src/Analyzers/CSharp/Analyzers/ for detecting unused using statements when external NuGet references change, then add test cases in src/Analyzers/CSharp/Tests/.
• Document the symbol table caching strategy and binder lifecycle in docs/wiki/ with a concrete example of how SemanticModel resolves a method call; include code paths through Binder.cs.

The Roslyn repository demonstrates a generally sound security posture with established security policies and proper vulnerability reporting channels via MSRC. No critical vulnerabilities were identified in the visible configuration and structure. Primary areas for improvement include: 1) Formal review of GitHub Actions workflows for secret management and permission scoping, 2) Verification of Dockerfile security hardening in development containers, 3) Audit of PowerShell scripts for input validation, and 4) Continuous scanning of dependencies for known vulnerabilities. The repository follows Microsoft's

• Low · Dependency Management Configuration Exposed — .azuredevops/dependabot.yml. The .azuredevops/dependabot.yml file is present in the repository, which may contain dependency update configurations. While not inherently dangerous, it should be reviewed to ensure sensitive package sources or credentials are not embedded in the configuration. Fix: Review the dependabot configuration to ensure no credentials or sensitive package sources are hardcoded. Use Azure DevOps secrets management for any required credentials.
• Low · Development Container Configuration Review Needed — .devcontainer/Dockerfile, .devcontainer/devcontainer.json. The .devcontainer/Dockerfile and related configuration files are present. Development containers may contain security configurations that could be insecure if not properly reviewed (e.g., running as root, exposing unnecessary ports, or including debug tools in production paths). Fix: Review Dockerfile for: 1) Running as non-root user, 2) Minimal base image, 3) Proper secret handling (no secrets in layers), 4) Up-to-date base images. Ensure devcontainer.json doesn't expose unnecessary ports or mount sensitive directories.
• Low · Git Configuration Files Present — .git-blame-ignore-revs, .gitattributes. Files like .git-blame-ignore-revs and .gitattributes are present. While these are standard Git configuration files, .git-blame-ignore-revs should be reviewed to ensure it doesn't mask security-relevant commits. Fix: Verify that .git-blame-ignore-revs doesn't contain commits that introduced security vulnerabilities or that its purpose is legitimate (e.g., formatting changes).
• Low · GitHub Actions Workflows Require Security Review — .github/workflows/*.yml. Multiple GitHub Actions workflows are present (.github/workflows/). These workflows could potentially contain security risks such as: insecure secret handling, privilege escalation, or execution of untrusted code. Fix: Review all workflow files for: 1) Proper secret management (use GitHub Secrets, not hardcoded), 2) Pinned action versions (not using 'latest' or untagged commits), 3) Proper permission scoping, 4) No use of potentially dangerous permissions like 'write-all'.
• Low · Copilot and AI Configuration Present — .github/copilot/, .github/copilot-instructions.md. GitHub Copilot configuration files are present (.github/copilot/settings.json, .github/copilot-instructions.md). These files may contain instructions or patterns that could potentially lead to insecure code generation if not properly configured. Fix: Review Copilot instructions to ensure they promote secure coding practices and don't contain patterns that could lead to security vulnerabilities. Keep instructions updated with current security best practices.
• Low · PowerShell Scripts in DevOps Skills — .github/skills/*/scripts/*.ps1. Multiple PowerShell scripts are present in .github/skills/*/scripts/. PowerShell scripts can pose security risks if they execute with elevated privileges or contain unvalidated input. Fix: Review all PowerShell scripts for: 1) Input validation, 2) Proper error handling, 3) Execution policy requirements, 4) No unquoted variables in dangerous contexts, 5) Use of approved verbs.
• Informational · No Package Dependencies Provided for Analysis — Dependencies/Package files. The dependency file content section was empty, so it was not possible to analyze for known vulnerable packages or dependency-related security issues. Fix: Provide package files (packages.config, .csproj, nuspec, or similar) for automated vulnerability scanning. Regularly scan dependencies using tools like NuGet Package Vulnerability Scanner or Snyk.

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.