cjappl wrote: > My sense is that it would be weird for -Wall not to include > -Wfunction-effects, but that it would be OK for -Wfunction-effects not to be > enabled by default.
I do agree, it seems reasonable for it to be in `-Wall` or similar! That is absolutely what I'd expect as a user :) > I do wonder, though, would it be that difficult to tell users to include > `-Wno-function-effects` with `-fsanitize=realtime` (or whatever it is)? Yes, that is what we have been going with, telling users to disable this warning if they want the sanitizer without function effects. Our main concern is if users "missed" this advice of disabling function effects, they would think RTSan couldn't be run without fixing these compile-time warnings/errors, and people would be dissuaded from using the sanitizer. Our current thinking is it might (??) be clearer for both features to be opt-in via flag (-fsanitize=realtime needed to opt in to using RealtimeSanitizer, and -Wfunction-effects needed to opt in to using function effects) instead of one being opt-in and one being opt-out and being keyed off the same attribute. I think the same question could also be asked in reversed -- would it be that difficult to tell users to enable -Wfunction-effects if they wanted the warnings? I think this gets to the root of our opt-in/opt-out differences. Where does the responsibility lie enabling these things? How are these features run separately, or together with minimal friction? https://github.com/llvm/llvm-project/pull/99656 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
