-
Notifications
You must be signed in to change notification settings - Fork 56
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
Draft-only PR #161
Draft-only PR #161
Conversation
@jkoritzinsky it would be great to have an initial feedback on the PR. Actual review is not needed, but I am interested in upstreaming these changes and I need confirmation they're worth upstreaming. |
Everything here seems like a good idea to me. |
There are some issues with CodeCov token. Doesn't matter for this PR, but in general. |
@jkoritzinsky the only issue left is everything coverage-related, reproducible only on AzDO:
Running build.ps1 and test.ps1 locally works fully (coverage reported correctly). The whole coverage situation in .NET world seems extremely fragile at the moment. No proper report merging, known deficiencies in AzDO publish coverage task, coverlet team still working on v2 tool spec. I'd say it's not worth the trouble. I'll split this PR tomorrow into:
|
I'd be fine dropping code-coverage checking for a while. It was primarily important when I was doing full rewrites of the C# code generator to make sure I got all the special cases. If it's working locally though, I'd prefer to move the code coverage handling under a switch so that I can still use it locally when changing marshalling. It's fine if we turn it off in CI. I'll go disable the check. Those 3 PRs sound like a great way to split this. Thanks for your contributions! I really appreciate it! |
Once #165 is merged, I'll rebase this and split into multiple PRs. |
341ada7
to
7a1b779
Compare
I've rebased everything I had on the latest master, and committed everything I have on the refactored SharpGen pipeline. This is still WIP:
Of course upstreaming this will take a long time (splitting this into chunks — nightmare). There is a new code here taken from 3rd party projects:
Both have MIT-compatible non-copyleft licenses, but this still needs to be taken care of:
I'm thinking my 3rd PR (RotS) will contain a lot of refactorings, except for the main one (merging tasks into one). I'll try to put it together tomorrow. |
Some progress (not pushed to remote):
To-do before I can call it a win:
Sadly, I can't drop BSD-licensed code, I'm afraid it will have to be taken into account when merged into SharpGen v2 master branch. I still haven't prepared the next PR. :( |
Done for now. I still haven't prepared the next PR, and I won't be able do that until the mid-July. :( |
7110a87
to
fe1a322
Compare
In my local branch I have a partially complete implementation of C# 9.0 function pointers codegen. The updated Microsoft Docs doc provider was previously in this repo, but I've moved it back into its own repo, private for now until we get the extensibility working. |
de688e8
to
3a77263
Compare
Published |
c18247f
to
0159b0e
Compare
Per discussion in #173, dropped delegates & assembly patching impl. Only fnptrs impl remains. I'll investigate if major |
Okay, I've successfully reverted a lot of changes (including splitting |
68da171
to
2bdb51f
Compare
89c666f
to
0ce28ae
Compare
Migrate tonet472;netcoreapp2.1
(MSBuild requiresnet472;netcoreapp2.0
, .NET Core 2.0 is EOL, 2.1 is the closest LTS)Update dependencies,minor code cleanupsFix bug in SharpGen MSBuild targets (it was impossible to overrideSharpGenSdkAssembly
path)Support multiple relations (see,cDimension
there is a length for bothinitialValue
andinitialVelocity
), e.g.length(initialValue),length(initialVelocity)
. Proper parsing for relations using Superpower toolkit.Prevent crash when relation specifies parameter name, which is absent on the method. Print helpful message instead.Workaround MSBuild Core not loadingMicrosoft.Win32.Registry
implementation dll (I suspect bug in MSBuild assembly load context override) by building RuntimeIdentifier-specific assemblies (win;unix
).Workaround MSBuildSdkExtras bug with the previous point; upd: I've submitted PR to MSBuildSdkExtras to make this better.Result
.Result
is forcibly mapped toint
, so the shadow callback returnsint
. But the actual C# interface returnsResult
, andResult
->int
cast is explicit, not implicit. Generate explicit cast.This PR is not meant to be merged (never ever), instead, it is the basis from which chunks can be torn out and upstreamed.
I'd like to have a feedback on these changes, if they are in line with SharpGenTools goals, if they are worthy of upstreaming, if there is a better way to accomplish their aims.The only thing left now, preventing the correct binding generation in my project, is marshalling primitive arrays (double[]
) in callbacks Vtbl (memory provided by caller, the callback must fill an array and returnResult
). SharpGen generates new array allocation instead of using the pointer received (that pointer is being cast to the correct pointer type and then forgotten).fast
fixes theNative
part, but not theVtbl
. I'll fill the issue if that is not a known issue.This PR is being separated into multiple and upstreamed.