In D33102, -Wcast-qual was implemented for C++,
so naturally it now produces warnings for clang codebase.
That specific warning
(cast from 'a' to 'b' must have all intermediate pointers const
qualified to be safe)
is clang-specific, i'm pretty sure gcc does not produce it.
To be perfectly honest, i did not thought about trying
to build llvm/clang with the clang with that warning beforehand.
So here is the question: how to proceed?
Revert? Disable that diagnostic? Etc?
Revert now, prepare a patch to fix all warnings during bootstrap.
Commit that one, recommit the original.
I would first revert it now because the bot needs to stay green now.
Then either the warnings can be fixed as a pre-commit to the added feature, or if not possible the LLVM cmake config should first be updated to detect and explicitly disable this warning.
I would first revert it *now* because the bot needs to stay green *now*.
Then either the warnings can be fixed as a pre-commit to the added feature,
or if not possible the LLVM cmake config should first be updated to detect
and explicitly disable this warning.
I think i'll attempt the following approach:
1. build all the llvm components i can with clang with the warning
2. fix all related warnings, commit after review
3. temporarily add -wno-error=cast-qual
5. revert -wno-error=cast-qual and see if anything breaks
6. either revert previous commit, and fix newly-catched issues, or all good.
/probably/ not worth worrying about changing the build system to disable/enable the flag - if there’s pretty high confidence that you’ve built all the things and fixed all the warnings, it’s OK to commit it and revert the patch if you missed. (I’ve committed and reverted patches (of significant/greater complexity) maybe 4-5 time due to deeper and deeper failures in buildbots - not ideal, to be sure, but not unheard of/impractical)
But also seems worth understanding which case the Clang warning is firing that the GCC warning is not - since the GCC warning is certainly caught and fixed by some buildbots or users, so I wouldn’t expect the LLVM codebase to be too far from clean.