You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In commit d23f681 I have modified the IL2C/Invoke test code.
Originally, the test case was configured to run only when it was native code, but as a result of the standardization of the unit testing method, it tries to run this code under CoreCLR as well. From CoreCLR's point of view, the InternalCall implementation is left out, so the error ECall undefined is raised.
I got around this by defining a property called IL2CServices.IsInNativeExecution, but had to place the method call in one call farther away to cheat the JIT.
In real-world code, such a situation is quite possible, but it is somewhat tedious to write such code every time. Also, due to a limitation of the C# compiler, if we use an extern reserved word, we have to mark it as InternalCall, which also seems to be an unintelligible promise (to a beginner).
So, I started to wonder if it might be a good idea to prepare an empty implementation, which was considered in the very first IL2C/Invoke but rejected because of its poor symmetry with DllImport. I started to think about it. In other words, in this case :
This means that it is also considered to be good. In this case, the MethodBody is simply ignored during IL2C conversion, with the same result as using extern.
Moreover, the nice thing about this method is that you can prepare the default behavior when working with CoreCLR.
The text was updated successfully, but these errors were encountered:
In commit d23f681 I have modified the IL2C/Invoke test code.
Originally, the test case was configured to run only when it was native code, but as a result of the standardization of the unit testing method, it tries to run this code under CoreCLR as well. From CoreCLR's point of view, the
InternalCall
implementation is left out, so the errorECall undefined
is raised.I got around this by defining a property called
IL2CServices.IsInNativeExecution
, but had to place the method call in one call farther away to cheat the JIT.In real-world code, such a situation is quite possible, but it is somewhat tedious to write such code every time. Also, due to a limitation of the C# compiler, if we use an
extern
reserved word, we have to mark it asInternalCall
, which also seems to be an unintelligible promise (to a beginner).So, I started to wonder if it might be a good idea to prepare an empty implementation, which was considered in the very first IL2C/Invoke but rejected because of its poor symmetry with
DllImport
. I started to think about it. In other words, in this case :This code is simply:
This means that it is also considered to be good. In this case, the MethodBody is simply ignored during IL2C conversion, with the same result as using
extern
.Moreover, the nice thing about this method is that you can prepare the default behavior when working with CoreCLR.
The text was updated successfully, but these errors were encountered: