thakis added a comment. In D98798#2754449 <https://reviews.llvm.org/D98798#2754449>, @jamieschmeiser wrote:
> @thakis, I have some questions about your comments. > Are you sure this is coming from a system header? The path that you gave has > third_party as a directory in the path. Yes. `third_party\depot_tools\win_toolchain\vs_files\20d5f2553f\Windows Kits\10\Include\10.0.19041.0\um\commctrl.h` is a hermetic system directory used via `/winsysrootthird_party\depot_tools\win_toolchain\vs_files\20d5f2553f`. > If the warning were being triggered by code in a system header, I would have > expected it to fire on something in the windows build bots but they appear to > be clean. I don't think LLVM uses a lot of code from the windows system headers. The compiler doesn't contain any UI :) (commctrl.h is a UI header). > I don't know if it is possible to suppress a warning based on whether the > source is in a system header, or from a macro expansion that is defined in a > system header; are you aware about whether or not this is possible? > If it is, I suspect it would already be in force as a general setting, again > making me question whether this is a system header...and if it isn't a system > header, that wouldn't help you in any case. > If I understand your second point correctly, you have a system that > previously compiled cleanly with warnings being treated as errors and you are > concerned that if you use the existing options to suppress this particular > warning, you are concerned that something could creep in. Therefore you are > proposing a different warning group that would be a subgroup of the existing > one so that if you set it, you would set both but you would still be able to > set the specific one. I don't know if this is possible or not. Either way, > I suspect that it would require using a different warning for the subtraction > case, which would also require significantly changing these changes. Am I > understanding correctly? If so, this implies that you have access to a > workaround for your problem, although it may not be the best solution. > I do not have access to a windows setup to test any of these proposed > changes; in particular, given that I suspect that the affected files are > specific to some third party vendor from which you have purchased code, I do > not have means of investigating the actual problems/solutions. If it would > be helpful, I would be happy to review any changes that you might like to > make to remedy the situation. > I will be on vacation for the next few days so please excuse my delayed > responses. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D98798/new/ https://reviews.llvm.org/D98798 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
