-Wunused-but-set-variable triggers a warning even the block of code is effectively dead.
Details
- Reviewers
MaskRay - Group Reviewers
Restricted Project - Commits
- rGd212bdf82883: [libunwind] Compile with -Wunused-but-set-variable
rG6b6d34473176: [libunwind] Compile with -Wunused-but-set-variable
Diff Detail
Event Timeline
libunwind/CMakeLists.txt | ||
---|---|---|
198 | added in ABC order. |
any chance this can inherit flag settings from llvm, so we can make such configuration choices in one place?
-Wunused-but-set-variable just added to unwind to be sure warnings won't come back. I don't see where it might cause problems. IIRC global runtime flags will be included in uninwd's cflags.
Sorry, I'm having trouble understanding what you mean - could you rephrase/use a few more words? (if the flag isn't added to libunwind, the warnings wouldn't come back because the warning wouldn't be enabled? The problems I have is that maintaining different flag sets in different subprojects (even if they're only additive) is more work/creates an inconsistent experience across subprojects compared to having all the flags selected in llvm proper so they're consistently used by all subprojects)
Some users do standalone builds. They use libunwind/CMakeLists.txt as the main config, skipping llvm/CMakeLists.txt.
cmake -GNinja -Hlibunwind -B/tmp/out/play In this setting, some llvm/CMakeLists.txt options (e.g. -fvisibility-inlines-hidden) are not inherited to libunwind.
Note that libcxx sets its own options as well as inherits options from llvm/CMakeLists.txt. I am on the fence whether libunwind should inherit llvm/'s options.
Not an absolute requirement - but I did want to check if it was possible/reasonable. If this is only to support parity in a standalone build, perhaps we should document/comment that the list should be kept in sync with some list in the LLVM build files?
Looks like the libunwind warning list is stronger than llvm's (scattered in llvm/cmake/modules/HandleLLVMOptions.cmake).
I think it is probably fine to not duplicate options which are also set in llvm/.
Perhaps not many groups use standalone builds, so losing some warning options is fine.
llvm/'s warnings are under LLVM_ENABLE_WARNINGS, while libunwind specifics are unconditional. Now I am unsure what to do.
I don't mind setting them if someone wants standalone builds to have more parity with non-standalone. But I'd object more to adding extra warnings per project without a pretty significant reason that one subproject should differ from others.
Perhaps not many groups use standalone builds, so losing some warning options is fine.
llvm/'s warnings are under LLVM_ENABLE_WARNINGS, while libunwind specifics are unconditional. Now I am unsure what to do.
If this flag isn't turned on for non-standalone builds/turned on in LLVM, then I'm not sure what issue the patch is intending to address. There wouldn't be any inconsistency, there wouldn't be any regression issue (like some builds checking the warning and some not checking it - so someone in the non-checking build committing a warning violation, breaking the checking build) if the flag wasn't added?
But if someone wants to turn it on for the non-standalone build, that sounds OK. It's probably not especially painful to cleanup.
Agree.
For -Wunused-but-set-variable in libunwind, there is probably another justification: libunwind uses -Wunused-parameter while llvm/cmake/modules/HandleLLVMOptions.cmake disables it.
Since libunwind is -Wunused-parameter clean, we don't want to regress it.
-Wunused-but-set-variable is a close option in the family (though not under the -Wunused umbrella).
It seems ok to set related options together, even if llvm/ will get this option as well.
(Overriding a subset is probably confusing.)
Perhaps not many groups use standalone builds, so losing some warning options is fine.
llvm/'s warnings are under LLVM_ENABLE_WARNINGS, while libunwind specifics are unconditional. Now I am unsure what to do.
If this flag isn't turned on for non-standalone builds/turned on in LLVM, then I'm not sure what issue the patch is intending to address. There wouldn't be any inconsistency, there wouldn't be any regression issue (like some builds checking the warning and some not checking it - so someone in the non-checking build committing a warning violation, breaking the checking build) if the flag wasn't added?
But if someone wants to turn it on for the non-standalone build, that sounds OK. It's probably not especially painful to cleanup.
I support that llvm/cmake/modules/HandleLLVMOptions.cmake adds -Wunused-but-set-variable as well, after some cleanup.
But I'd object more to adding extra warnings per project without a pretty significant reason that one subproject should differ from others.
Flag is added here to have some regression check for the unused variables as this issue come up not just for me.
I'd keep the flag here until it is enable globally.
I'm not sure I understand - what do you mean by "regression" - causing a build to fail because that build had the warning enabled already? Or you mean introducing code that has set-but-unused variables, but without any build failures?
I'd prefer we not enable this warning only for one subproject like this - divergence between subprojects increases maintenance burden and developer flexibility when moving between subprojects.
introducing code that has set-but-unused variables
This what I mean, code is unused variable free and the flag helps to stay as it is.
increases maintenance burden and developer flexibility when moving between subprojects.
I hope this flag is not so harmful nor problematic for new code.
I support that llvm/cmake/modules/HandleLLVMOptions.cmake adds -Wunused-but-set-variable as well, after some cleanup.
Sounds good to me.
Place below other -Wunused-*