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 binder gen compile issues due to inaccessible members and identifier name clashes #91657

Merged
merged 6 commits into from
Sep 7, 2023

Conversation

layomia
Copy link
Contributor

@layomia layomia commented Sep 6, 2023

Fixes #90909 and #90976. RC-2 candidate.

cc @ericstj.

@layomia layomia added this to the 8.0.0 milestone Sep 6, 2023
@layomia layomia self-assigned this Sep 6, 2023
@ghost
Copy link

ghost commented Sep 6, 2023

Tagging subscribers to this area: @dotnet/area-extensions-configuration
See info in area-owners.md if you want to be subscribed.

Issue Details

Fixes #90909 and #90976. RC-2 candidate.

cc @ericstj.

Author: layomia
Assignees: layomia
Labels:

area-Extensions-Configuration

Milestone: 8.0.0

@layomia layomia requested a review from tarekgh September 6, 2023 04:22
@layomia layomia force-pushed the binder-gen-formatting branch from 9d8783f to 832c9bb Compare September 6, 2023 20:58
@layomia
Copy link
Contributor Author

layomia commented Sep 7, 2023

CI failures unrelated; referenced above.

@@ -78,6 +80,27 @@ private static bool IsValidRootConfigType(ITypeSymbol? type)
}

return true;

static bool IsAccessibleFromGenBinders(ITypeSymbol type)
Copy link
Member

Choose a reason for hiding this comment

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

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I don't have a "within" symbol. The symbol would be the generated binder extension class which doesn't exist yet.

Copy link
Member

Choose a reason for hiding this comment

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

Couldn't you use another type symbol in the same assembly as a proxy for the one that will be generated?

Copy link
Member

@eiriktsarpalis eiriktsarpalis Sep 7, 2023

Choose a reason for hiding this comment

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

It should be possible to use the current IAssemblySymbol as the 'within' parameter although I haven't tested that myself.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yes I considered the proxy approach. It didn't feel deterministic on first thought, but yes it would be a correct/better check. I'll also try using the assembly symbol.

Copy link
Contributor Author

@layomia layomia Sep 12, 2023

Choose a reason for hiding this comment

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

Using a proxy would work in the common case, but we'd need to account for the assembly possibly having just one (e.g. a singular, simple target-config POCO with primitive fields). Any handwritten fallback would have a vastly different impl.

Comparing with assembly doesn't work - nested privates aren't visible.

Copy link
Member

Choose a reason for hiding this comment

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

Comparing with assembly doesn't work - nested privates aren't visible.

Are any of the types being generated nested within user-defined types? If not, I would expect its visibility to be equivalent to that of the assembly?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Comparing with assembly doesn't work - nested privates aren't visible.

I tried it again; the assembly check works. Must have not used the ! operator when I tried. Thanks.

@layomia
Copy link
Contributor Author

layomia commented Sep 7, 2023

Will address @eiriktsarpalis's feedback in a new PR before proposing an RC-2 backport with the two merged commits.

@layomia
Copy link
Contributor Author

layomia commented Sep 12, 2023

/backport to release/8.0

@github-actions
Copy link
Contributor

Started backporting to release/8.0: https://github.com/dotnet/runtime/actions/runs/6165475776

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Config binder generator generates uncompilable code when a private nested type is used
3 participants