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

Fix code generation for Durable Functions function-based syntax. #47

Merged
merged 4 commits into from
Sep 23, 2022

Conversation

jviau
Copy link
Member

@jviau jviau commented Sep 22, 2022

This PR addresses 2 issues with function based syntax code gen for Durable Functions:

  1. Functions returning Task<T> would get double nested as Task<Task<T>>
  2. Functions using custom types would not resolve their fully qualified namespace, leading to compilation issues.

resolves #35

@jviau jviau requested a review from cgillum September 22, 2022 18:49
Copy link
Member

@cgillum cgillum left a comment

Choose a reason for hiding this comment

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

LGTM!

@jviau jviau requested a review from cgillum September 22, 2022 21:48
@jviau
Copy link
Member Author

jviau commented Sep 22, 2022

@cgillum I found another case to fully qualify the type name.

Copy link
Member

@cgillum cgillum left a comment

Choose a reason for hiding this comment

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

I took a slightly deeper look this time through and have a few more questions that didn't come up from earlier iterations.

{
this.FullTypeName = fullTypeName;
this.RequiredNamespaces = requiredNamespaces;
this.Name = name;
this.Kind = kind;
this.Parameter = parameter;
this.ReturnType = returnTypeSyntax;
this.ReturnType = SyntaxNodeUtility.GetRenderedTypeExpression(returnType, false);
Copy link
Member

Choose a reason for hiding this comment

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

Does this false mean we don't support nullable annotations in return types?

return false;
}

if (!SyntaxNodeUtility.TryGetQualifiedTypeName(model, method, out string? fullTypeName))
{
function = null;
return false;
}
Copy link
Member

Choose a reason for hiding this comment

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

Would it make sense to move the TryGetParameter and TryGetQualifiedName checks further up, above the new return type code you added? Could that short-circuiting help save some CPU cycles or do we very rarely expect those methods to return false?

{
return false;
}

if (toProcess is not PredefinedTypeSyntax && typeInfo.Type.ContainingNamespace.IsGlobalNamespace)
if (typeInfo.ContainingNamespace.IsGlobalNamespace)
{
requiredNamespaces = null;
return false;
Copy link
Member

Choose a reason for hiding this comment

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

I know you didn't write this code, but is it correct for us to bail like this if we encounter a global namespace? Why wouldn't we continue to process remaining types in the remaining list?

string expression = symbol.ToString();
if (expression.StartsWith("System.") && symbol.ContainingNamespace.Name == "System")
{
expression = expression.Substring("System.".Length);
Copy link
Member

Choose a reason for hiding this comment

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

We do this because the System namespace is implicitly imported by the compiler?

@jviau
Copy link
Member Author

jviau commented Sep 23, 2022

I have opened #48 to track the comments here and other improvements to the generator.

@jviau jviau merged commit b79f77b into microsoft:main Sep 23, 2022
@jviau jviau deleted the fix-func-gen branch September 23, 2022 22:30
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.

The type of namespace could not be found for POCO input and outputs
2 participants