Merge pull request #17839 from lydia-duncan/suppressDepInDep
Only generate a deprecation warning if we're not already in a deprecated symbol
[reviewed by @dlongnecke-cray]
It can be annoying to get deprecated warnings in symbols that are themselves
deprecated - I suspect that in situations like this, part of the reason the
outer symbol is deprecated is because it used another deprecated symbol but had
to be kept around for users to transition. In such cases, the deprecation
warning will be addressed by removing the outer deprecated symbol, so we don't
need to warn about it.
This impacted the BigInteger module when deprecating the Round enum and the
functions that took it as an argument. Users of the BigInteger module would
get a warning for every reference to the Round enum in there, even though these
remaining references were to ease the transition to using the new version of
the deprecated functions.
Note that I don't recursively check if the parent symbol is deprecated, so it is
still possible to get deprecation warnings inside the functions of a deprecated
module, for instance. Based on past experience with traversing the AST up
from a node, I strongly suspect doing this would cause a performance impact
and thus I don't think it is worthwhile.
Add two new tests of the functionality, ensuring we don't give extra warnings.
Covers deprecated symbols within a function and within the function's arguments
Passed a full paratest with futures
Modified Files: A test/deprecated-keyword/argOfDepTypeInDepFunc.chpl