diff options
author | Peter Klausler <pklausler@nvidia.com> | 2023-03-15 12:21:04 -0700 |
---|---|---|
committer | Peter Klausler <pklausler@nvidia.com> | 2023-03-27 15:43:09 -0700 |
commit | 51d48a3e6609c17299a16e8e823af6901be23c11 (patch) | |
tree | 159b653db18f7b24be7e5d69401e54a42e353e8b /llvm/unittests/ExecutionEngine/Orc/ExecutionSessionWrapperFunctionCallsTest.cpp | |
parent | 9b4e8b7b0a6b368dcce474e82bdcd55a2f27bc1e (diff) | |
download | llvm-51d48a3e6609c17299a16e8e823af6901be23c11.zip llvm-51d48a3e6609c17299a16e8e823af6901be23c11.tar.gz llvm-51d48a3e6609c17299a16e8e823af6901be23c11.tar.bz2 |
[flang] Reimplement C1406 check as a warning
Constraint C1406 in Fortran 2018 prohibits the USE of the same module
name as both an intrinsic module and a non-intrinsic module in a scope.
The current check misinterprets the constraint as applying only to
explicitly INTRINSIC or NON_INTRINSIC module natures.
Change the check to also apply to non-explicit module natures, and
also downgrade it to a portability warning, since there is no ambiguity
and I suspect that we need to accept this usage when building f18's
own intrinsic modules.
Differential Revision: https://reviews.llvm.org/D146576
Diffstat (limited to 'llvm/unittests/ExecutionEngine/Orc/ExecutionSessionWrapperFunctionCallsTest.cpp')
0 files changed, 0 insertions, 0 deletions