Skip to content

generate valid, runtime-resolvable names for tuple-typed parameters - #92

Open
koenbeuk wants to merge 1 commit into
mainfrom
fix/tuple-parameter-naming
Open

generate valid, runtime-resolvable names for tuple-typed parameters#92
koenbeuk wants to merge 1 commit into
mainfrom
fix/tuple-parameter-naming

Conversation

@koenbeuk

@koenbeuk koenbeuk commented Aug 2, 2026

Copy link
Copy Markdown
Collaborator

No description provided.

Copilot AI review requested due to automatic review settings August 2, 2026 01:29
@codecov

codecov Bot commented Aug 2, 2026

Copy link
Copy Markdown

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

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 addresses tuple-typed parameters in ExpressiveSharp’s naming/lookup pipeline so generated expression factory members have stable, valid identifiers and can be resolved consistently at runtime (including cases where tuple syntax/element names differ from reflection-visible ValueTuple forms).

Changes:

  • Adds integration and generator tests covering tuple-typed parameters (including nested/named tuple scenarios in generator compilation).
  • Updates generator-side parameter type display formatting to expand tuples as ValueTuple<...> for runtime-aligned naming.
  • Broadens identifier sanitization to treat any non-alphanumeric/underscore as invalid when generating class/method suffixes.

Reviewed changes

Copilot reviewed 5 out of 5 changed files in this pull request and generated 3 comments.

Show a summary per file
File Description
tests/ExpressiveSharp.IntegrationTests/Tests/TupleParameterTests.cs Adds a runtime integration test for expanding an expression that calls an [Expressive] method with a tuple parameter.
tests/ExpressiveSharp.Generator.Tests/ExpressiveGenerator/TupleParameterTests.cs Adds generator tests asserting generated output compiles for tuple and nested/named tuple parameter types.
src/ExpressiveSharp/Services/ExpressionClassNameGenerator.cs Makes type-name sanitization more robust so generated identifiers don’t include invalid characters (e.g., tuple syntax punctuation).
src/ExpressiveSharp.Generator/Interpretation/ExpressiveInterpreter.cs Introduces a tuple-expanded SymbolDisplayFormat intended to align compile-time names with runtime reflection naming.
src/ExpressiveSharp.Generator/Interpretation/ExpressiveForInterpreter.cs Switches [ExpressiveFor] parameter type display to the shared tuple-expanded runtime name format.

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

Comment on lines +12 to +16
// Tuples must render as ValueTuple<...> so compile-time names match what the runtime
// resolver derives from reflection (which never sees tuple syntax or element names).
internal static readonly SymbolDisplayFormat RuntimeNameFormat =
SymbolDisplayFormat.FullyQualifiedFormat.AddMiscellaneousOptions(
SymbolDisplayMiscellaneousOptions.ExpandValueTuple);
Comment on lines 481 to 486
// Parameter types disambiguate method overloads in the registry; properties and parameterless targets keep ParameterTypeNames null.
if (!targetParameters.IsEmpty)
{
descriptor.ParameterTypeNames = targetParameters
.Select(p => p.Type.ToDisplayString(SymbolDisplayFormat.FullyQualifiedFormat))
.Select(p => p.Type.ToDisplayString(ExpressiveInterpreter.RuntimeNameFormat))
.ToList();
Comment on lines +20 to +24
public static class TupleParameterFixtures
{
[Expressive]
public static int First((int, int) pair) => pair.Item1;
}
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