Skip to content

Conversation

@BillyONeal
Copy link
Member

@BillyONeal BillyONeal commented Jul 7, 2020

This is to resolve Microsoft-internal:

(which all boil down to 'getting yelled at for not turning on /analyze')

Functional changes:

  • Added annotations for consistency to definitions
  • Added what I hope are 'obvious' _Analysis_assume_s
  • When a function sometimes filled in a value and sometimes did not, and the parameter was annotated _Out_, I removed the annotation as the annotations to tell PREfast that the parameter is conditionally _Out_ exceed any value they might give us.
  • Filed multprec.cpp: _MP_Rem has apparently nonsense memory read #1008 for a 'probably a bug but I'm not sure' case in _MP_Rem
  • Blindly suppressed additional warnings in ConcRT and Boost as there is nothing we can do about them here
  • Changed __crtInitializeCriticalSectionEx to return the value of InitializeCriticalSectionAndSpinCount rather than always return TRUE; in Vista or later this is no functional change, and on XP it will pass through the result correctly. Most callers are still ignoring the return value (as they probably should, now) but this avoids a warning here.
  • Changed _Wcsxfrm to use RAII to record when bbuffer is allocated rather than extra null checks.
  • Changed Xp_setw to hoist constexpr comparisons into an if constexpr block.
  • Added _PThrow null check before calling RtlPcToFileHeader in excptptr.cpp.

@BillyONeal BillyONeal requested a review from a team as a code owner July 7, 2020 09:30
@CaseyCarter CaseyCarter added the bug Something isn't working label Jul 7, 2020
Copy link
Member

@StephanTLavavej StephanTLavavej left a comment

Choose a reason for hiding this comment

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

The arm/arm64 builds are failing. From the error log:

C:\agent\_work\1\s\stl\src\winapisupp.cpp(493,1): error C2220: the following warning is treated as an error
C:\agent\_work\1\s\stl\src\winapisupp.cpp(490) : warning C28251: Inconsistent annotation for '__crtQueueUserWorkItem': this instance has no annotations. See c:\agent\_work\1\s\stl\src\awint.hpp(232). 

@StephanTLavavej

This comment has been minimized.

@BillyONeal

This comment has been minimized.

@BillyONeal
Copy link
Member Author

(In fact I'd rather this land after the atomic wait stuff since that adds new APIs that are likely to make PREfast unhappy)

And follow the style in threadpoollegacyapiset.h.
The functional changes are:

* `__crtFlsAlloc`: Change `lpCallback`
  from `__in` to `_In_opt_`
  as declared in `fibersapi.h`
* `__crtCreateEventExW`: Change `dwFlags`
  from `__reserved` to `_In_`
  as declared in `synchapi.h`
* `__crtGetFileInformationByHandleEx`: Change `lpFileInformation`
  from `_Out_` to `_Out_writes_bytes_(dwBufferSize)`
  as declared in `WinBase.h`
* `__crtSetFileInformationByHandle`: Change `lpFileInformation`
  from `_In_` to `_In_reads_bytes_(dwBufferSize)`
  as declared in `fileapi.h`
* `__crtGetLocaleInfoEx`: Change `lpLCData`
  from `_Out_opt_` to `_Out_writes_opt_(cchData)`
  as declared in `WinNls.h`
@StephanTLavavej
Copy link
Member

Building with /analyze is noticeably slower. Are there other possibilities, like making this off-by-default for developers, but with coverage in the CI, assuming that /analyze build breaks will be relatively rare?

@BillyONeal
Copy link
Member Author

Building with /analyze is noticeably slower. Are there other possibilities, like making this off-by-default for developers, but with coverage in the CI, assuming that /analyze build breaks will be relatively rare?

Sure, we can do that; I didn't bother before because I figure our test pass takes ~an hour and our build takes ~30 seconds, and turning this on makes it take ~45 seconds; but the test pass still dominates. Making it a CMake configurable option is probably a good idea.

@StephanTLavavej
Copy link
Member

Pushed a fix for the build break, which was simple - define __crtQueueUserWorkItem with SAL, like the rest of the definitions. But then I noticed that awint.hpp had different SAL annotations from the WinSDK, some stylistic but some significant. I updated the SAL, changing deprecated __meow to modern _Meow_ (note: not a mechanical in-place conversion; each occurrence was taken from the WinSDK) and fixing the differences. (I'm not sure if they were taken from an older WinSDK, or what. I used the WinSDK that's currently checked into the MSVC-internal repo.)

I ran full clean builds of x86/x64/arm/arm64 and they succeeded.

@BillyONeal
Copy link
Member Author

Thanks for running that down Stephan :D

@StephanTLavavej StephanTLavavej self-requested a review July 15, 2020 08:32
@BillyONeal BillyONeal self-assigned this Jul 16, 2020
@StephanTLavavej StephanTLavavej dismissed their stale review July 16, 2020 01:10

Fixed build break, need to actually review changes now

# Conflicts:
#	stl/inc/xfilesystem_abi.h
#	stl/src/filesystem.cpp
@StephanTLavavej

This comment has been minimized.

@StephanTLavavej
Copy link
Member

I resolved the merge conflict; the code in parallel_algorithms.cpp was deleted, and I verified that this PR's addition of _Analysis_assume_(_Kernel32); didn't need to be moved anywhere else.

@BillyONeal
Copy link
Member Author

Thanks STL

Copy link
Member

@StephanTLavavej StephanTLavavej left a comment

Choose a reason for hiding this comment

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

Only change requested is to make the /analyze build off by default, and enabled for PR/CI builds.

@StephanTLavavej StephanTLavavej removed their assignment Aug 20, 2020
@cbezault cbezault added the build Related to the build system label Aug 24, 2020
@BillyONeal
Copy link
Member Author

Thanks Curtis!

@cbezault cbezault requested a review from mnatsuhara August 24, 2020 20:44
@cbezault
Copy link
Contributor

I'm not sure how to verify that the changes I made make /analyze run in the CI since the output isn't any different...

@CaseyCarter
Copy link
Contributor

CaseyCarter commented Aug 24, 2020

I'm not sure how to verify that the changes I made make /analyze run in the CI since the output isn't any different...

Temporarily Inject a code pattern that /analyze warns about and see if the CI breaks? (Possibly as a test PR from a different branch so as not to break this one?)

@StephanTLavavej
Copy link
Member

The build break was that /clr:pure is /std:c++14, so using if constexpr in xxxprec.hpp triggered the Future Technology warning. The simplest way to silence this was to use the STL's header warning suppression machinery, which determines whether that warning needs to be suppressed (in addition to silencing other noise that we never care about). I didn't use the whole public header guard, just the MSVC warning fragment.

@StephanTLavavej StephanTLavavej self-assigned this Aug 26, 2020
@StephanTLavavej StephanTLavavej merged commit 5bf2826 into microsoft:master Aug 26, 2020
@StephanTLavavej
Copy link
Member

Analyzing change... 🤖 Beep! Thanks for this improvement, human! 🚀

@BillyONeal BillyONeal deleted the analyze branch September 23, 2020 02:43
@StephanTLavavej StephanTLavavej mentioned this pull request Jun 21, 2022
4 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

bug Something isn't working build Related to the build system

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants