Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Move minimum support to sdk 8 #295

Merged
merged 8 commits into from
Jan 13, 2025
Merged

Conversation

rjmurillo
Copy link
Owner

@rjmurillo rjmurillo commented Dec 20, 2024

For v1.0 release, Moq.Analyzers will move to support the latest stable .NET LTS SDK

Changes:

  • Updated Microsoft.CodeAnalysis.CSharp and Microsoft.CodeAnalysis.CSharp.Workspaces updated to 4.8. This is the earliest .NET 8 SDK we can support. See https://github.com/dotnet/roslyn/blob/main/docs/wiki/NuGet-packages.md?plain=1#L49
  • Removed unnecessary CancellationToken parameters in benchmark helper methods as a result of the package updates
  • Updated SDK to support roll-forward behavior. This is to work around having to keep up to patches on workstations (or worse, getting auto patched because of a CVE and having things fail)

Copy link

coderabbitai bot commented Dec 20, 2024

📝 Walkthrough

Walkthrough

This pull request encompasses updates across multiple configuration and project files, primarily focusing on version upgrades and SDK configuration. The changes include updating package versions for Microsoft CodeAnalysis packages to version 4.8, modifying the SDK roll-forward behavior in global.json, removing CancellationToken parameters from benchmark helper methods, and updating a project's target framework from .NET 8.0 to .NET 9.0. Additionally, new and removed rules in YAML files reflect changes in code analysis guidelines.

Changes

File Change Summary
Directory.Packages.props - Updated package versions for Microsoft.CodeAnalysis.CSharp.Workspaces and Microsoft.CodeAnalysis.CSharp from 4.3.1 to 4.8
- Minor documentation reference adjustments
global.json - Changed rollForward property from "disable" to "patch"
tests/Moq.Analyzers.Benchmarks/Helpers/BenchmarkCSharpCompilationFactory.cs - Removed CancellationToken.None parameter from WithAnalyzers method calls
tests/Moq.Analyzers.Benchmarks/Moq.Analyzers.Benchmarks.csproj - Updated target framework from net8.0 to net9.0
src/Analyzers/SquiggleCop.Baseline.yaml - Added new rule: CS1587 regarding XML comment placement
src/CodeFixes/SquiggleCop.Baseline.yaml - Removed multiple design and usage rules
tests/Moq.Analyzers.Benchmarks/SquiggleCop.Baseline.yaml - Removed specific diagnostic rules CA0419 and CS9216
tests/Moq.Analyzers.Test.Analyzers/SquiggleCop.Baseline.yaml - Removed numerous diagnostic rules related to code analysis

Possibly related PRs

Suggested labels

housekeeping


📜 Recent review details

Configuration used: CodeRabbit UI
Review profile: ASSERTIVE
Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 026824c and 8fc35c8.

📒 Files selected for processing (5)
  • Directory.Packages.props (1 hunks)
  • src/Analyzers/SquiggleCop.Baseline.yaml (1 hunks)
  • src/CodeFixes/SquiggleCop.Baseline.yaml (1 hunks)
  • tests/Moq.Analyzers.Benchmarks/SquiggleCop.Baseline.yaml (2 hunks)
  • tests/Moq.Analyzers.Test.Analyzers/SquiggleCop.Baseline.yaml (1 hunks)
⏰ Context from checks skipped due to timeout of 90000ms (1)
  • GitHub Check: build (windows-latest)
🔇 Additional comments (7)
Directory.Packages.props (1)

20-22: Verify package version compatibility and stability.

The update to Roslyn 4.8 is significant and introduces .NET 8 support. Please ensure:

  1. This version is stable and production-ready
  2. All dependent packages are compatible with this version
  3. The minimum VS 2022 17.8 requirement is documented in the project's requirements

Run this script to check package compatibility and version status:

✅ Verification successful

Package versions are properly aligned and stable

The update to Roslyn 4.8.0 (released Nov 2023) is stable and the package versions are correctly aligned:

  • Core packages are consistently at version 4.8
  • Analyzer packages are appropriately versioned at 3.11.0
  • Test packages use independent versioning as expected
🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Check if version 4.8 is stable and get its publish date
curl -s https://api.nuget.org/v3/registration5-semver1/microsoft.codeanalysis.csharp/index.json | jq '.items[].items[] | select(.catalogEntry.version=="4.8.0") | {version: .catalogEntry.version, published: .catalogEntry.published, isStable: (.catalogEntry.version | contains("-") | not)}'

# Find any package references to Microsoft.CodeAnalysis.* to verify version alignment
rg -l "Microsoft\.CodeAnalysis\." --type-add 'props:*.props' --type props

Length of output: 607


Script:

#!/bin/bash
# Check Microsoft.CodeAnalysis.* package versions in all props files
for file in Directory.Packages.props build/targets/tests/Packages.props build/targets/codeanalysis/CodeAnalysis.props build/targets/codeanalysis/Packages.props; do
    echo "=== $file ==="
    rg "Microsoft\.CodeAnalysis" "$file" -A 1
done

Length of output: 2642

tests/Moq.Analyzers.Test.Analyzers/SquiggleCop.Baseline.yaml (2)

315-315: Verify XML comment placement rule addition.

The addition of CS1587 (XML comment placement validation) seems appropriate but appears to be the only rule retained. Consider if this single rule is sufficient for XML documentation validation.

Let's check if there are other XML documentation related rules being enforced elsewhere:


Line range hint 1-314: Verify the impact of removing these code analysis rules.

The removal of over 300 code analysis rules, including critical security, performance, and design rules, could significantly impact code quality and security. While this might be part of moving to SDK 8, we should ensure that equivalent rules are enforced through other means.

Let's verify if these rules are replaced by newer alternatives:

✅ Verification successful

Analyzer configuration has been modernized and enhanced

The removal of rules from SquiggleCop.Baseline.yaml is part of a well-structured modernization of the code analysis setup. The project now uses:

  • Built-in .NET analyzers (EnableNETAnalyzers: true)
  • Multiple specialized analyzer packages (Meziantou, Roslynator, StyleCop, SonarAnalyzer, etc.)
  • Centralized configuration through .globalconfig
  • Preview analysis mode for enhanced rule coverage

The removed rules are effectively replaced by this more comprehensive and maintainable analysis configuration.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Check if there are other rule files that might contain replacement rules
fd --type f --extension yaml --extension json . | grep -i "rule\|analyz"

# Look for any documentation about rule migrations
fd --type f --extension md . | xargs rg -i "rule.*migrat|analyz.*migrat"

Length of output: 358


Script:

#!/bin/bash
# Compare the content of all SquiggleCop.Baseline.yaml files
for f in $(fd --type f --full-path SquiggleCop.Baseline.yaml); do
  echo "=== $f ==="
  head -n 5 "$f"
done

# Look for .editorconfig files that might contain the new rule configurations
fd --type f --full-path .editorconfig

# Search for SDK 8.0 related changes
rg -i "sdk.*8\.0|netcore.*8\.0|net8\.0" -g "!*.{yaml,md}"

Length of output: 6262


Script:

#!/bin/bash
# Look for build property files that might contain analyzer configurations
fd --type f "Directory.Build.props|Directory.Build.targets|global.json"

# Search for analyzer configuration in project files
rg -i "analyzer|ruleset" -g "*.csproj|*.props|*.targets"

# Look for any documentation about analyzer configuration
rg -i "analyzer.*config|ruleset.*config" -g "*.md|*.txt"

Length of output: 573


Script:

#!/bin/bash
# Check contents of build property files
echo "=== Root Directory.Build.props ==="
cat Directory.Build.props

echo -e "\n=== Root Directory.Build.targets ==="
cat Directory.Build.targets

echo -e "\n=== src/Directory.Build.props ==="
cat src/Directory.Build.props

echo -e "\n=== global.json ==="
cat global.json

# Fixed ripgrep search for analyzer configurations
echo -e "\n=== Searching for analyzer configurations in project files ==="
rg -i "analyzer|ruleset" "*.csproj" "*.props" "*.targets"

Length of output: 2065


Script:

#!/bin/bash
# Check the content of code analysis configuration files
echo "=== CodeAnalysis.props ==="
cat build/targets/codeanalysis/CodeAnalysis.props

echo -e "\n=== CodeAnalysis.targets ==="
cat build/targets/codeanalysis/CodeAnalysis.targets

# Look for any analyzer packages in project files
find . -name "*.csproj" -exec grep -l "Analyzer" {} \;

Length of output: 3803

src/Analyzers/SquiggleCop.Baseline.yaml (1)

315-315: LGTM! The new analyzer rule for XML comment validation is properly configured.

The addition of CS1587 rule will help maintain code quality by ensuring XML comments are placed on valid language elements.

src/CodeFixes/SquiggleCop.Baseline.yaml (2)

315-315: Addition of XML comment validation rule aligns with SDK 8 requirements.

The addition of CS1587 (XML comment validation) is appropriate as it helps maintain documentation quality.


Line range hint 1-314: Verify the impact of removing CA rules.

The removal of numerous CA rules (Microsoft's code analysis rules) could potentially lead to reduced code quality enforcement. Please ensure that:

  1. These rules are now handled by SDK 8's built-in analyzers
  2. The removal doesn't compromise the project's code quality standards

Let's verify if these rules are covered by SDK 8:

✅ Verification successful

Rule removals are aligned with SDK 8+ analyzer configuration

The removal of CA rules from the baseline is justified as these rules are now handled by the SDK's built-in analyzers, evidenced by:

  • Project uses .NET SDK 8+ with EnableNETAnalyzers set to true
  • Analysis mode is set to "preview" for latest rules
  • Extended analyzer rules are enforced
🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Check if removed rules are covered by SDK 8's built-in analyzers

# Search for any references to these rules in project files
rg -l "CA\d{4}" --type xml

# Check SDK 8 analyzer configuration
fd -e props -e targets | xargs rg "EnableNETAnalyzers|AnalysisLevel"

Length of output: 344


Script:

#!/bin/bash
# Check SDK version and analyzer configurations

# Look for SDK version in project files
fd -e csproj -e props | xargs rg "TargetFramework|LangVersion|AnalysisMode"

# Check for any other analyzer packages
fd -e csproj | xargs rg -i "analyzer|StyleCop|Roslyn"

Length of output: 4410

tests/Moq.Analyzers.Benchmarks/SquiggleCop.Baseline.yaml (1)

Line range hint 1-1000: LGTM! The removal of diagnostic rules aligns with SDK 8 migration.

The removal of the following diagnostic rules is appropriate for the SDK 8 migration:

  • CA0419 (Ambiguous reference in cref attribute)
  • CS9216 (Lock statement type conversion warning)

Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media?

❤️ Share
🪧 Tips

Chat

There are 3 ways to chat with CodeRabbit:

  • Review comments: Directly reply to a review comment made by CodeRabbit. Example:
    • I pushed a fix in commit <commit_id>, please review it.
    • Generate unit testing code for this file.
    • Open a follow-up GitHub issue for this discussion.
  • Files and specific lines of code (under the "Files changed" tab): Tag @coderabbitai in a new review comment at the desired location with your query. Examples:
    • @coderabbitai generate unit testing code for this file.
    • @coderabbitai modularize this function.
  • PR comments: Tag @coderabbitai in a new PR comment to ask questions about the PR branch. For the best results, please provide a very specific query, as very limited context is provided in this mode. Examples:
    • @coderabbitai gather interesting stats about this repository and render them as a table. Additionally, render a pie chart showing the language distribution in the codebase.
    • @coderabbitai read src/utils.ts and generate unit testing code.
    • @coderabbitai read the files in the src/scheduler package and generate a class diagram using mermaid and a README in the markdown format.
    • @coderabbitai help me debug CodeRabbit configuration file.

Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments.

CodeRabbit Commands (Invoked using PR comments)

  • @coderabbitai pause to pause the reviews on a PR.
  • @coderabbitai resume to resume the paused reviews.
  • @coderabbitai review to trigger an incremental review. This is useful when automatic reviews are disabled for the repository.
  • @coderabbitai full review to do a full review from scratch and review all the files again.
  • @coderabbitai summary to regenerate the summary of the PR.
  • @coderabbitai generate docstrings to generate docstrings for this PR. (Beta)
  • @coderabbitai resolve resolve all the CodeRabbit review comments.
  • @coderabbitai configuration to show the current CodeRabbit configuration for the repository.
  • @coderabbitai help to get help.

Other keywords and placeholders

  • Add @coderabbitai ignore anywhere in the PR description to prevent this PR from being reviewed.
  • Add @coderabbitai summary to generate the high-level summary at a specific location in the PR description.
  • Add @coderabbitai anywhere in the PR title to generate the title automatically.

CodeRabbit Configuration File (.coderabbit.yaml)

  • You can programmatically configure CodeRabbit by adding a .coderabbit.yaml file to the root of your repository.
  • Please see the configuration documentation for more information.
  • If your editor has YAML language server enabled, you can add the path at the top of this file to enable auto-completion and validation: # yaml-language-server: $schema=https://coderabbit.ai/integrations/schema.v2.json

Documentation and Community

  • Visit our Documentation for detailed information on how to use CodeRabbit.
  • Join our Discord Community to get help, request features, and share feedback.
  • Follow us on X/Twitter for updates and announcements.

@rjmurillo rjmurillo added dependencies Pull requests that update a dependency file releasable labels Dec 20, 2024
Copy link

codacy-production bot commented Dec 20, 2024

Coverage summary from Codacy

See diff coverage on Codacy

Coverage variation Diff coverage
+0.00% (target: -1.00%) (target: 95.00%)
Coverage variation details
Coverable lines Covered lines Coverage
Common ancestor commit (3a1f286) 724 633 87.43%
Head commit (8fc35c8) 724 (+0) 633 (+0) 87.43% (+0.00%)

Coverage variation is the difference between the coverage for the head and common ancestor commits of the pull request branch: <coverage of head commit> - <coverage of common ancestor commit>

Diff coverage details
Coverable lines Covered lines Diff coverage
Pull request (#295) 0 0 ∅ (not applicable)

Diff coverage is the percentage of lines that are covered by tests out of the coverable lines that the pull request added or modified: <covered lines added or modified>/<coverable lines added or modified> * 100%

See your quality gate settings    Change summary preferences

Codacy stopped sending the deprecated coverage status on June 5th, 2024. Learn more

Copy link

@codeclimate codeclimate bot left a comment

Choose a reason for hiding this comment

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

The PR diff size of 7257 lines exceeds the maximum allowed for the inline comments feature.

@rjmurillo rjmurillo requested a review from Copilot December 25, 2024 02:46

Choose a reason for hiding this comment

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

Copilot reviewed 6 out of 9 changed files in this pull request and generated no comments.

Files not reviewed (3)
  • Directory.Packages.props: Language not supported
  • global.json: Language not supported
  • tests/Moq.Analyzers.Benchmarks/Moq.Analyzers.Benchmarks.csproj: Language not supported
@rjmurillo rjmurillo marked this pull request as ready for review January 13, 2025 22:58
Copy link

codeclimate bot commented Jan 13, 2025

Code Climate has analyzed commit 8fc35c8 and detected 0 issues on this pull request.

View more on Code Climate.

Copy link

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

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

Actionable comments posted: 1

📜 Review details

Configuration used: CodeRabbit UI
Review profile: ASSERTIVE
Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 07c600e and 026824c.

📒 Files selected for processing (4)
  • Directory.Packages.props (1 hunks)
  • global.json (1 hunks)
  • tests/Moq.Analyzers.Benchmarks/Helpers/BenchmarkCSharpCompilationFactory.cs (2 hunks)
  • tests/Moq.Analyzers.Benchmarks/Moq.Analyzers.Benchmarks.csproj (1 hunks)
🧰 Additional context used
📓 Path-based instructions (1)
tests/Moq.Analyzers.Benchmarks/Helpers/BenchmarkCSharpCompilationFactory.cs (1)

Pattern **/*.cs: I need your help tracking down and fixing some bugs that have been reported in this codebase.

I suspect the bugs are related to:

  • Incorrect handling of edge cases
  • Off-by-one errors in loops or array indexing
  • Unexpected data types
  • Uncaught exceptions
  • Concurrency issues
  • Improper configuration settings

To diagnose:

  1. Review the code carefully and systematically
  2. Trace the relevant code paths
  3. Consider boundary conditions and potential error states
  4. Look for antipatterns that tend to cause bugs
  5. Run the code mentally with example inputs
  6. Think about interactions between components

When you find potential bugs, for each one provide:

  1. File path and line number(s)
  2. Description of the issue and why it's a bug
  3. Example input that would trigger the bug
  4. Suggestions for how to fix it

After analysis, please update the code with your proposed fixes. Try to match the existing code style. Add regression tests if possible to prevent the bugs from recurring.

I appreciate your diligence and attention to detail! Let me know if you need any clarification on the intended behavior of the code.

⏰ Context from checks skipped due to timeout of 90000ms (1)
  • GitHub Check: Codacy Static Code Analysis
🔇 Additional comments (4)
tests/Moq.Analyzers.Benchmarks/Helpers/BenchmarkCSharpCompilationFactory.cs (1)

21-22: Verify WithAnalyzers API compatibility with CancellationToken removal.

The removal of CancellationToken.None from WithAnalyzers calls might affect cancellation behavior. While this aligns with moving to SDK 8+, we should verify the API compatibility.

Also applies to: 40-42

✅ Verification successful

CancellationToken removal is safe in WithAnalyzers calls

The removal of CancellationToken.None is consistent with the codebase patterns:

  • All WithAnalyzers calls in the benchmarks follow this pattern
  • Changes are isolated to test infrastructure
  • Project already targets modern .NET SDK (8.0+)
🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Check WithAnalyzers API signatures in the codebase
rg -A 2 "WithAnalyzers.*CancellationToken" 

# Check for any existing usages that might be affected
rg -A 2 "CreateAsync.*CancellationToken"

Length of output: 87


Script:

#!/bin/bash
# Check for WithAnalyzers usage patterns
rg -l "WithAnalyzers"

# Check project SDK versions
fd -e csproj . --exec cat {}

# Look for test setup patterns
rg -A 3 "CompilationWithAnalyzers"

Length of output: 13140

Directory.Packages.props (1)

20-22: Verify package compatibility matrix.

The upgrade to Microsoft.CodeAnalysis 4.8 is appropriate for .NET 8 support, but we should verify compatibility with other dependencies.

✅ Verification successful

Package compatibility verified successfully

The upgrade to Microsoft.CodeAnalysis 4.8 is compatible with:

  • All project target frameworks (netstandard2.0, net8.0, net9.0)
  • Related Microsoft.CodeAnalysis packages (3.11.x family)
  • VS 2022 17.8 as intended
🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Check for any version constraints or conflicts
rg -l "Microsoft\.CodeAnalysis" | xargs cat | rg "Version|PackageReference"

# Check for any direct dependencies on these packages
rg --type=csproj -l "Microsoft\.CodeAnalysis\.CSharp"

Length of output: 5030


Script:

#!/bin/bash
# Find and examine .csproj files and their contents
fd -e csproj --exec cat {}

# Check for target framework versions
fd -e props -e csproj | xargs cat | rg "TargetFramework"

# Look for any compatibility-related configuration
fd -e props -e csproj | xargs cat | rg -i "support|compatible|require"

Length of output: 8815

global.json (1)

3-4: Verify .NET 9 SDK requirement.

The project is using .NET 9.0.100 SDK with patch-level roll-forward. Since .NET 9 is in preview:

  1. This might introduce instability
  2. Consider staying on .NET 8 until .NET 9 is released
✅ Verification successful

Using .NET 9 SDK is appropriate for this analyzer project

The .NET 9 SDK usage is justified as this is a Roslyn analyzer project (Moq.Analyzers) that needs to maintain compatibility with upcoming .NET versions. The patch-level roll-forward policy is also appropriate for development tooling.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Check for .NET SDK version requirements across the solution
rg -l "net9" | xargs cat | rg "TargetFramework|RuntimeIdentifier"

# Check for any preview package dependencies
cat Directory.Packages.props | rg "preview|beta|alpha"

Length of output: 447


Script:

#!/bin/bash
# Check project type and purpose
fd -e csproj | xargs cat | rg -A 2 "ProjectTypeGuids|OutputType|PackageId"

# Check for analyzer/SDK development indicators
rg -l "Microsoft\.CodeAnalysis" | xargs cat | rg "using Microsoft\.CodeAnalysis|ISourceGenerator|ISyntaxReceiver"

Length of output: 2151

tests/Moq.Analyzers.Benchmarks/Moq.Analyzers.Benchmarks.csproj (1)

5-5: Verify package compatibility with .NET 9.

While upgrading the test project to .NET 9 is less risky, we should verify that all package dependencies support this version:

  • BenchmarkDotNet
  • Microsoft.CodeAnalysis packages
  • Microsoft.CodeAnalysis.AnalyzerUtilities
✅ Verification successful

Dependencies are compatible with .NET 9

The benchmark project's dependencies are compatible with .NET 9:

  • BenchmarkDotNet 0.13.12 has .NET 9 support
  • Microsoft.CodeAnalysis packages are build-time only (PrivateAssets="all")
  • Microsoft.CodeAnalysis.AnalyzerUtilities is using a .NET 9 compatible beta version
🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Check package versions and their .NET support
cat Directory.Packages.props | rg "PackageVersion.*Include=\"(BenchmarkDotNet|Microsoft\.CodeAnalysis)"

# Look for any framework-specific conditions
rg "net9" --type=csproj

Length of output: 496


Script:

#!/bin/bash
# Search for csproj files and their content
find . -name "*.csproj" -exec cat {} \;

# Look for framework-specific conditions in all files
rg "Condition.*net9|net9.*Condition" --type-add 'proj:*.{csproj,props,targets}' --type=proj

Length of output: 8143

Directory.Packages.props Show resolved Hide resolved
@rjmurillo rjmurillo merged commit 2544518 into main Jan 13, 2025
10 checks passed
@rjmurillo rjmurillo deleted the move-minimum-support-to-SDK-8 branch January 13, 2025 23:07
@rjmurillo rjmurillo added this to the vNext milestone Jan 13, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
dependencies Pull requests that update a dependency file releasable
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant