Job has been failing for months and is preventing other PRs from getting
merged. This PR fixes the pipeline - it changed the following:
- runs on macos-latest-large (which is a non-arm image)
- starts the emulator under java8 (see
https://learn.microsoft.com/en-us/java/openjdk/transition-from-java-8-to-java-11)
- runs emulator with -no-audio
The above were requirements to get the pipeline running. Other changes
include the following:
- The job will auto-cancel when a newer commit is pushed to the
PR.
- The 'Wait for emulator ready' step now has a 2 minute timeout. This
is necessary because we get no indication on whether or not the
command that started the emulator suceeded. I believe there is room
for improvement here, but it is outside the scope of the PR.
Two warnings were being emitted in the MSVC+LLVM tests.
The warning `-Wunsafe-buffer-usage` is initially introduced in some capacity here https://reviews.llvm.org/D137346 pointing to documentation at https://discourse.llvm.org/t/rfc-c-buffer-hardening/65734. The warning is a stylistic checker whose goal is to "emit a warning every time an unsafe operation is performed on a raw pointer". This type of programming model is not useful for library implementations of types such as `span`, where direct manipulation of raw pointers is inevitable, so disable the warning altogether.
There is also a false-positive warning https://github.com/llvm/llvm-project/issues/65689 that I've disabled inline.
`size_bytes()` returns the span's size in bytes.
Assuming the span was constructed with an accurate size parameter, the check `size() < dynamic_extent / sizeof(element_type)` isn't required, since `size_t(-1)` (which is `dynamic_extent`) represents the size of the address space, so the number of bytes will never exceed it and in practice won't even come close.
Otherwise, it is not actually feasible to detect cases when the size parameter does not correspond to the dimensions of the underlying data pointer. In these cases, the relationship `size() < dynamic_extent / sizeof(element_type)` is simply one of many ways in which the `size()` could be incorrect, and serves no necessary purpose.
Resolves#1012
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`
- `fail_fast`,`basic_string_span` and `basic_zstring_span` are not declared in the headers any more.
- Name the exporting header file for all types in `GSL.natvis`.
This solves issue #1070 and removes the class `string_span`. The only content remaining in the header file `gsl/string_span` is the `*zstring` types.
This also removes the `string_span_tests.cpp` unit tests as these were only for the deprecated `string_span` class.
Co-authored-by: Werner Henze <werner.henze+gitcommits@posteo.de>
The Clang compiler for MSVC in Visual Studio 2022 17.4.33122.133 used by the test runner has a bug which raises -Wdeprecated "out-of-line definition of constexpr static data member is redundant in C++17 and is deprecated" in gsl/span, when compiling with C++14. Temporarily suppress this warning for MSVC Clang with C++14.
This avoids propagating -std=c++14 as a compile option
Currently if you use less than CMake 3.8 and you install the project
`-std=c++14` gets added to the INTERFACE_COMPILE_OPTIONS. This forces
users to use C++ 14 or remove the property from the imported target.
The solution is to raise the minimum and use `cxx_std_14`
Closes issue #550, which highlighted overhead in not_null::get for larger types such as shared_ptr. Every call to get would return a copy of the contained value.
This PR implements Herb's suggestion for changing the return type of not_null::get. The not_null's value will now only be copied if it is "trivially copyable"; otherwise, it will be returned by const reference.
Note: this change also forces the returned copy to be const.
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.
In the implementation of gsl::narrow, there is a comparison `static_cast<U>(t) != u` which may be comparing two floats.
The comparison here is done purposefully to categorize ill effects of narrowing conversion, since the values being compared *should* be the same when compared with `operator==`.
Note, using #pragma GCC will suppress this warning for both GCC and Clang.
The following reserved identifiers are being used specifically to target certain MSVC constructs, so suppress the warning in VS 2022 (LLVM) "... is reserved because it starts with '_' followed by a capital letter":
- _Unchecked_type
- _Verify_range
- _Verify_offset
- _Unwrapped
- _Unwrap_when_unverified
- _Seek_to
- _Unchecked_begin
- _Unchecked_end
* 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>
* Require Git for build tests only if installed GTest is not found
Cloning via Git is not the only path to obtain Google Test framework. In Linux,
using a system package manager is the preferred way, and gtest can be installed
through APK, APT, DNF, pacman, or many other. Now we make Git mandatory after
checking GTest existence.
See also: https://github.com/microsoft/GSL/pull/961#discussion_r548959056
* Support standalone tests
The patch makes possible to run auto-tests against globally installed GSL,
ignoring local headers. To do this, run CMake in the tests/ folder.
cmake -B build -S tests -DGSL_CXX_STANDARD=14
This feature should not break existing build recipes.
Co-authored-by: Nicholas Guriev <nicholas@guriev.su>
* [cmake] Adding options for INSTALL and TEST (#964)
* [cmake] Adding GSL_INSTALL option
Not all consumers of GSL automatically want to have this install logic.
It's good practice to gate install logic behind an option.
For an example look at magic_enum:
https://github.com/Neargye/magic_enum/blob/master/CMakeLists.txt
If the client wants to install GSL they still can. But they should ask
for it by overriding GSL_INSTALL.
* Update cmake/guidelineSupportLibrary.cmake
added nl@eof
* Update CMakeLists.txt
* Update CMakeLists.txt
Co-authored-by: Juan Ramos <juanr0911@gmail.com>
Co-authored-by: Jordan Maples [MSFT] <49793787+JordanMaples@users.noreply.github.com>
* missing config line restored by moving GNUInstallDirs back to main file
Co-authored-by: hdf89shfdfs <31327577+hdf89shfdfs@users.noreply.github.com>
Co-authored-by: Juan Ramos <juanr0911@gmail.com>
* [cmake] Adding GSL_INSTALL option
Not all consumers of GSL automatically want to have this install logic.
It's good practice to gate install logic behind an option.
For an example look at magic_enum:
https://github.com/Neargye/magic_enum/blob/master/CMakeLists.txt
If the client wants to install GSL they still can. But they should ask
for it by overriding GSL_INSTALL.
* Update cmake/guidelineSupportLibrary.cmake
added nl@eof
* Update CMakeLists.txt
* Update CMakeLists.txt
Co-authored-by: Juan Ramos <juanr0911@gmail.com>
Co-authored-by: Jordan Maples [MSFT] <49793787+JordanMaples@users.noreply.github.com>
