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

Implement lambda params with modifiers without type name #69273

Closed

Conversation

Rekkonnect
Copy link
Contributor

@Rekkonnect Rekkonnect commented Jul 28, 2023

@dotnet-issue-labeler dotnet-issue-labeler bot added Area-Compilers untriaged Issues and PRs which have not yet been triaged by a lead labels Jul 28, 2023
@ghost ghost added the Community The pull request was submitted by a contributor who is not a Microsoft employee. label Jul 28, 2023
@CyrusNajmabadi
Copy link
Member

@dotnet/roslyn-compiler @jaredpar i approved making this PR (as draft) as the corresponding proposal champion. The intent is not to take this in (at least until LDM approval), but instead to just see the scope of the change needed to support this lang change. Thanks!

@Rekkonnect Rekkonnect changed the title Implement by-ref lambda params without type name Implement lambda params with modifiers without type name Aug 1, 2023
int firstDefault = -1;
for (int i = 0; i < lambda.ParameterCount; i++)
var paramSyntax = lambda.ParameterSyntax(i);
if (paramSyntax is not null)
Copy link
Member

Choose a reason for hiding this comment

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

Why can paramSyntax be null? If the lambda has non-zero ParameterCount I would expect it to have corrsponding parameter syntaxes.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

It can be null in some tests for parameters with modifiers without parameter parentheses (e.g. ref x => x), which is illegal per the spec. Without the underlying changes, now permitting the null parameter syntax, the assertion would fail.

Since the modifiers are not allowed in single-parameter unparenthesized lambda expressions, we need to at least expect the case to arise.

Copy link
Member

Choose a reason for hiding this comment

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

i don't really get it either. i would not expect any sort of lambda to have a nulll parameter syntax.

Copy link
Member

Choose a reason for hiding this comment

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

Since the modifiers are not allowed in single-parameter unparenthesized lambda expressions, we need to at least expect the case to arise.

this sentence doesn't make sense. Just because the modifiers are not legal doesn't mean you get a null parameter syntax.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Made changes to preserve this, but kept the removal of the check about having an explicitly typed parameter list. To circumvent breaks, lambda binding data for simple lambda expressions (parameters without parentheses) now contain a singleton separated syntax list of parameter syntaxes.

@Rekkonnect Rekkonnect marked this pull request as ready for review April 6, 2024 17:41
@Rekkonnect Rekkonnect requested a review from a team as a code owner April 6, 2024 17:41
@jaredpar jaredpar added this to the Backlog milestone Sep 5, 2024
@@ -779,7 +779,8 @@ public static void M(ref readonly int x) { }
Diagnostic(ErrorCode.ERR_CantConvAnonMethParams, "=>").WithArguments("lambda expression", "System.Linq.Expressions.Expression<D>").WithLocation(7, 28),
// (8,49): error CS1615: Argument 1 may not be passed with the 'out' keyword
// Expression<Action<int>> e5 = (int p) => C.M(out p);
Diagnostic(ErrorCode.ERR_BadArgExtraRef, "p").WithArguments("1", "out").WithLocation(8, 49));
Diagnostic(ErrorCode.ERR_BadArgExtraRef, "p").WithArguments("1", "out").WithLocation(8, 49)
Copy link
Member

Choose a reason for hiding this comment

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

revert please.

@CyrusNajmabadi
Copy link
Member

FYI, i did my open implementation of this PR here: #75400

It comes with a large test suite, including many cases not handled by this PR. We can attempt to bring this one forward, or we can go with #75400.

@Rekkonnect
Copy link
Contributor Author

Yours seems cleaner and refactors some code that I don't remember touching in my PR, so I think it's better to roll with yours. Perhaps bring some of the tests from this one into the other PR if they prove useful and cover a wider range.

I don't really have a strong opinion with this implementation as it wasn't as structured, but rather patchy. Feel free to use whatever parts are necessary, including the tests.

@Rekkonnect
Copy link
Contributor Author

Closing in favor of #75400

@Rekkonnect Rekkonnect closed this Nov 28, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area-Compilers Community The pull request was submitted by a contributor who is not a Microsoft employee. untriaged Issues and PRs which have not yet been triaged by a lead
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants