Closed bbannier closed 2 weeks ago
Hi Benjamin! :smile:
The issue is, that the standard demands copy_options
to be a class enum of bit values like this (the actual values of each flag are unspecified though):
enum class copy_options : uint16_t {
none = 0,
skip_existing = 1,
overwrite_existing = 2,
update_existing = 4,
recursive = 8,
copy_symlinks = 0x10,
skip_symlinks = 0x20,
directories_only = 0x40,
create_symlinks = 0x80,
create_hard_links = 0x100
};
And to have operators in place to use them in and/or operations as bit-mask creating result values of type copy_options
.
It is clear that any result of these operators will not be a value of the enum, but that is how the API is specified, so I don't see a good way to fix this without either breaking compliance or filling the enum up with dummy values for all valid combinations (that would be 512 entries in total). Neither seems like a good idea and for example libstdc++ does nearly the same.
Thanks for having a look and the explanations! I believe I see similar issues around fs::perm_options
and it seems a more general issues. Looking at llvm/llvm-project#76208 this seems to be a false positive, so I am closing this issue. I do not think it makes much sense to suppress this since clang-tidy seems to plan to fix this.
We are trying to bump CI linting to
clang-tidy-18
and notice that it reports an issue aroundfs::copy
, namely that code is triggered which attempts to cast an integer to an enum type which does not contain the value.We are building with C++17, but I can see this by adding a test to the project also (C++11).
TBH, I am not entirely sure how this cast comes about at all, please let me know if I am holding it wrong (hi Steffen!).