-
Notifications
You must be signed in to change notification settings - Fork 107
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
Disable runtime marshalling for the CsWinRT repo. #1431
Disable runtime marshalling for the CsWinRT repo. #1431
Conversation
Just so I understand, is this to start catching all remaining cases and address them? Because I can't see things just working with no changes at all after enabling this flag, especially given I know there's still other PRs removing more marshalling stuff 😅 Either way, absolutely love this, and it was about time! 🚀 |
The goal is to see what is going to break. But I am curious which marshaling thing you are referring to? |
Gotcha, yeah that makes perfect sense 👍
I was thinking of those in #1416, plus I expect some more stuff will also break. For instance:
|
Unrelated, it seems like the CI isn't running? Is this because the source branch is from another fork? |
Right, we don't automatically run CI for forks. |
That PR was trying to port the changes already in the staging branch to master. The staging branch should already have blittable signatures. It would be interesting to see which Marshal functions break when the tests run. |
Some tests use runtime marshalling which is fine, so I scoped it down to actual artifacts produced by this repo. |
The changes look good to me, but I have to say I feel like I'm missing something here, or maybe I just don't completely understand what does disabling runtime marshalling affect. We have several uses of stuff like |
This change is here to find all remaining cases where we rely on runtime marshalling with the goal of eventually not having any. |
No I know that. I think I got tripped up by the CI being green, that's the part that was not adding up. Question: would it not be better not to merge this PR though, to avoid completely breaking the CI in the branch until we fix everything? As in, we can just keep rebasing this one as it spots more issues, and then we can gradually fix them in other PRs, and only merge this one once the CI for this one is actually all green? And on that note, can't we close and reopen this from a branch in this same repo like I mentioned, to get the CI to actually run from this branch? |
A manually kicked off build is actually green right now. |
What performance improvement can this bring? Is there at least a ballpark estimate? |
No performance difference whatsoever. |
cfc6fce
to
7c3623f
Compare
Disable runtime marshalling for the CsWinRT repo.