-
Notifications
You must be signed in to change notification settings - Fork 264
Fix classic COM errors on non-supported compilers #1194
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
Fix classic COM errors on non-supported compilers #1194
Conversation
Also, enable fast path for Clang and give friendlier errors to MSVC
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
|
Looks the build is completely broken again... @DefaultRyan |
|
Looks like NuGet stuff is failing, I don't imagine my PR is the source of these issues. |
|
Looks like this: microsoft/azure-pipelines-tasks#16088 issue here. Investigating how to workaround. |
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
|
I think I may have figure out a fix. Our build pipeline actually had an explicit "Use NuGet version x" step, but it was only being used on manual builds for some reason. I took out the conditional to have it run always, and upped the NuGet version from 5.3 to 6.0.2 while I was at it, and got a successful pipeline run internally. I just kicked off a run here, so let's see if that goes well. |
|
PS: Moving our pipeline over to be YML-based would probably help in that we'd have more visibility and transparency with what's actually happening in the pipeline. But as with everything, that conversion would take time, and I'm not sure if the value provided would be worth the effort. Anybody have any thoughts? Is there a big clamoring for this to happen that I'm unaware of? |
|
I recently changed the build agents to a newer Windows version so that they would have VS2022 installed. I had only worked with YML build definitions before that (not with the classic UI). I found it a bit confusing and think it would have been easier to make that change if the Windows version was in YML for each phase of the build. (The version needed updating for like 3 or 4 levels of job and I kept missing some). |
|
Wish we had negative unit tests - this is impossible for me to "code review". 😭 |
…winrt/base.h in MSVC
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
Also, enable fast path for Clang and give friendlier errors to MSVC.
Testing the
__has_declspec_attributepath revealed to be a bit tricky, because a bunch of CRT headers rely on MS extensions. I ended up passing-fno-declspecto disable__declspecspecifically and then adding#define __declspec(x)to no-op all the__declspecin the CRT headers and cppwinrt. This finally gave the desired error: