aboutsummaryrefslogtreecommitdiff
path: root/llvm/unittests/ExecutionEngine/Orc/ExecutionSessionWrapperFunctionCallsTest.cpp
diff options
context:
space:
mode:
authorPeter Klausler <pklausler@nvidia.com>2023-03-15 12:21:04 -0700
committerPeter Klausler <pklausler@nvidia.com>2023-03-27 15:43:09 -0700
commit51d48a3e6609c17299a16e8e823af6901be23c11 (patch)
tree159b653db18f7b24be7e5d69401e54a42e353e8b /llvm/unittests/ExecutionEngine/Orc/ExecutionSessionWrapperFunctionCallsTest.cpp
parent9b4e8b7b0a6b368dcce474e82bdcd55a2f27bc1e (diff)
downloadllvm-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