* clang-format improvements
- Add a clang-format linter check to the PR pipeline
- Apply clang-format to files where the linter initially failed
- Remove `CommentPragmas` from `.clang-format`
- Remove all `// clang-format off` and `// NO-FORMAT` as they are not needed
- Remove a commented out `GSL_SUPPRESS`
* clang-format 20
* pipeline fail
* Update .github/workflows/clang-format.yml
Co-authored-by: Carson Radtke <nosrac925@gmail.com>
* output used clang-format version
* installed version is 18 which replaces "GSL_SUPPRESS(bounds.1)" with "GSL_SUPPRESS(bounds .1)"
* only include/gsl, not include
to prevent formatting of include/CMakeLists.txt
* apply clang-format[-20]
In a VS2026 developer command prompt I ran `clang-format -i include\gsl\* --assume-filename x.cpp`. This was necessary because VS GUI does not format files without an extension :(. Please note that `--assume-filename` is necessary here, otherwise the files will not be formatted. Surprisingly the behaviour for the formatter differs from the behaviour of `lang-format(-20) --dry-run --Werror include/gsl/*` where clang-format recognizes that the files is C++.
* change "#if 0" back to original version with comments only
* formatting scripts for windows and linux
for linux with linter (shfmt and shellcheck)
* add WhitespaceSensitiveMacros: [GSL_SUPPRESS]
* provide path for clang-format (Windows)
Currently not clear to me:
On my personal computer at home, when I start "Developer Command Prompt for VS18", I can run `clang-format` without providing the path.
On my managed (domain) company computer, when I start "Developer Command Prompt for VS18", I can NOT run `clang-format` without providing the path. I need to call `"%VCINSTALLDIR%Tools\Llvm\bin\clang-format"`.
I have no idea what the difference is. At least the version `"%VCINSTALLDIR%Tools\Llvm\bin\clang-format"` works on both computers, so I add the path.
---------
Co-authored-by: Werner Henze <w.henze@avm.de>
Co-authored-by: Carson Radtke <nosrac925@gmail.com>
Co-authored-by: Werner Henze <werner.henze+gitcommits@posteo.de>
* deprecated features adopted into C++
1) Mark the following GSL features as deprecated:
- gsl::unique_ptr (always)
- gsl::shared_ptr (always)
- gsl::byte (since c++17)
- gsl::joining_thread (never implemented)
2) Refactor existing deprecations to use the new GSL_DEPRECATED(msg) macro.
3) Create a section in the README for deprecated features in the
standard.
* do not deprecate gsl::to_integer because we never claim to implement it.
* do not use gsl::byte if it is deprecated
Reverts commit that changes #include "assert" -> #include "gsl/assert".
This change is necessary in order to comply with CppCoreGuideline's
SF.12. Now we do #include "./assert".
Office is seeing build breaks due to `#include "span"` including
C++20 span instead of gsl/span. Most likely we want all headers
includes qualified with "gsl/" to avoid similar issues.
https://github.com/microsoft/GSL/issues/1075
- Add `static_assert` because we only support C style array `at` for up to half of the address space.
- Add `std::` before `size_t`.
- tests:
- Add `#include <exception>`
- Implement `span_tests` `interop_with_gsl_at` like `at_tests` `std_span`
Somewhere along the way, GSL's implementation of final_act and finally seems to have become way overthought. This PR is to re-simplify these facilities back to what C++ Core Guidelines C.30 said which is simple and clear and works. It just copies the invocable thing, and doesn't bother trying to optimize the copy. This should be fine, because we're typically passing something that's cheap to copy, often a stateless lambda.
The problem in #846 appears to be because finally looks like was originally written as a const&/&& overload (its state at the time that issue was opened)... to eliminate a copy when you invoke it with a temporary. If so, then the && was probably never intended to be a forwarder, but an rvalue reference that tripped over the horrid C++ syntax collision where a && parameter magically instead means a forwarding reference because the type happens to be a template parameter type here. So I suspect the original author was just trying to write an rvalue overload, and the forwarder that's there now was never intended at all.
* move span specialization of 'at' to <gsl/span> and update the parameter to be taken by reference
* undid previous changes and acted upon decisions made in maintainer sync. Fixed tests failing in /kernel mode
* ran clang-format on the include folder
* ran clang-format on the test folder
Co-authored-by: Jordan Maples <jordan.maples@microsoft.com>
Carson Radtkeandcopilot-swe-agent[bot]
Carson Radtke
Tiago
d-winsor
dmitrykobets-msft
Herb Sutter
Jean-Michaël Celerier
Jordan Maples [MSFT]andJordan Maples