Default Interface Method Prototype #10505

yizhang82 · 2017-03-27T20:46:02Z

CoreCLR Issue - https://github.com/dotnet/coreclr/issues/10504
C# Language Spec (WIP) - https://github.com/dotnet/csharplang/blob/master/proposals/default-interface-methods.md

As suggested by @jkotas, I'm moving my work to dev/defaultintf branch in the main CoreCLR repo. I'm going to keep submitting periodically submit new PRs to dev/defaultintf branch going forward - this is going to make collaboration between various runtime and language team a bit easier.

What this PR has:

Allow non-abstract non-public interface methods in ILDAsm and change our IL.targets to use ILDAsm we built for the time being, until we have a good set of toolsets that has the new ILDAsm.
Allow type loader to ignore not implemented interfaces (we may need to add more validation later)
Hooked up VSD interface dispatch to look for default interface method in the absence of proper implementation from the class itself.
A naive implementation of default interface method look up based on InterfaceMap, from derived class to base class - just enough for prototyping on both CLR and C# sides. Once we finalize the design, it'll be replaced by the real thing.
Support for shared generics by properly instantiate MethodDesc which inserts instantiating stubs to pass the secret MethodTable argument for the particular generic instantiation. One particular interesting aspect of this is that we need to lie to the JIT about those interface methods at call site requires secret argument so that it emits the correct code at callsite.
Support for explicit override by looking up methodimpls (implicit method override is not supported)
Support for interface variance
Temporary workaround for interface precode. Today we always assume interface has precode
Added tests
- Note that the C# code is simply there to make writing IL a bit easier - the IL are disassembled from C# generated code and then modified by hand. Once things got more stable we can delete them, or see if it makes sense to switch over to a new C# compiler for positive cases that we care about.

TODO - See https://github.com/dotnet/coreclr/issues/10504

@jkotas @davidwrighton PTAL

//cc @fadimounir

This reverts commit eecb802.

…thod. add a test case for overriding but it may not be what we want

… PARAM_TYPE calling conv

…getMethodSigInternal

…ithout precode. This is accdentally discovered by methodimpl test case when iterating methods on a default interface method that has already been JITted

jkotas · 2017-03-27T20:58:28Z

cc @migueldeicaza @kumpera

…s are choking on CoreCLR ilasm for security related stuff

davidwrighton · 2017-04-04T17:55:08Z

src/ilasm/assembler.cpp

-                            report->warn("Non-virtual, non-abstract instance method in interface, set to such\n");
-                            flags = (CorMethodAttr)(flags |mdVirtual | mdAbstract);
+                            report->warn("Non-virtual instance method in interface, set to such\n");
+                            flags = (CorMethodAttr)(flags | mdVirtual);


I think that in ILASM we should permit non-virtuals. This would be to allow either the feature to be implemented in the runtime, or for tests that the feature is blocked by the typeloader to be put in place. In either case, we shouldn't mystically mark the method as virtual. (However, we should consider spewing a warning)

Yep. I haven't got to supporting instance methods yet. I'm looking into it now and have removed these checks from ILAsm.

davidwrighton · 2017-04-04T17:57:52Z

src/vm/method.cpp

@@ -1869,7 +1873,8 @@ BOOL MethodDesc::AcquiresInstMethodTableFromThis() {
        IsSharedByGenericInstantiations()  &&
        !HasMethodInstantiation() &&
        !IsStatic() &&
-        !GetMethodTable()->IsValueType();
+        !GetMethodTable()->IsValueType() &&
+        !IsDefaultInterfaceMethod();


IsDefaultInterfaceMethod [](start = 9, length = 24)

Could we rename this predicate to be IsInterfaceMethodWithImplementation()? We may support non-virtual interface methods, and calling them "default" interface methods would be confusing.

I'm a bit unsure about this one. Default interface method feature do have wider implications (such as non-virtual instance methods, etc). But the specific default interface method scenario in the context of runtime should be referring to non-abstract virtual instance method. You can also argue that IsInterfaceMethodWithImplementation can also refer to instance methods in interface, which is not what we want here.
I'll add a bit of comment in the method header to explain / clarify that it is non-abstract virtual instance method. I can change it if you feel strongly, though.

davidwrighton · 2017-04-04T18:06:06Z

src/vm/methodtablebuilder.cpp

-                    BuildMethodTableThrowException(BFA_NONAB_NONCCTOR_METHOD_ON_INT);
-                }
-            }
-        }


Why are you removing the check against cctor's on interfaces? It seems to me that since we've not talked positively about adding static fields to interfaces, we should keep cctors disabled.

If I read the code correctly, we already allow static cctors in interfaces (since we allow static methods already), and the check is for non-cctor that are virtual or special name. I can keep the special name check for now.

davidwrighton · 2017-04-04T18:08:03Z

src/vm/methodtablebuilder.cpp

@@ -7667,6 +7704,23 @@ MethodTableBuilder::PlaceInterfaceMethods()
                PlaceMethodFromParentEquivalentInterfaceIntoInterfaceSlot(itfSlotIt, pCurItfEntry, &rgInterfaceDispatchMapTypeIDs, dwCurInterface);
            }
 #endif
+
+            /*


Please don't check in commented out code without a comment as to what's going on here.

I've removed the code for now. It might be useful going forward when we go for a new implementation but I can easily add it back.

davidwrighton · 2017-04-04T18:09:26Z

src/vm/methodtablebuilder.cpp

-                    MethodDesc *pMD = it.GetDeclMethodDesc();
-                    BuildMethodTableThrowException(IDS_CLASSLOAD_NOTIMPLEMENTED, pMD->GetNameOnNonArrayClass());
-                }
+                // @DESIGN - What is the right level of check if the interface itself does not have default implementation


Please add a DIM_TODO to the comment so we can find these bits of commented out logic.

Thanks. Fixed/Replaced with DIM_TODO

davidwrighton · 2017-04-04T18:09:56Z

…ue type call test scenario

yizhang82 · 2017-04-06T04:04:40Z

Thanks @davidwrighton for review!

* allow non-zero RVA on abstract interface method in ilasm * Revert "allow non-zero RVA on abstract interface method in ilasm" This reverts commit eecb802. * add a test case and allow virtual non-abstract method in ilasm * allow non-abstract methods in the loader * fixup dispatch map * support for simple default interface method scenario * fix a bug with incorrect usage of MethodIterator skpping the first method. add a test case for overriding but it may not be what we want * add another simple test case for base class * allow private/internal methods in ilasm and add a explict impl test * update reference to mscorlib in il test * add shared generics and variance case * allow interface dispatch to return instantiating stubs with the right PARAM_TYPE calling conv * simple factoring and add a valuetype test case * add a test case for generic virtual methods * a bit more refactoring by moving the CALLCONV_PARAMTYPE logic inside getMethodSigInternal * support explicit methodimpl and remove implicit methodimpl test case * update test cases to give more clear output * Fix a bug where GetMethodDescForSlot chokes on interface MethodDesc without precode. This is accdentally discovered by methodimpl test case when iterating methods on a default interface method that has already been JITted * cleanup code after review and add a bit more comments * update comments * only use custom ILAsm for default interface methods tests - some tests are choking on CoreCLR ilasm for security related stuff * address comments and allow instance methods, and add a constraint value type call test scenario * disable the failing protected method scenario

Yi Zhang added 20 commits March 11, 2017 10:58

allow non-zero RVA on abstract interface method in ilasm

eecb802

Revert "allow non-zero RVA on abstract interface method in ilasm"

83ba711

This reverts commit eecb802.

add a test case and allow virtual non-abstract method in ilasm

675e681

allow non-abstract methods in the loader

c986dbe

fixup dispatch map

6e36e29

support for simple default interface method scenario

b6db058

fix a bug with incorrect usage of MethodIterator skpping the first me…

a2a95a7

…thod. add a test case for overriding but it may not be what we want

add another simple test case for base class

205e7f5

allow private/internal methods in ilasm and add a explict impl test

60afcd5

update reference to mscorlib in il test

f6e3c08

add shared generics and variance case

c48881f

allow interface dispatch to return instantiating stubs with the right…

ed5c9d6

… PARAM_TYPE calling conv

simple factoring and add a valuetype test case

adf1a09

add a test case for generic virtual methods

546df05

a bit more refactoring by moving the CALLCONV_PARAMTYPE logic inside …

97108f6

…getMethodSigInternal

support explicit methodimpl and remove implicit methodimpl test case

7efe42e

update test cases to give more clear output

a52dd22

Fix a bug where GetMethodDescForSlot chokes on interface MethodDesc w…

5078548

…ithout precode. This is accdentally discovered by methodimpl test case when iterating methods on a default interface method that has already been JITted

cleanup code after review and add a bit more comments

4d9e3cf

update comments

be54957

dnfclas added the cla-already-signed label Mar 27, 2017

only use custom ILAsm for default interface methods tests - some test…

9fdf872

…s are choking on CoreCLR ilasm for security related stuff

davidwrighton reviewed Apr 4, 2017

View reviewed changes

address comments and allow instance methods, and add a constraint val…

f8295a2

…ue type call test scenario

disable the failing protected method scenario

a1ceb77

yizhang82 merged commit d793d5e into dotnet:dev/defaultintf Apr 6, 2017

yizhang82 deleted the defaultintf branch April 6, 2017 06:59

karelz modified the milestone: Future Aug 28, 2017

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Default Interface Method Prototype #10505

Default Interface Method Prototype #10505

yizhang82 commented Mar 27, 2017 •

edited

Loading

jkotas commented Mar 27, 2017

davidwrighton Apr 4, 2017

yizhang82 Apr 5, 2017

davidwrighton Apr 4, 2017

yizhang82 Apr 6, 2017

davidwrighton Apr 4, 2017

yizhang82 Apr 6, 2017

davidwrighton Apr 4, 2017

yizhang82 Apr 6, 2017

davidwrighton Apr 4, 2017

yizhang82 Apr 6, 2017

davidwrighton commented Apr 4, 2017

yizhang82 commented Apr 6, 2017

Default Interface Method Prototype #10505

Default Interface Method Prototype #10505

Conversation

yizhang82 commented Mar 27, 2017 • edited Loading

jkotas commented Mar 27, 2017

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

davidwrighton commented Apr 4, 2017

yizhang82 commented Apr 6, 2017

yizhang82 commented Mar 27, 2017 •

edited

Loading