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

[DllImportGenerator] Remove unnecessary DLLIMPORTGENERATOR_ENABLED ifdefs #61345

Merged
merged 1 commit into from
Nov 9, 2021

Conversation

elinor-fung
Copy link
Member

Only went through the ones that are in projects that no longer even build down-level.
There's more we should be able to clean up now that we have the forwarding support.

cc @AaronRobinsonMSFT @jkoritzinsky

@jkoritzinsky
Copy link
Member

Now that we have down level support, we should consider updating the code fix that uses this preprocessor option. I don’t know if it’s as useful as it was previously.

@elinor-fung
Copy link
Member Author

Agreed - where updating means deleting that option?

I want to make sure we get through actually turning on / using the generator for all the down-level runtime libraries first though, and then do that as part of clean-up for productization.

@@ -8,13 +8,8 @@ internal static partial class Interop
{
internal static partial class Advapi32
{
#if DLLIMPORTGENERATOR_ENABLED
[GeneratedDllImport(Interop.Libraries.Advapi32, EntryPoint = "ConvertStringSidToSidW", CharSet = CharSet.Unicode, SetLastError = true)]
[GeneratedDllImport(Interop.Libraries.Advapi32, EntryPoint = "ConvertStringSidToSidW", CharSet = CharSet.Unicode, ExactSpelling = true, SetLastError = true)]
Copy link
Member

Choose a reason for hiding this comment

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

Was the addition of ExactSpelling here just an opportunistic addition? Should we be using it in other places we're not currently

Copy link
Member Author

Choose a reason for hiding this comment

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

Yeah, this was just opportunistic - I just noticed that already had the W suffix while doing this.

internal static partial int GetWindowsAccountDomainSid(
#else
[DllImport(Interop.Libraries.Advapi32, EntryPoint = "GetWindowsAccountDomainSid", CharSet = CharSet.Unicode, SetLastError = true)]
internal static extern int GetWindowsAccountDomainSid(
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 have an analyzer that warns when specifying a CharSet and it's a nop? I assume that's how you spotted these? But if that's the case, why wasn't it previously firing for this #if case? Or is it just a suggestion right now that doesn't trigger warn-as-error build failures?

Copy link
Member Author

Choose a reason for hiding this comment

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

We don't. I just did a quick scan through the changes I had and manually updated a few things.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants