Added missing tests to kernel32 and DbgHelp.

[AraHaan]

Fixes #224

(Tests created on my Mac)

[AraHaan]

Wait why doesn't the pipeline test ns2.0 as well so it can expose the failures on these when targeting that TFM?

[AArnott]

why doesn't the pipeline test ns2.0 as well

netstandard2.0 isn't a runtime. It's just a standard. Tests can only run on a runtime like .NET Core, .NET Framework, or mono.
It looks like we only run tests on .NET 5, regardless of OS. For the code generation tests that seems adequate since I do not expect the runtime to influence the code generation itself. But we could add more runtimes if necessary.

[AArnott]

We don't want a test for every API to make sure it generated. We have tests for specific APIs that tend to be problematic and throw exceptions during generation, but ultimately those are redundant with our "generate everything" tests. Why do we need these new tests?

[AraHaan]

Because a lot of those api's I added are technically some of the common ones I find that people want to use on the internet, myself included.

Sure, one could use System.Diagnostics.Process but what if that is not provided but those APIs are?

Plus there is an issue where the ProcessId returned from that class (from the Process.GetCurrentProcess() call would not return the native ProcessId and instead the "managed" one when needing to call an unmanaged api and then as that is concerned it is according to the OS is not a valid id or is an id that points to an entirely different process.

I guess I could remove 3 of the tests but add them to the interesting apis.

• GetCurrentProcess
• GetCurrentProcessId
• GetCurrentThreadId

And have MiniDumpWriteDump and MINIDUMP_TYPE be their own tests.

[AraHaan]

I see this is why I have my issue on my codebase not generating this enum:

  Failed GeneratorTests.GetMINIDUMP_TYPEGeneration [126 ms]
  Error Message:
   Assert.True() Failure
Expected: True
Actual:   False
  Stack Trace:
     at GeneratorTests.GetMINIDUMP_TYPEGeneration() in D:\a\1\s\test\Microsoft.Windows.CsWin32.Tests\GeneratorTests.cs:line 248

Which is odd because it should be constant across all cpu specific builds of Windows 10 that has the latest dbghelp.dll.

I think this should be rebased on top of #272 after that gets merged and see if that test starts to pass but change the other test to somehow test it being generated when it is set up correctly to be generating.

[AArnott]

Because a lot of those api's I added are technically some of the common ones I find that people want to use on the internet, myself included.

To be clear, I'm not arguing that we shouldn't generate those APIs. We do. I'm just saying they already have test coverage as part of the full-generation test. If we have a bug where certain APIs are simply missing in the generated code, then that's certainly worth taking a look at. It sounds like that's what you're saying, so I'll take another look.

[AArnott]

You're using the wrong API here. TryGetEnumName can't be used to verify that the enum is generated.
By adding this.AssertNoDiagnostics(); to the test the generated code is logged as test output and I see that the enum is in fact generated. So no bug here, it seems.

[AArnott]

The trick here is to add this line to the top of your test:

        this.compilation = this.compilation.WithOptions(this.compilation.Options.WithPlatform(Platform.X86));

With that, the test passes. So again, apparently no bug here.

[AArnott]

I don't see the value of testing these individually unless they provide a faster path to exposing an existing test failure in the FullGeneration test.