Enable deprecations warnings #6555
Conversation
|
PTAL |
|
What's the deal with the Windows failure here? |
No idea, investigating |
|
I'm waiting to chat with the Clang developers about this before approving. |
I presume we're still pending a good resolution here? |
I think so... I would be interested to find ways to trip the depreciation warning without requiring any special build configuration. |
| # which will cause all warnings to be ignored. This is not helpful, since | ||
| # we *want* deprecation warnings to be propagated. So we must set | ||
| # NO_SYSTEM_FROM_IMPORTED in order for it to be seen. | ||
| set_target_properties(${TARGET} PROPERTIES NO_SYSTEM_FROM_IMPORTED YES) |
There was a problem hiding this comment.
It seems that Clang has a special flag for this... https://clang.llvm.org/docs/UsersManual.html#controlling-diagnostics-in-system-headers
The other approach is to try to make the deprecation warning fire on the class that is directly instantiated by the user, so that the warning appears to originate from user code.
We currently disable deprecation warnings inside Halide. This re-enables them there, and also inside add_halide_generator().
steven-johnson
force-pushed
the
srj/warn-deprecaton
branch
from
78a5bb6 to
8dbf52f
Compare
|
Rebased and updated to main -- not sure where we stand on this. IIRC there were issues with deprecation warnings on templated methods not getting triggered, but that's moot (the warnings in question never got added and might not ever be added). Maybe this is better than nothing? |
|
PTAL |
* Enable deprecations warnings We currently disable deprecation warnings inside Halide. This re-enables them there, and also inside add_halide_generator().
We currently disable deprecation warnings inside Halide. This re-enables them there, and also inside add_halide_generator().
(Note, additive to PR #6554)