Uh oh!
There was an error while loading. Please reload this page.
Fix binder gen compile issues due to inaccessible members and identifier name clashes - #91657
Conversation
ghost
commented
Sep 6, 2023
Tagging subscribers to this area: @dotnet/area-extensions-configuration |
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
9d8783f to
832c9bbComparelayomia
commented
Sep 7, 2023
CI failures unrelated; referenced above. |
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
| return true; | ||
| static bool IsAccessibleFromGenBinders(ITypeSymbol type) |
There was a problem hiding this comment.
Couldn't you use IsSymbolAccessibleWithin instead?
There was a problem hiding this comment.
I don't have a "within" symbol. The symbol would be the generated binder extension class which doesn't exist yet.
There was a problem hiding this comment.
Couldn't you use another type symbol in the same assembly as a proxy for the one that will be generated?
There was a problem hiding this comment.
It should be possible to use the current IAssemblySymbol as the 'within' parameter although I haven't tested that myself.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
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
commented
Sep 12, 2023
/backport to release/8.0 |
Started backporting to release/8.0: https://github.com/dotnet/runtime/actions/runs/6165475776 |
Fixes#90909 and #90976. RC-2 candidate.
cc @ericstj.