Revert result macros to be noexcept again

[lhecker]

A number of result macros aren't declared as noexcept which causes C26447
warnings if they're used within a noexcept context. This can make them
uncomfortable to use in the Terminal project which has this warning enabled.

It appears as if the noexcept attribute was removed in/around OS PR !2943876,
when C++17 was enabled for a project. This resulted in a conflict with the
__forceinline attribute and caused the FailFast_IfWin32Error function
to be exported from the .lib erroneously. DevDiv-748887 seems to
be the related bug report for MSVC and was resolved in VS 16.1.

This PR was tested by building (chk, dev) the .lib mentioned in !2943876
and comparing the dumpbin /SYMBOLS output before and after the change.
Apart from a size reduction of 16 bytes, nothing changed.

[jonwis]

This might be a tricky one to bring back into the OS, depending on how complicated (or not) people's logging/telemetry callouts are. Overall goodness, though. Thanks.

[lhecker]

@dunhor @DefaultRyan Could you help me get this PR reviewed? 🙂

[dunhor]

This might be a tricky one to bring back into the OS, depending on how complicated (or not) people's logging/telemetry callouts are. Overall goodness, though. Thanks.

Ideally changes like this should go into the OS directly for the obvious reasons, however I'm not opposed to bringing it in through here. There's just a non-zero risk that it will need to be reverted if issues arise. It is the responsibility of the author to do due diligence, but it sounds like that's been done here so I have no objections.

[dunhor]

FYI - this has been reverted. The relevant error is:

error C4981: Warbird: function 'long __stdcall wil::details::in1diag3::Log_IfFailed(void *,unsigned int,char const *,long)' marked as __forceinline not inlined because it contains exception semantics

The (maybe) good news is that the impact didn't seem too broad, so maybe there's hope in fixing them up. Either way, this change likely needs to be done in the OS repo. I tried looking into the cause, but I was ultimately unable to repro it locally and kind of ran out of time for investigation.

[lhecker]

Ugh, damn. I'm extremely sorry for the extra work I caused for you. 😔
I'll try to submit an internal PR for this sometime soon.

[dunhor]

No worries. Like I said, the impact was very limited. IIRC it was like 2 directories (albeit in the OneCore build, so IDK if the build just didn't make it far enough to expose other failures.

Looking back now, it seems 'C4981' is just a warning, so it may very well be the case that the warning can be avoided with a localized disabling of the warning. On top of being an issue with an obscure compiler feature, if it didn't take me so long to try and get a repro - and had I actually succeeded in getting a repro - I probably could have just tried it out myself, but I ultimately ran out of time :/