fix: NestedSelectExprTest and update documentation

[arika0093]

Update the Issue207_NestedSelectExprTest to support partial classes and remove .NET 9 specific warnings. Revise documentation for Nested SelectExpr to clarify its beta status and eliminate the .NET 9+ recommendation.

close #211

Summary by CodeRabbit

• Documentation
  • Refreshed nested SelectExpr documentation with clearer, more detailed explanations
  • Updated GitHub issue reporting guidance for streamlined support and feedback
  • Expanded guidance on empty partial class declarations and when they're beneficial
  • Clarified that DTOs can be placed anywhere in your codebase, removing location constraints

_{✏️ Tip: You can customize this high-level summary in your review settings.}

[coderabbitai]

Walkthrough

Documentation updated to simplify beta warnings and clarify DTO placement flexibility. Test file restructured as partial class with forward partial DTO declarations and NET9.0_OR_GREATER guard removed, enabling unconditional compilation of NestedSelectExpr tests.

Changes

Cohort / File(s)	Summary
Documentation Updates docs/library/nested-selectexpr.md	Simplified beta feature warning to GitHub issue reporting. Expanded rationale for empty partial class declarations with Roslyn evaluation details. Updated DTO Location description to reflect flexible placement ("Anywhere you want"). Removed .NET Version row from Nested SelectExpr Basic Usage table.
Test Restructuring tests/Linqraft.Tests/Issue207_NestedSelectExprTest.cs	Converted test class to partial. Removed NET9.0_OR_GREATER preprocessor guard for unconditional compilation. Added public partial forward declarations for NestedEntity207Dto and NestedItem207Dto DTO types.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~12 minutes

• Documentation rewording and table restructuring are straightforward content updates
• Test class conversion to partial and forward DTO declarations follow a clear pattern
• No complex logic changes or multi-file dependencies to verify

Possibly related issues

• bug: Test case Issue207 does not work properly on older environments only #211: Changes directly address DTO forward-declarations and removal of NET9 guard in Issue207_NestedSelectExprTest, enabling Roslyn-based evaluation and broader runtime compatibility.

Possibly related PRs

• Implement nested SelectMany support in DTO generation #81: Both touch Nested SelectExpr test handling and introduce partial DTO declarations to support Roslyn-based nested Select/SelectMany generation behavior.
• Enhance SelectExpr handling for generic and predefined DTOs #83: Related through SelectExpr handling for predefined/explicit DTO types; this PR's forward partial DTO declarations support the generator changes in that PR.
• docs: add Nested SelectExpr documentation for reusable DTOs #225: Modifies the same documentation file (docs/library/nested-selectexpr.md) for Nested SelectExpr guidance.

Poem

🐰 A partial class hops into place,
DTOs declared with forward grace,
Guards removed, the tests run free,
On any .NET, wild as can be!
Docs clarified, placement now bright—
SelectExpr nestles just right! 🌟

Pre-merge checks and finishing touches

✅ Passed checks (3 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title accurately summarizes the main changes: fixing the NestedSelectExprTest class structure (making it partial) and updating documentation for Nested SelectExpr.
Docstring Coverage	✅ Passed	Docstring coverage is 100.00% which is sufficient. The required threshold is 80.00%.

✨ Finishing touches

• 📝 Generate docstrings

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch fix/test-i207-support-all-platforms

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 0

🧹 Nitpick comments (2)

tests/Linqraft.Tests/Issue207_NestedSelectExprTest.cs (1)

150-152: Public partial DTO declarations align with the test intent; verify they match generator output

Declaring NestedEntity207Dto and NestedItem207Dto as public partial inside the test class is a good fit for:

• Exercising the “user‑defined partial DTO + generated part” scenario.
• Keeping these DTOs in the Linqraft.Tests namespace, as asserted later in the test.

One thing to confirm: the source generator’s partial definitions for these DTOs must use the same accessibility (public) and type shape, otherwise you’ll hit partial‑type accessibility mismatches. It might also be worth adding a short comment above these declarations indicating they’re stubs for the generator to avoid confusion for future readers.

docs/library/nested-selectexpr.md (1)

154-159: Consider slightly clarifying “Anywhere you want” in the comparison table

The updated DTO Location value (“Anywhere you want”) correctly reflects that DTOs are generated where you place the partial declarations, not in the LinqraftGenerated_HASH namespace. You might consider a slightly more precise phrasing such as:

Wherever you declare the DTO partial (any namespace/class)

to make it unambiguous that “anywhere” means “wherever the partial type lives”.

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 64b9787 and 12e70f4.

📒 Files selected for processing (2)

• docs/library/nested-selectexpr.md (3 hunks)
• tests/Linqraft.Tests/Issue207_NestedSelectExprTest.cs (2 hunks)

🧰 Additional context used

🧠 Learnings (10)

📚 Learning: 2025-11-25T12:08:35.849Z

Learnt from: CR
Repo: arika0093/Linqraft PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-11-25T12:08:35.849Z
Learning: Add test cases for source generators to `tests/Linqraft.Tests/`

Applied to files:

• tests/Linqraft.Tests/Issue207_NestedSelectExprTest.cs
• docs/library/nested-selectexpr.md

📚 Learning: 2025-11-25T12:08:35.849Z

Learnt from: CR
Repo: arika0093/Linqraft PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-11-25T12:08:35.849Z
Learning: Applies to src/Linqraft/DummyExpression.cs : Do not edit `DummyExpression.cs`; it serves only as a marker for the Source Generator

Applied to files:

• tests/Linqraft.Tests/Issue207_NestedSelectExprTest.cs
• docs/library/nested-selectexpr.md

📚 Learning: 2025-11-25T12:08:35.849Z

Learnt from: CR
Repo: arika0093/Linqraft PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-11-25T12:08:35.849Z
Learning: Applies to src/Linqraft.Core/**/*.cs : Keep helper methods lightweight and focused; helper methods are called frequently during analysis

Applied to files:

• tests/Linqraft.Tests/Issue207_NestedSelectExprTest.cs
• docs/library/nested-selectexpr.md

📚 Learning: 2025-11-25T12:08:35.849Z

Learnt from: CR
Repo: arika0093/Linqraft PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-11-25T12:08:35.849Z
Learning: Applies to src/Linqraft.Core/**/*Helper.cs : Document complex helper methods with XML comments

Applied to files:

• docs/library/nested-selectexpr.md

📚 Learning: 2025-11-25T12:08:35.849Z

Learnt from: CR
Repo: arika0093/Linqraft PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-11-25T12:08:35.849Z
Learning: Applies to src/Linqraft.Core/**/*.cs : Cache expensive operations in helper methods when possible

Applied to files:

• docs/library/nested-selectexpr.md

📚 Learning: 2025-11-25T12:08:35.849Z

Learnt from: CR
Repo: arika0093/Linqraft PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-11-25T12:08:35.849Z
Learning: Applies to src/Linqraft.Analyzer/**/*Analyzer.cs : All new analyzers should inherit from `BaseLinqraftAnalyzer`

Applied to files:

• docs/library/nested-selectexpr.md

📚 Learning: 2025-11-25T12:08:35.849Z

Learnt from: CR
Repo: arika0093/Linqraft PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-11-25T12:08:35.849Z
Learning: Applies to src/Linqraft.{Analyzer,Core}/**/*.cs : Always prefer semantic analysis over string matching; use `RoslynTypeHelper` instead of string-based type checking

Applied to files:

• docs/library/nested-selectexpr.md

📚 Learning: 2025-11-25T12:08:35.849Z

Learnt from: CR
Repo: arika0093/Linqraft PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-11-25T12:08:35.849Z
Learning: Applies to src/Linqraft.Core/SyntaxHelpers/*.cs : Syntax helpers should be placed in `Linqraft.Core/SyntaxHelpers/` and named `*Helper.cs`

Applied to files:

• docs/library/nested-selectexpr.md

📚 Learning: 2025-11-25T12:08:35.849Z

Learnt from: CR
Repo: arika0093/Linqraft PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-11-25T12:08:35.849Z
Learning: Applies to src/Linqraft.{Analyzer,Core}/**/*.cs : Use `ISymbolEqualityComparer` for symbol comparisons in analyzer code

Applied to files:

• docs/library/nested-selectexpr.md

📚 Learning: 2025-11-25T12:08:35.849Z

Learnt from: CR
Repo: arika0093/Linqraft PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-11-25T12:08:35.849Z
Learning: Applies to src/Linqraft.Core/RoslynHelpers/*.cs : Roslyn helpers should be placed in `Linqraft.Core/RoslynHelpers/` and named `Roslyn*Helper.cs`

Applied to files:

• docs/library/nested-selectexpr.md

🧬 Code graph analysis (1)

tests/Linqraft.Tests/Issue207_NestedSelectExprTest.cs (1)

tests/Linqraft.Tests/Issue217_NestedSelectExprTest.cs (1)

• Issue_NestedSelectExprTest (6-67)

🔇 Additional comments (3)

tests/Linqraft.Tests/Issue207_NestedSelectExprTest.cs (1)

11-11: Partial test class looks appropriate; just ensure multi-target builds still pass

Making Issue207_NestedSelectExprTest partial is consistent with the pattern of letting generated/other partial definitions live alongside the hand-written part, and the unconditional [Fact] nicely drops the .NET 9–only restriction. Please just double‑check that all target frameworks you build for can still compile and run this test with the NestedSelectExpr generator enabled (no language-version or generator assumptions leaking in).

docs/library/nested-selectexpr.md (2)

10-11: Beta warning wording is clear and actionable

The shortened beta note reads well and gives users a direct action (file an issue on GitHub). This is a good simplification without losing important context.

---

41-44: Expanded rationale for empty partials is helpful and technically accurate

The explanation of Roslyn treating undeclared DTOs as an unknown type and the resulting ambiguity in generation location very nicely justifies the “declare all DTO partials” requirement. This should significantly reduce confusion for users reading the docs.