* 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>
- `strict_not_null<std::unique_ptr<int>>{ std::make_unique<int>()}` failed to compile
- `strict_not_null` ctor needs to move the passed `unique_ptr`, not copy
- Copied `not_null` `TestNotNullConstructors` for `strict_not_null`
- The `noexcept` specifiers on the `strict_not_null` and `not_null` constructors were out of sync.
- Added unit test for `not_null<unique_ptr<T>>` and for `strict_not_null<unique_ptr<T>>`
- Added unit test for `gsl::swap` for two `strict_not_null`
- Added unit test for `gsl::swap` for `not_null` and `strict_not_null`
Co-authored-by: Werner Henze <w.henze@avm.de>
* 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>
* Added c++17 test configurations for clang5.0 and clang6.0
* Removed explicit not_null constructor, sloppy_not_null, added strict_not_null
We added explicit not_null constructor in version 2.0.0.
It proved very difficult to switch to the new version for
large code bases that adopted previous versions of gsl,
due to not_null used extensively in the code. Still, using
explicit constructor is very benefitial for new code, since
it encorages better API design and make null checks intentional.
To resolve the issue, this change:
- removes explicit keyword from not_null constructor
- removes unneded sloppy_not_null type
- adds strict_not_null type to behave the same way as v2 not_null
- updates tests
* Removed explicit not_null constructor, sloppy_not_null, added strict_not_null
We added explicit not_null constructor in version 2.0.0.
It proved very difficult to switch to the new version for
large code bases that adopted previous versions of gsl,
due to not_null used extensively in the code. Still, using
explicit constructor is very benefitial for new code, since
it encorages better API design and make null checks intentional.
To resolve the issue, this change:
- removes explicit keyword from not_null constructor
- removes unneded sloppy_not_null type
- adds strict_not_null type to behave the same way as v2 not_null
- updates tests
* fixed build break for gcc7
* added more tests
* added more non-compiling tests
* Addressed PR comments and suppressed a code analysis warning
* Fixed test failure in not_null tests
Werner Henze
Carson Radtke
Jordan Maples [MSFT]
Tushar Maheshwari
Roelf-Jilling
Jordan Maples
Anna Gringauze