This is an archive of the discontinued LLVM Phabricator instance.

[libunwind] Compile with -Wunused-but-set-variable
ClosedPublic

Authored by danielkiss on Aug 10 2021, 8:42 AM.

Details

Summary

-Wunused-but-set-variable triggers a warning even the block of code is effectively dead.

Diff Detail

Event Timeline

danielkiss created this revision.Aug 10 2021, 8:42 AM
danielkiss requested review of this revision.Aug 10 2021, 8:42 AM
danielkiss added reviewers: Restricted Project, MaskRay.
MaskRay accepted this revision.Aug 10 2021, 11:21 AM

Thanks!

libunwind/CMakeLists.txt
199

Place below other -Wunused-*

This revision is now accepted and ready to land.Aug 10 2021, 11:21 AM
danielkiss marked an inline comment as done.
danielkiss added inline comments.
libunwind/CMakeLists.txt
199

added in ABC order.

This revision was automatically updated to reflect the committed changes.
danielkiss marked an inline comment as done.
Herald added projects: Restricted Project, Restricted Project. · View Herald TranscriptAug 11 2021, 1:16 AM
Herald added 1 blocking reviewer(s): Restricted Project. · View Herald Transcript

any chance this can inherit flag settings from llvm, so we can make such configuration choices in one place?

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.

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.

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?

MaskRay added a comment.EditedAug 31 2021, 10:33 AM

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.

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/.

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.

MaskRay added a comment.EditedAug 31 2021, 11:07 AM

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/.

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.

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.

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.

-Wall enables -Wunused-but-set-variable, so the CMake change is not needed.

-Wall enables -Wunused-but-set-variable, so the CMake change is not needed.

oh right, dropped.