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

Collection expression plan for AOT support #1877

Open
7 tasks done
Sergio0694 opened this issue Nov 23, 2024 · 0 comments · May be fixed by #1878
Open
7 tasks done

Collection expression plan for AOT support #1877

Sergio0694 opened this issue Nov 23, 2024 · 0 comments · May be fixed by #1878
Labels

Comments

@Sergio0694
Copy link
Member

Sergio0694 commented Nov 23, 2024

Collection expressions pose a significant challenge for trim/AOT support in CsWinRT, because depending on the use case scenario, they can cause Roslyn to generate synthesized types that cannot be seen by developers nor by analyzers. This means that it's impossible for CsWinRT to collect them in the vtable logic and generate CCW vtables for them. Currently, there's no easy way for developers to spot such uses, meaning it's very easy to accidentally introduce code that's not AOT compatible when using collection expressions, which will then crash at runtime.

This issue tracks all the work needed to solve this issue. There's three components to this:

  • Generator updates to gather CCW info where needed
  • New analyzers to spot unsupported collection expressions, and warn on them
  • New diagnostic suppressors to suppress IDE03XX warnings in these scenarios

Changes for collection expressions in code

These changes apply to code that is already using a collection expression (ie. no IDE03XX warning is present):

This is the expected behavior after these changes:

int[] a = []; // Ok
int[] b = [1, 2, 3]; // Ok
IEnumerable<int> c = []; // Ok, gathers 'int[]'
IList<int> d = []; // Ok, gathers 'List<int>'
ICollection<int> e = [1, 2, 3]; // Warning
IReadOnlyList<int> f = [1, 2, 3]; // Warning

"Use collection expression for array" (IDE0300)

There are three scenarios here:

We need these changes:

  • New diagnostic suppressor: suppress IDE0300 warnings for case 2, if the collection expression is not empty

"Use collection expression for empty" (IDE0301)

No work needed. All IDE0301 suggestions are valid, as they're only for empty collection expressions.

"Use collection expression for stackalloc" (IDE0302)

No work needed. No stackalloc expression interacts with WinRT marshalling, since they can't be boxed.

"Use collection expression for Create()" (IDE0303)

These suggestions are valid only if they cause a collection builder method to be picked up. That is, we only need this:

  • New diagnostic suppressor: suppress IDE0303 when the lvalue is an interface type without [CollectionBuilder]

"Use collection expression for builder" (IDE0304)

Same as for IDE0303, that is:

  • New diagnostic suppressor: suppress IDE0304 when the lvalue is an interface type without [CollectionBuilder]

"Use collection expression for fluent" (IDE0305)

Same as for IDE0303 and IDE0304, that is:

  • New diagnostic suppressor: suppress IDE0305 when the lvalue is an interface type without [CollectionBuilder]
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant