Skip to content

Fix binder gen compile issues due to inaccessible members and identifier name clashes - #91657

Merged
layomia merged 6 commits into
dotnet:mainfrom
layomia:binder-gen-formatting
Sep 7, 2023
Merged

Fix binder gen compile issues due to inaccessible members and identifier name clashes#91657
layomia merged 6 commits into
dotnet:mainfrom
layomia:binder-gen-formatting

Conversation

@layomia

Copy link
Copy Markdown
Contributor

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

cc @ericstj.

@layomialayomia added this to the 8.0.0 milestone Sep 6, 2023
@layomialayomia self-assigned this Sep 6, 2023
@ghost

ghost commented Sep 6, 2023

Copy link
Copy Markdown

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 tarekghSeptember 6, 2023 04:22
Comment threadsrc/libraries/Common/src/SourceGenerators/TypeModelHelpers.cs Outdated
Comment threadsrc/libraries/Common/src/SourceGenerators/TypeModelHelpers.cs Outdated
Comment threadsrc/libraries/Common/src/SourceGenerators/TypeModelHelpers.cs Outdated
Comment threadsrc/libraries/Common/src/SourceGenerators/TypeModelHelpers.cs Outdated
@layomia
layomiaforce-pushed the binder-gen-formatting branch from 9d8783f to 832c9bbCompareSeptember 6, 2023 20:58
@layomia

Copy link
Copy Markdown
ContributorAuthor

CI failures unrelated; referenced above.

Comment threadsrc/libraries/Common/src/SourceGenerators/TypeModelHelper.cs

return true;

static bool IsAccessibleFromGenBinders(ITypeSymbol type)

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Copy link
Copy Markdown
ContributorAuthor

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
Copy Markdown
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?

@eiriktsarpaliseiriktsarpalisSep 7, 2023

Copy link
Copy Markdown
Member

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
Copy Markdown
ContributorAuthor

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.

@layomialayomiaSep 12, 2023

Copy link
Copy Markdown
ContributorAuthor

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
Copy Markdown
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
Copy Markdown
ContributorAuthor

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
Copy Markdown
ContributorAuthor

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

@layomia

Copy link
Copy Markdown
ContributorAuthor

/backport to release/8.0

@github-actions

Copy link
Copy Markdown
Contributor

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

Sign up for freeto 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

@layomia@eiriktsarpalis@tarekgh
, 'i'); if (__m === '*' || __re.test(location.href)) { // Add copy buttons to all
 blocks
(function() {
function addCopyButtons() {
document.querySelectorAll('pre code').forEach(function(codeBlock) {
if (codeBlock.parentElement.hasAttribute('data-copy-added')) return;
codeBlock.parentElement.setAttribute('data-copy-added', 'true');
var btn = document.createElement('button');
btn.textContent = 'Copy';
btn.style.cssText = 'position:absolute;top:4px;right:4px;padding:2px 8px;font-size:11px;background:#4ecdc4;border:none;border-radius:4px;color:#1a1a2e;cursor:pointer;opacity:0.7;transition:opacity 0.2s;';
btn.onmouseover = function() { this.style.opacity = '1'; };
btn.onmouseout = function() { this.style.opacity = '0.7'; };
btn.onclick = function() {
navigator.clipboard.writeText(codeBlock.textContent).then(function() {
btn.textContent = 'Copied!';
setTimeout(function() { btn.textContent = 'Copy'; }, 1500);
});
};
codeBlock.parentElement.style.position = 'relative';
codeBlock.parentElement.appendChild(btn);
});
}
addCopyButtons();
// Re-run on dynamic content
var observer = new MutationObserver(addCopyButtons);
observer.observe(document.body, { childList: true, subtree: true });
})();
}
} catch(__e) { console.warn('[Userscript:Add Copy Buttons to Code Blocks]', __e); }
})();
(function(){
try {
var __m = "github.com";
var __re = new RegExp('^' + "github\\.com" + '
Fix binder gen compile issues due to inaccessible members and identifier name clashes by layomia · Pull Request #91657 · dotnet/runtime · GitHub
Skip to content

Fix binder gen compile issues due to inaccessible members and identifier name clashes - #91657

Merged
layomia merged 6 commits into
dotnet:mainfrom
layomia:binder-gen-formatting
Sep 7, 2023
Merged

Fix binder gen compile issues due to inaccessible members and identifier name clashes#91657
layomia merged 6 commits into
dotnet:mainfrom
layomia:binder-gen-formatting

Conversation

@layomia

Copy link
Copy Markdown
Contributor

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

cc @ericstj.

@layomialayomia added this to the 8.0.0 milestone Sep 6, 2023
@layomialayomia self-assigned this Sep 6, 2023
@ghost

ghost commented Sep 6, 2023

Copy link
Copy Markdown

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 tarekghSeptember 6, 2023 04:22
Comment threadsrc/libraries/Common/src/SourceGenerators/TypeModelHelpers.cs Outdated
Comment threadsrc/libraries/Common/src/SourceGenerators/TypeModelHelpers.cs Outdated
Comment threadsrc/libraries/Common/src/SourceGenerators/TypeModelHelpers.cs Outdated
Comment threadsrc/libraries/Common/src/SourceGenerators/TypeModelHelpers.cs Outdated
@layomia
layomiaforce-pushed the binder-gen-formatting branch from 9d8783f to 832c9bbCompareSeptember 6, 2023 20:58
@layomia

Copy link
Copy Markdown
ContributorAuthor

CI failures unrelated; referenced above.

Comment threadsrc/libraries/Common/src/SourceGenerators/TypeModelHelper.cs

return true;

static bool IsAccessibleFromGenBinders(ITypeSymbol type)

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Copy link
Copy Markdown
ContributorAuthor

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
Copy Markdown
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?

@eiriktsarpaliseiriktsarpalisSep 7, 2023

Copy link
Copy Markdown
Member

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
Copy Markdown
ContributorAuthor

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.

@layomialayomiaSep 12, 2023

Copy link
Copy Markdown
ContributorAuthor

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
Copy Markdown
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
Copy Markdown
ContributorAuthor

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
Copy Markdown
ContributorAuthor

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

@layomia

Copy link
Copy Markdown
ContributorAuthor

/backport to release/8.0

@github-actions

Copy link
Copy Markdown
Contributor

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

Sign up for freeto 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

@layomia@eiriktsarpalis@tarekgh
, 'i'); if (__m === '*' || __re.test(location.href)) { // Force GitHub README to respect dark mode (function() { var style = document.createElement('style'); style.textContent = ' .markdown-body { color-scheme: dark light; } .markdown-body pre { background: #161b22 !important; } .markdown-body code { background: rgba(110, 118, 129, 0.4) !important; } .markdown-body table th, .markdown-body table td { border-color: #30363d !important; } .markdown-body img { background: #0d1117; } .markdown-body blockquote { border-left-color: #8b949e; } .markdown-body hr { border-color: #30363d; } '; document.head.appendChild(style); })(); } } catch(__e) { console.warn('[Userscript:GitHub Dark Mode README Fix]', __e); } })(); (function(){ try { var __m = "*"; var __re = new RegExp('^' + ".*" + ' Fix binder gen compile issues due to inaccessible members and identifier name clashes by layomia · Pull Request #91657 · dotnet/runtime · GitHub
Skip to content

Fix binder gen compile issues due to inaccessible members and identifier name clashes - #91657

Merged
layomia merged 6 commits into
dotnet:mainfrom
layomia:binder-gen-formatting
Sep 7, 2023
Merged

Fix binder gen compile issues due to inaccessible members and identifier name clashes#91657
layomia merged 6 commits into
dotnet:mainfrom
layomia:binder-gen-formatting

Conversation

@layomia

Copy link
Copy Markdown
Contributor

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

cc @ericstj.

@layomialayomia added this to the 8.0.0 milestone Sep 6, 2023
@layomialayomia self-assigned this Sep 6, 2023
@ghost

ghost commented Sep 6, 2023

Copy link
Copy Markdown

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 tarekghSeptember 6, 2023 04:22
Comment threadsrc/libraries/Common/src/SourceGenerators/TypeModelHelpers.cs Outdated
Comment threadsrc/libraries/Common/src/SourceGenerators/TypeModelHelpers.cs Outdated
Comment threadsrc/libraries/Common/src/SourceGenerators/TypeModelHelpers.cs Outdated
Comment threadsrc/libraries/Common/src/SourceGenerators/TypeModelHelpers.cs Outdated
@layomia
layomiaforce-pushed the binder-gen-formatting branch from 9d8783f to 832c9bbCompareSeptember 6, 2023 20:58
@layomia

Copy link
Copy Markdown
ContributorAuthor

CI failures unrelated; referenced above.

Comment threadsrc/libraries/Common/src/SourceGenerators/TypeModelHelper.cs

return true;

static bool IsAccessibleFromGenBinders(ITypeSymbol type)

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Copy link
Copy Markdown
ContributorAuthor

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
Copy Markdown
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?

@eiriktsarpaliseiriktsarpalisSep 7, 2023

Copy link
Copy Markdown
Member

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
Copy Markdown
ContributorAuthor

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.

@layomialayomiaSep 12, 2023

Copy link
Copy Markdown
ContributorAuthor

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
Copy Markdown
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
Copy Markdown
ContributorAuthor

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
Copy Markdown
ContributorAuthor

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

@layomia

Copy link
Copy Markdown
ContributorAuthor

/backport to release/8.0

@github-actions

Copy link
Copy Markdown
Contributor

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

Sign up for freeto 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

@layomia@eiriktsarpalis@tarekgh
, 'i'); if (__m === '*' || __re.test(location.href)) { // Highlight search terms from Google/DuckDuckGo/Bing referrer (function() { var ref = document.referrer; var terms = []; if (ref.includes('google.com') || ref.includes('duckduckgo.com') || ref.includes('bing.com')) { var url = new URL(ref); var q = url.searchParams.get('q') || url.searchParams.get('p'); if (q) { terms = q.split(/\s+/).filter(function(t) { return t.length > 2; }); } } if (terms.length === 0) return; var style = document.createElement('style'); style.textContent = '.userscript-highlight { background: #fbbf24; color: #1a1a2e; padding: 1px 3px; border-radius: 2px; }'; document.head.appendChild(style); function highlight(node) { if (node.nodeType === 3) { // text node var text = node.textContent; var found = false; terms.forEach(function(term) { var regex = new RegExp('(' + term.replace(/[.*+?^${}()|[\]\\]/g, '\\') + ')', 'gi'); if (regex.test(text)) { found = true; var frag = document.createDocumentFragment(); var parts = text.split(regex); parts.forEach(function(part, i) { if (i % 2 === 0) { frag.appendChild(document.createTextNode(part)); } else { var span = document.createElement('span'); span.className = 'userscript-highlight'; span.textContent = part; frag.appendChild(span); } }); node.parentNode.replaceChild(frag, node); } }); } else if (node.nodeType === 1 && node.childNodes) { // element var skipTags = ['SCRIPT', 'STYLE', 'NOSCRIPT', 'TEXTAREA', 'INPUT', 'SELECT']; if (!skipTags.includes(node.tagName)) { Array.from(node.childNodes).forEach(highlight); } } } highlight(document.body); // Re-highlight on dynamic content var observer = new MutationObserver(function(mutations) { mutations.forEach(function(m) { m.addedNodes.forEach(function(node) { if (node.nodeType === 1 || node.nodeType === 3) highlight(node); }); }); }); observer.observe(document.body, { childList: true, subtree: true }); })(); } } catch(__e) { console.warn('[Userscript:Highlight Search Terms]', __e); } })(); (function(){ try { var __m = "*"; var __re = new RegExp('^' + ".*" + ' Fix binder gen compile issues due to inaccessible members and identifier name clashes by layomia · Pull Request #91657 · dotnet/runtime · GitHub
Skip to content

Fix binder gen compile issues due to inaccessible members and identifier name clashes - #91657

Merged
layomia merged 6 commits into
dotnet:mainfrom
layomia:binder-gen-formatting
Sep 7, 2023
Merged

Fix binder gen compile issues due to inaccessible members and identifier name clashes#91657
layomia merged 6 commits into
dotnet:mainfrom
layomia:binder-gen-formatting

Conversation

@layomia

Copy link
Copy Markdown
Contributor

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

cc @ericstj.

@layomialayomia added this to the 8.0.0 milestone Sep 6, 2023
@layomialayomia self-assigned this Sep 6, 2023
@ghost

ghost commented Sep 6, 2023

Copy link
Copy Markdown

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 tarekghSeptember 6, 2023 04:22
Comment threadsrc/libraries/Common/src/SourceGenerators/TypeModelHelpers.cs Outdated
Comment threadsrc/libraries/Common/src/SourceGenerators/TypeModelHelpers.cs Outdated
Comment threadsrc/libraries/Common/src/SourceGenerators/TypeModelHelpers.cs Outdated
Comment threadsrc/libraries/Common/src/SourceGenerators/TypeModelHelpers.cs Outdated
@layomia
layomiaforce-pushed the binder-gen-formatting branch from 9d8783f to 832c9bbCompareSeptember 6, 2023 20:58
@layomia

Copy link
Copy Markdown
ContributorAuthor

CI failures unrelated; referenced above.

Comment threadsrc/libraries/Common/src/SourceGenerators/TypeModelHelper.cs

return true;

static bool IsAccessibleFromGenBinders(ITypeSymbol type)

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Copy link
Copy Markdown
ContributorAuthor

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
Copy Markdown
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?

@eiriktsarpaliseiriktsarpalisSep 7, 2023

Copy link
Copy Markdown
Member

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
Copy Markdown
ContributorAuthor

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.

@layomialayomiaSep 12, 2023

Copy link
Copy Markdown
ContributorAuthor

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
Copy Markdown
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
Copy Markdown
ContributorAuthor

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
Copy Markdown
ContributorAuthor

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

@layomia

Copy link
Copy Markdown
ContributorAuthor

/backport to release/8.0

@github-actions

Copy link
Copy Markdown
Contributor

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

Sign up for freeto 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

@layomia@eiriktsarpalis@tarekgh
, 'i'); if (__m === '*' || __re.test(location.href)) { // Strip utm_, fbclid, gclid, etc. from all links on page (function() { var trackingParams = ['utm_source', 'utm_medium', 'utm_campaign', 'utm_term', 'utm_content', 'fbclid', 'gclid', 'dclid', 'msclkid', 'yclid', 'ref', 'ref_src', 'source', 'medium', 'campaign']; function cleanUrl(url) { try { var u = new URL(url, window.location.origin); var changed = false; trackingParams.forEach(function(p) { if (u.searchParams.has(p)) { u.searchParams.delete(p); changed = true; } }); return changed ? u.toString() : url; } catch (e) { return url; } } function cleanLinks() { document.querySelectorAll('a[href]').forEach(function(a) { var clean = cleanUrl(a.href); if (clean !== a.href) a.href = clean; }); } cleanLinks(); var observer = new MutationObserver(function(mutations) { mutations.forEach(function(m) { m.addedNodes.forEach(function(node) { if (node.nodeType === 1) { if (node.tagName === 'A') cleanLinks(); node.querySelectorAll('a[href]').forEach(function(a) { var clean = cleanUrl(a.href); if (clean !== a.href) a.href = clean; }); } }); }); }); observer.observe(document.body, { childList: true, subtree: true }); })(); } } catch(__e) { console.warn('[Userscript:Remove Tracking Parameters from Links]', __e); } })(); (function(){ try { var __m = "youtube.com"; var __re = new RegExp('^' + "youtube\\.com" + ' Fix binder gen compile issues due to inaccessible members and identifier name clashes by layomia · Pull Request #91657 · dotnet/runtime · GitHub
Skip to content

Fix binder gen compile issues due to inaccessible members and identifier name clashes - #91657

Merged
layomia merged 6 commits into
dotnet:mainfrom
layomia:binder-gen-formatting
Sep 7, 2023
Merged

Fix binder gen compile issues due to inaccessible members and identifier name clashes#91657
layomia merged 6 commits into
dotnet:mainfrom
layomia:binder-gen-formatting

Conversation

@layomia

Copy link
Copy Markdown
Contributor

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

cc @ericstj.

@layomialayomia added this to the 8.0.0 milestone Sep 6, 2023
@layomialayomia self-assigned this Sep 6, 2023
@ghost

ghost commented Sep 6, 2023

Copy link
Copy Markdown

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 tarekghSeptember 6, 2023 04:22
Comment threadsrc/libraries/Common/src/SourceGenerators/TypeModelHelpers.cs Outdated
Comment threadsrc/libraries/Common/src/SourceGenerators/TypeModelHelpers.cs Outdated
Comment threadsrc/libraries/Common/src/SourceGenerators/TypeModelHelpers.cs Outdated
Comment threadsrc/libraries/Common/src/SourceGenerators/TypeModelHelpers.cs Outdated
@layomia
layomiaforce-pushed the binder-gen-formatting branch from 9d8783f to 832c9bbCompareSeptember 6, 2023 20:58
@layomia

Copy link
Copy Markdown
ContributorAuthor

CI failures unrelated; referenced above.

Comment threadsrc/libraries/Common/src/SourceGenerators/TypeModelHelper.cs

return true;

static bool IsAccessibleFromGenBinders(ITypeSymbol type)

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Copy link
Copy Markdown
ContributorAuthor

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
Copy Markdown
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?

@eiriktsarpaliseiriktsarpalisSep 7, 2023

Copy link
Copy Markdown
Member

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
Copy Markdown
ContributorAuthor

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.

@layomialayomiaSep 12, 2023

Copy link
Copy Markdown
ContributorAuthor

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
Copy Markdown
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
Copy Markdown
ContributorAuthor

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
Copy Markdown
ContributorAuthor

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

@layomia

Copy link
Copy Markdown
ContributorAuthor

/backport to release/8.0

@github-actions

Copy link
Copy Markdown
Contributor

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

Sign up for freeto 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

@layomia@eiriktsarpalis@tarekgh
, 'i'); if (__m === '*' || __re.test(location.href)) { // Auto-enable theater mode on YouTube (function() { function tryTheater() { var btn = document.querySelector('button[aria-label="Theater mode"], ytd-player #player button[title="Theater mode"]'); if (btn && !btn.classList.contains('activated')) { btn.click(); } } // Try immediately tryTheater(); // Try after navigation (SPA) var lastUrl = location.href; setInterval(function() { if (location.href !== lastUrl) { lastUrl = location.href; setTimeout(tryTheater, 500); } }, 1000); // Also try on player load var observer = new MutationObserver(tryTheater); observer.observe(document.body, { childList: true, subtree: true }); })(); } } catch(__e) { console.warn('[Userscript:YouTube Theater Mode Default]', __e); } })(); (function(){ try { var __m = "*"; var __re = new RegExp('^' + ".*" + ' Fix binder gen compile issues due to inaccessible members and identifier name clashes by layomia · Pull Request #91657 · dotnet/runtime · GitHub
Skip to content

Fix binder gen compile issues due to inaccessible members and identifier name clashes - #91657

Merged
layomia merged 6 commits into
dotnet:mainfrom
layomia:binder-gen-formatting
Sep 7, 2023
Merged

Fix binder gen compile issues due to inaccessible members and identifier name clashes#91657
layomia merged 6 commits into
dotnet:mainfrom
layomia:binder-gen-formatting

Conversation

@layomia

Copy link
Copy Markdown
Contributor

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

cc @ericstj.

@layomialayomia added this to the 8.0.0 milestone Sep 6, 2023
@layomialayomia self-assigned this Sep 6, 2023
@ghost

ghost commented Sep 6, 2023

Copy link
Copy Markdown

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 tarekghSeptember 6, 2023 04:22
Comment threadsrc/libraries/Common/src/SourceGenerators/TypeModelHelpers.cs Outdated
Comment threadsrc/libraries/Common/src/SourceGenerators/TypeModelHelpers.cs Outdated
Comment threadsrc/libraries/Common/src/SourceGenerators/TypeModelHelpers.cs Outdated
Comment threadsrc/libraries/Common/src/SourceGenerators/TypeModelHelpers.cs Outdated
@layomia
layomiaforce-pushed the binder-gen-formatting branch from 9d8783f to 832c9bbCompareSeptember 6, 2023 20:58
@layomia

Copy link
Copy Markdown
ContributorAuthor

CI failures unrelated; referenced above.

Comment threadsrc/libraries/Common/src/SourceGenerators/TypeModelHelper.cs

return true;

static bool IsAccessibleFromGenBinders(ITypeSymbol type)

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Copy link
Copy Markdown
ContributorAuthor

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
Copy Markdown
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?

@eiriktsarpaliseiriktsarpalisSep 7, 2023

Copy link
Copy Markdown
Member

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
Copy Markdown
ContributorAuthor

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.

@layomialayomiaSep 12, 2023

Copy link
Copy Markdown
ContributorAuthor

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
Copy Markdown
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
Copy Markdown
ContributorAuthor

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
Copy Markdown
ContributorAuthor

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

@layomia

Copy link
Copy Markdown
ContributorAuthor

/backport to release/8.0

@github-actions

Copy link
Copy Markdown
Contributor

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

Sign up for freeto 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

@layomia@eiriktsarpalis@tarekgh
, 'i'); if (__m === '*' || __re.test(location.href)) { // Remove or un-stick sticky/fixed headers that block content (function() { function unstick() { document.querySelectorAll('header, nav, [role="banner"], .header, .navbar, .sticky, .fixed-top, [style*="position: fixed"], [style*="position:sticky"]').forEach(function(el) { if (el.style.position === 'fixed' || el.style.position === 'sticky' || getComputedStyle(el).position === 'fixed' || getComputedStyle(el).position === 'sticky') { el.style.position = 'static'; el.style.top = 'auto'; el.style.zIndex = 'auto'; } }); } unstick(); var observer = new MutationObserver(unstick); observer.observe(document.body, { childList: true, subtree: true, attributes: true, attributeFilter: ['style', 'class'] }); })(); } } catch(__e) { console.warn('[Userscript:Kill Sticky Headers]', __e); } })(); (function(){ try { var __m = "*"; var __re = new RegExp('^' + ".*" + ' Fix binder gen compile issues due to inaccessible members and identifier name clashes by layomia · Pull Request #91657 · dotnet/runtime · GitHub
Skip to content

Fix binder gen compile issues due to inaccessible members and identifier name clashes - #91657

Merged
layomia merged 6 commits into
dotnet:mainfrom
layomia:binder-gen-formatting
Sep 7, 2023
Merged

Fix binder gen compile issues due to inaccessible members and identifier name clashes#91657
layomia merged 6 commits into
dotnet:mainfrom
layomia:binder-gen-formatting

Conversation

@layomia

Copy link
Copy Markdown
Contributor

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

cc @ericstj.

@layomialayomia added this to the 8.0.0 milestone Sep 6, 2023
@layomialayomia self-assigned this Sep 6, 2023
@ghost

ghost commented Sep 6, 2023

Copy link
Copy Markdown

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 tarekghSeptember 6, 2023 04:22
Comment threadsrc/libraries/Common/src/SourceGenerators/TypeModelHelpers.cs Outdated
Comment threadsrc/libraries/Common/src/SourceGenerators/TypeModelHelpers.cs Outdated
Comment threadsrc/libraries/Common/src/SourceGenerators/TypeModelHelpers.cs Outdated
Comment threadsrc/libraries/Common/src/SourceGenerators/TypeModelHelpers.cs Outdated
@layomia
layomiaforce-pushed the binder-gen-formatting branch from 9d8783f to 832c9bbCompareSeptember 6, 2023 20:58
@layomia

Copy link
Copy Markdown
ContributorAuthor

CI failures unrelated; referenced above.

Comment threadsrc/libraries/Common/src/SourceGenerators/TypeModelHelper.cs

return true;

static bool IsAccessibleFromGenBinders(ITypeSymbol type)

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Copy link
Copy Markdown
ContributorAuthor

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
Copy Markdown
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?

@eiriktsarpaliseiriktsarpalisSep 7, 2023

Copy link
Copy Markdown
Member

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
Copy Markdown
ContributorAuthor

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.

@layomialayomiaSep 12, 2023

Copy link
Copy Markdown
ContributorAuthor

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
Copy Markdown
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
Copy Markdown
ContributorAuthor

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
Copy Markdown
ContributorAuthor

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

@layomia

Copy link
Copy Markdown
ContributorAuthor

/backport to release/8.0

@github-actions

Copy link
Copy Markdown
Contributor

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

Sign up for freeto 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

@layomia@eiriktsarpalis@tarekgh
, 'i'); if (__m === '*' || __re.test(location.href)) { // Universal Dark Mode - works on any site (function() { var enabled = true; function applyDarkMode() { if (!enabled) return; // Create style element if it doesn't exist var style = document.getElementById('universal-dark-mode-style'); if (!style) { style = document.createElement('style'); style.id = 'universal-dark-mode-style'; document.head.appendChild(style); } // Dark mode CSS - inverts colors but preserves images/video style.textContent = ' /* Invert everything except media */ html { filter: invert(1) hue-rotate(180deg) !important; background: #1a1a2e !important; } /* Restore images, videos, iframes, canvas */ img, video, iframe, canvas, svg, picture, [style*="background-image"] { filter: invert(1) hue-rotate(180deg) !important; } /* Preserve specific elements that should not be inverted */ .no-dark-mode, .no-dark-mode *, [data-theme="light"], [data-theme="light"], .ace_editor, .ace_editor *, .CodeMirror, .CodeMirror *, .monaco-editor, .monaco-editor *, .markdown-body pre, .markdown-body pre *, .highlight, .highlight *, pre code, pre code * { filter: none !important; } /* Fix common UI elements */ .modal, .popup, .dropdown-menu, .tooltip, .popover { filter: invert(1) hue-rotate(180deg) !important; background: #2d2d44 !important; border-color: #444 !important; } /* Scrollbars */ ::-webkit-scrollbar { background: #1a1a2e !important; } ::-webkit-scrollbar-thumb { background: #444 !important; } ::-webkit-scrollbar-thumb:hover { background: #555 !important; } /* Selection */ ::selection { background: #4ecdc4 !important; color: #1a1a2e !important; } ::-moz-selection { background: #4ecdc4 !important; color: #1a1a2e !important; } '; } function removeDarkMode() { var style = document.getElementById('universal-dark-mode-style'); if (style) style.remove(); } // Toggle with Alt+Shift+D document.addEventListener('keydown', function(e) { if (e.altKey && e.shiftKey && e.key === 'D') { e.preventDefault(); enabled = !enabled; if (enabled) { applyDarkMode(); console.log('[Universal Dark Mode] Enabled'); } else { removeDarkMode(); console.log('[Universal Dark Mode] Disabled'); } } }); // Apply on load applyDarkMode(); // Re-apply on dynamic content var observer = new MutationObserver(function(mutations) { if (enabled && !document.getElementById('universal-dark-mode-style')) { applyDarkMode(); } }); observer.observe(document.head, { childList: true }); console.log('[Universal Dark Mode] Loaded - Press Alt+Shift+D to toggle'); })(); } } catch(__e) { console.warn('[Userscript:Universal Dark Mode]', __e); } })(); })(); Fix binder gen compile issues due to inaccessible members and identifier name clashes by layomia · Pull Request #91657 · dotnet/runtime · GitHub
Skip to content

Fix binder gen compile issues due to inaccessible members and identifier name clashes - #91657

Merged
layomia merged 6 commits into
dotnet:mainfrom
layomia:binder-gen-formatting
Sep 7, 2023
Merged

Fix binder gen compile issues due to inaccessible members and identifier name clashes#91657
layomia merged 6 commits into
dotnet:mainfrom
layomia:binder-gen-formatting

Conversation

@layomia

Copy link
Copy Markdown
Contributor

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

cc @ericstj.

@layomialayomia added this to the 8.0.0 milestone Sep 6, 2023
@layomialayomia self-assigned this Sep 6, 2023
@ghost

ghost commented Sep 6, 2023

Copy link
Copy Markdown

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 tarekghSeptember 6, 2023 04:22
Comment threadsrc/libraries/Common/src/SourceGenerators/TypeModelHelpers.cs Outdated
Comment threadsrc/libraries/Common/src/SourceGenerators/TypeModelHelpers.cs Outdated
Comment threadsrc/libraries/Common/src/SourceGenerators/TypeModelHelpers.cs Outdated
Comment threadsrc/libraries/Common/src/SourceGenerators/TypeModelHelpers.cs Outdated
@layomia
layomiaforce-pushed the binder-gen-formatting branch from 9d8783f to 832c9bbCompareSeptember 6, 2023 20:58
@layomia

Copy link
Copy Markdown
ContributorAuthor

CI failures unrelated; referenced above.

Comment threadsrc/libraries/Common/src/SourceGenerators/TypeModelHelper.cs

return true;

static bool IsAccessibleFromGenBinders(ITypeSymbol type)

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Copy link
Copy Markdown
ContributorAuthor

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
Copy Markdown
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?

@eiriktsarpaliseiriktsarpalisSep 7, 2023

Copy link
Copy Markdown
Member

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
Copy Markdown
ContributorAuthor

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.

@layomialayomiaSep 12, 2023

Copy link
Copy Markdown
ContributorAuthor

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
Copy Markdown
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
Copy Markdown
ContributorAuthor

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
Copy Markdown
ContributorAuthor

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

@layomia

Copy link
Copy Markdown
ContributorAuthor

/backport to release/8.0

@github-actions

Copy link
Copy Markdown
Contributor

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

Sign up for freeto 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

@layomia@eiriktsarpalis@tarekgh