Warning for partial ComImport types with members in more than one type part

[jnm2]

The same reasoning applies as the reasoning for why partial enums wouldn't make sense. The meaning of a member in a ComImport type changes based on its order within the type.

There is currently no warning for a pair of source files like this, but there should be:

[ComImport]
partial interface ISomeInterface { void Foo(); }

partial interface ISomeInterface { void Bar(); }

There should be no warning for a case like this:

[ComImport]
partial interface ISomeInterface { void Foo(); }

[SomeInterface]
partial interface ISomeInterface
{
    public struct DoesNotAffectVTable { }
}

Why not warn for partial ComImport interfaces in the first place?

The source generator https://github.com/microsoft/CsWin32 is a new official vehicle for consuming Windows platform APIs. It generates most types as partial so that you can add customizations, but it doesn't do this for ComImport interfaces. @AArnott cited the danger described at the top. The use case for a partial ComImport interface was to add attributes:

namespace Windows.Win32.UI.Shell
{
    [CoClass(typeof(ShellLink))]
    internal partial interface IShellLinkW { }
}

This is safe, but adding a member would not be safe. Therefore the warning should only apply if more than one type part has members.

[AArnott]

The same reasoning applies as the reasoning for why partial enums wouldn't make sense.

partial enums are fine if the first enum value declared in each partial explicitly prescribes the value. For example, there's no problem here:

partial enum Foo
{
    A = 1,
    B,
}

partial enum Foo
{
    C = 3,
    D,
}

[jnm2]

That will give "CS0267: The 'partial' modifier can only appear immediately before 'class', 'record', 'struct', 'interface', or a method return type." (dotnet/csharplang#2669) Even if partial enums with explicit ordering were allowed in the future, you'd want errors or warnings if the order wasn't explicitly given. That error/warning would be analogous to what we're asking for in ComImport types.

[jaredpar]

Moving to roslyn-analyzers as this feels more like an analyzer issue vs. a core compiler one. The reasoning being that [ComImport] isn't really a concept that is understood by the compiler. It exists outside of it. That's very much in analyzer territory.

[mavasani]

Needs to be triaged/approved by dotnet/runtime.

[dotnet-issue-labeler]

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

[elachlan]

This is a potential blocker for winforms as we attempt to migrate interop code to CsWin32.

CC: @JeremyKuhne, @lonitra

[elachlan]

@danmoseley can you please see if you can get this unstuck?

[AArnott]

@elachlan Can you elaborate on how lack of an analyzer would be a blocker for WinForms? At best it seems to me it would just help you write correct code. But when would WinForms define partial COM interfaces? CsWin32 is being used in WinForms without marshaling, so interfaces aren't even being generated.