Skip to content

More various cleanups - #2621

Merged
Stephan T. Lavavej (StephanTLavavej) merged 8 commits into
microsoft:mainfrom
StephanTLavavej:cleanups
Apr 4, 2022
Merged

Stephan T. Lavavej (StephanTLavavej) merged 8 commits into
microsoft:mainfrom
StephanTLavavej:cleanups

Conversation

@StephanTLavavej

@StephanTLavavej Stephan T. Lavavej (StephanTLavavej) commented Mar 29, 2022

Copy link
Copy Markdown
Member

Some of these are things I've noticed while reading every line of the STL's headers for Standard Library Modules, but they aren't blocking anything.

  • In tests/libcxx/expected_results.txt, change 2 tests from FAIL to SKIPPED. This avoids unexpected passes when running set_environment before running the tests. (Because set_environment puts the freshly-built STL on the INCLUDE path, Clang suppresses warnings from those "system headers", so if tests are expected to FAIL due to such warnings, they will instead unexpectedly pass.)
    • This is a quality-of-life improvement for myself, as I always run set_environment.
  • Update .github/workflows/update-status-chart.yml as new versions of actions/checkout and actions/setup-node are now available. Also update node-version (as usual, it's not critical to keep this constantly updated.)
    • Tested in my fork.
  • In <variant>, DevCom-1004719 "Bogus warning C4100 'unreferenced formal parameter' emitted by if constexpr" was resolved as fixed, but it still repros in the compiler's own sources. I've filed VSO-1513409 internally with a preprocessed file, so we should update the bug citation.
  • Several classes were implicitly using private access control. We conventionally say private explicitly. (With exceptions for friend declarations and static_asserts where the access control doesn't matter.)
    • Initially noticed while reading all headers, then audited via regex, so this list is fairly comprehensive (didn't bother looking outside STL headers).
  • We were unnecessarily repeating access specifiers in <sstream> and <xtree>.
    • Noticed while folding class members in VSCode - I don't have a more automated way to scan for this.
  • In <charconv>, we should use _STL_INTERNAL_STATIC_ASSERT for our internal array sizes - there's no reason to perform such validation during user compilations. (The static assertions themselves are probably overly paranoid.)
  • Comment the <cwctype> #undefs.

Comment thread tests/libcxx/expected_results.txt
@StephanTLavavej

Copy link
Copy Markdown
Member Author

I'm mirroring this to the MSVC-internal repo - please notify me if any further changes are pushed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

enhancement Something can be improved

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants