diff options
| author | Peter Klausler <pklausler@nvidia.com> | 2022-10-24 11:22:22 -0700 |
|---|---|---|
| committer | Peter Klausler <pklausler@nvidia.com> | 2022-10-30 13:37:47 -0700 |
| commit | f8dbe79cc673439db4b90cdcabcffc79348a2ca1 (patch) | |
| tree | 7aafa34aa6164edeb47944281248cf17ae5883ec /llvm/unittests/Support/CommandLineTest.cpp | |
| parent | c4c198f603d78ae328b517273df7ae8fb01a095c (diff) | |
| download | llvm-f8dbe79cc673439db4b90cdcabcffc79348a2ca1.zip llvm-f8dbe79cc673439db4b90cdcabcffc79348a2ca1.tar.gz llvm-f8dbe79cc673439db4b90cdcabcffc79348a2ca1.tar.bz2 | |
[flang] Don't resolve component names to components in derived-type definition scope
We implemented 19.3.4p1 literally in name resolution:
A component name has the scope of its derived-type definition. Outside the type definition,
it may also appear within a designator of a component of a structure of that type or as a
component keyword in a structure constructor for that type.
and within the derived-type definition would resolve the "bare"
names of components in specification inquiries and other contexts to
those components, not to any symbols in the enclosing scopes.
It turns out that most Fortran compilers resolve only "bare" names thus
when they are type parameters, and the names of data and procedure components
do not shadow exterior symbols. Adjust name resolution to follow that
precedent rather than what seems to be clear language in the standard.
Differential Revision: https://reviews.llvm.org/D136984
Diffstat (limited to 'llvm/unittests/Support/CommandLineTest.cpp')
0 files changed, 0 insertions, 0 deletions