Skip to content
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

[3.0] COM Binding Transformation #2406

Open
wants to merge 29 commits into
base: develop/3.0
Choose a base branch
from

Conversation

curin
Copy link
Contributor

@curin curin commented Dec 31, 2024

Summary of the PR

Adds the necessary enhancements to allow for easy to use COM bindings and any changes required to get Microsoft Bindings building.

-Adds TransformCOM mod to implement in place ComPtr transformations in all COM classes
-Adds DisableWarnings mod to disable warnings in all files for a job in order to avoid build errors from unavoidable or ignorable errors
-Adds several additions to ClangScraper to disable caching and remove generated files from the output.
-Adds some QOL improvements such as --only and csv list support to silk touch

@Perksey Perksey changed the base branch from main to develop/3.0 December 31, 2024 15:04
@curin curin marked this pull request as ready for review January 10, 2025 02:25
@curin curin requested a review from a team as a code owner January 10, 2025 02:25
@curin
Copy link
Contributor Author

curin commented Jan 10, 2025

@Perksey Ready for Review

Copy link
Member

@Perksey Perksey left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice work! It's cool to see this come together :)

Some notes...

@Perksey
Copy link
Member

Perksey commented Jan 12, 2025

Obviously note the CI errors as well if you haven't already.

Copy link
Member

@Perksey Perksey left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry this review is a bit all over the place, I wrote things as I saw them so comments may not be placed at their root causes.

Glad to see this moving along nicely.

/// <summary>
/// compares boolean value and int
/// </summary>
/// <param name="lh"></param>
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I haven't really called this out in past PRs as it is a bit of a nitpick, but it would be nice if you did fill out the documentation template generated!

[MethodImpl(
MethodImplOptions.AggressiveInlining | MethodImplOptions.AggressiveOptimization
)]
public static implicit operator Ptr(nuint ptr) => new(ptr.ToPointer());
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not completely comfortable with -> Ptr being implicit. The other direction is fine, but we should make it a little harder to accidentally interpret a random integer as a pointer.

[MethodImpl(
MethodImplOptions.AggressiveInlining | MethodImplOptions.AggressiveOptimization
)]
public static implicit operator Ptr<T>(nuint ptr) => new((T*)ptr.ToPointer());
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same comment.

/// <summary>
/// Represents a native interface structure
/// </summary>
public unsafe interface INativeInterface
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this required by ClangSharp? If not we probably want to hold off on designing generalised abstractions over OOP ABI mechanisms until we have information on the other mechanisms we want to support. Recommend folding into IComInterface for now.

/// <summary>
/// Class that provides some simple functions for displaying a progress bar for the generator
/// </summary>
public static class ProgressBarUtility
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not a fan of this being static. I also don't like us interacting with stdout directly given that SilkTouch has been designed to be somewhat embeddable, in that you can create your own DI container and just call AddSilkTouch - it is possible that there is no desire in this application for SilkTouch to interact with the console at all.

If we're keeping this, I recommend making it a DI interface that is added to the service collection scoped to each job (this way we don't have to do the multi-threading handling either).

In the long run something similar to how MSBuild's TerminalLogger (the default one these days) logs to console would be cool (obviously with a progress bar) but there's no need to go too crazy.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This does not work well with multithreading as it is editing the console output directly so that the loading bar gets overwritten. It needs to be done with a certain statefulness across threads since the console exists across threads. Moving it to a central thread could work but unfortunately you need to handle the logger outputting to the console and need to remove the progress bar before writing logs.
This is meant as simple utility to be used in cases where my sanity was dwindling due to watching nothing happening on the console for minutes at a time.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm fine if we want to pull this out it was more for my sanity than anything and I was more like we'll it's here and works but to do it right would take more work.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah I agree we should definitely figure something out to make the user experience better, but we should probably spend more time figuring out the best way.

// Check if the type is a ComType
if (typeInfoR.Type != null && ComTypes.Any(type => $"{type.Item1}*" == nameR))
{
return BinaryExpression(node.Kind(), node.Left, IdentifierName($"{node.Right.ToFullString()}.lpVtbl"));
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we want to exclude fields that are named differently from TransformInterfaces? Not a leading question, genuinely not sure if we should keep the hardcoded check or whether it makes sense.

FileScopedNamespaceDeclarationSyntax node
)
{
_namespace.Add(node.Name.ToString());
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think there's a common utility function that will get the namespace that a descendent node is in.

)
)
.WithSemicolonToken(Token(SyntaxKind.SemicolonToken))
.WithLeadingTrivia(
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we move some of the trivia construction out to something reusable? It's very verbose and repeated a lot throughout this file.

Copy link
Contributor Author

@curin curin Feb 8, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I do have this fixed as I handled all the casts to use the same function. Will let you know when that update is added

Perksey and others added 21 commits February 15, 2025 18:33
-also support for csv lists in --only and --skip
-Setup to run using new mod system properly
-Added pointer member accessor to member accessor conversion
-Added Logging
per Mod Performance
-Added early out
-fix duplicate call
-Add INativeGuid
-fixed some broken using from TerraFX files
-Allowed BaseType to be specified for ComTypes
-Added several files for override due to issue in generation
-allowed for multiple COM base types
-allowed for addition of manual COM types
-added several manual overrides
-added all manual files necessary for compilation
Fixed some manual warnings as well
This reverts commit 0a1bd47.
-using globbing instead of regex
-removed an unnecessary restriction on interface finding
-updates single line code to expression bodies
Co-authored-by: Dylan Perks <[email protected]>
for rollback purposes
moved to internal Native struct
INativeInterface and IComInterface added to represent all interfaces and Com interfaces, respectively.
- IComInterface is a child of INativeInterface and INativeGuid
-and fixing issues with how it works
added manual file importer
added a progress bar in some cases for QoL
moved rename function into NameUtils
Added per job file logs
fixed up the progress bar system to be cleaner
@curin curin force-pushed the develop/3/com-bindings-refactor branch from 6c6d633 to fe2f36c Compare February 16, 2025 00:05
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: In Progress
Development

Successfully merging this pull request may close these issues.

2 participants