llvm-project/flang/lib/Semantics/resolve-names-utils.h

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

150 lines
5.4 KiB
C
Raw Normal View History

//===-- lib/Semantics/resolve-names-utils.h ---------------------*- C++ -*-===//
[flang] Name resolution for defined operators Instead of tracking just genericName_ while in a generic interface block or generic statement, now we immediately create a symbol for it. A parser::Name isn't good enough because a defined-operator or defined-io-generic-spec doesn't have a name. Change the parse tree to add a source field to GenericSpec. Use these as names for symbols for defined-operator and defined-io-generic-spec (e.g. "operator(+)" or "read(formatted)"). Change the source for defined-op-name to include the dots so that they can be distinguished from normal symbols with the same name (e.g. you can have both ".foo." and "foo"). These symbols have names in the symbol table like ".foo.", not "operator(.foo.)", because references to them have that form. Add GenericKind enum to GenericDetails and GenericBindingDetails. This allows us to know a symbol is "assignment(=)", for example, without having to do a string comparison. Add GenericSpecInfo to handle analyzing the various kinds of generic-spec and generating symbol names and GenericKind for them. Add reference to LanguageFeatureControl to SemanticsContext so that they can be checked during semantics. For this change, if LogicalAbbreviations is enabled, report an error if the user tries to define an operator named ".T." or ".F.". Add resolve-name-utils.cc to hold utility functions and classes that don't have to be in the ResolveNamesVisitor class hierarchy. The goal is to reduce the size of resolve-names.cc where possible. Original-commit: flang-compiler/f18@3081f694e21dbcaef2554198a682c9af57f2e185 Reviewed-on: https://github.com/flang-compiler/f18/pull/338
2019-03-19 02:48:02 +08:00
//
// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
// See https://llvm.org/LICENSE.txt for license information.
// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
[flang] Name resolution for defined operators Instead of tracking just genericName_ while in a generic interface block or generic statement, now we immediately create a symbol for it. A parser::Name isn't good enough because a defined-operator or defined-io-generic-spec doesn't have a name. Change the parse tree to add a source field to GenericSpec. Use these as names for symbols for defined-operator and defined-io-generic-spec (e.g. "operator(+)" or "read(formatted)"). Change the source for defined-op-name to include the dots so that they can be distinguished from normal symbols with the same name (e.g. you can have both ".foo." and "foo"). These symbols have names in the symbol table like ".foo.", not "operator(.foo.)", because references to them have that form. Add GenericKind enum to GenericDetails and GenericBindingDetails. This allows us to know a symbol is "assignment(=)", for example, without having to do a string comparison. Add GenericSpecInfo to handle analyzing the various kinds of generic-spec and generating symbol names and GenericKind for them. Add reference to LanguageFeatureControl to SemanticsContext so that they can be checked during semantics. For this change, if LogicalAbbreviations is enabled, report an error if the user tries to define an operator named ".T." or ".F.". Add resolve-name-utils.cc to hold utility functions and classes that don't have to be in the ResolveNamesVisitor class hierarchy. The goal is to reduce the size of resolve-names.cc where possible. Original-commit: flang-compiler/f18@3081f694e21dbcaef2554198a682c9af57f2e185 Reviewed-on: https://github.com/flang-compiler/f18/pull/338
2019-03-19 02:48:02 +08:00
//
//===----------------------------------------------------------------------===//
[flang] Name resolution for defined operators Instead of tracking just genericName_ while in a generic interface block or generic statement, now we immediately create a symbol for it. A parser::Name isn't good enough because a defined-operator or defined-io-generic-spec doesn't have a name. Change the parse tree to add a source field to GenericSpec. Use these as names for symbols for defined-operator and defined-io-generic-spec (e.g. "operator(+)" or "read(formatted)"). Change the source for defined-op-name to include the dots so that they can be distinguished from normal symbols with the same name (e.g. you can have both ".foo." and "foo"). These symbols have names in the symbol table like ".foo.", not "operator(.foo.)", because references to them have that form. Add GenericKind enum to GenericDetails and GenericBindingDetails. This allows us to know a symbol is "assignment(=)", for example, without having to do a string comparison. Add GenericSpecInfo to handle analyzing the various kinds of generic-spec and generating symbol names and GenericKind for them. Add reference to LanguageFeatureControl to SemanticsContext so that they can be checked during semantics. For this change, if LogicalAbbreviations is enabled, report an error if the user tries to define an operator named ".T." or ".F.". Add resolve-name-utils.cc to hold utility functions and classes that don't have to be in the ResolveNamesVisitor class hierarchy. The goal is to reduce the size of resolve-names.cc where possible. Original-commit: flang-compiler/f18@3081f694e21dbcaef2554198a682c9af57f2e185 Reviewed-on: https://github.com/flang-compiler/f18/pull/338
2019-03-19 02:48:02 +08:00
#ifndef FORTRAN_SEMANTICS_RESOLVE_NAMES_UTILS_H_
#define FORTRAN_SEMANTICS_RESOLVE_NAMES_UTILS_H_
// Utility functions and class for use in resolve-names.cpp.
[flang] Name resolution for defined operators Instead of tracking just genericName_ while in a generic interface block or generic statement, now we immediately create a symbol for it. A parser::Name isn't good enough because a defined-operator or defined-io-generic-spec doesn't have a name. Change the parse tree to add a source field to GenericSpec. Use these as names for symbols for defined-operator and defined-io-generic-spec (e.g. "operator(+)" or "read(formatted)"). Change the source for defined-op-name to include the dots so that they can be distinguished from normal symbols with the same name (e.g. you can have both ".foo." and "foo"). These symbols have names in the symbol table like ".foo.", not "operator(.foo.)", because references to them have that form. Add GenericKind enum to GenericDetails and GenericBindingDetails. This allows us to know a symbol is "assignment(=)", for example, without having to do a string comparison. Add GenericSpecInfo to handle analyzing the various kinds of generic-spec and generating symbol names and GenericKind for them. Add reference to LanguageFeatureControl to SemanticsContext so that they can be checked during semantics. For this change, if LogicalAbbreviations is enabled, report an error if the user tries to define an operator named ".T." or ".F.". Add resolve-name-utils.cc to hold utility functions and classes that don't have to be in the ResolveNamesVisitor class hierarchy. The goal is to reduce the size of resolve-names.cc where possible. Original-commit: flang-compiler/f18@3081f694e21dbcaef2554198a682c9af57f2e185 Reviewed-on: https://github.com/flang-compiler/f18/pull/338
2019-03-19 02:48:02 +08:00
#include "flang/Evaluate/fold.h"
#include "flang/Parser/message.h"
#include "flang/Parser/tools.h"
#include "flang/Semantics/expression.h"
#include "flang/Semantics/scope.h"
#include "flang/Semantics/semantics.h"
#include "flang/Semantics/symbol.h"
#include "flang/Semantics/type.h"
#include "llvm/Support/raw_ostream.h"
#include <forward_list>
namespace Fortran::parser {
class CharBlock;
struct ArraySpec;
struct CoarraySpec;
struct ComponentArraySpec;
struct DataRef;
struct DefinedOpName;
struct Designator;
struct Expr;
struct GenericSpec;
struct Name;
} // namespace Fortran::parser
[flang] Name resolution for defined operators Instead of tracking just genericName_ while in a generic interface block or generic statement, now we immediately create a symbol for it. A parser::Name isn't good enough because a defined-operator or defined-io-generic-spec doesn't have a name. Change the parse tree to add a source field to GenericSpec. Use these as names for symbols for defined-operator and defined-io-generic-spec (e.g. "operator(+)" or "read(formatted)"). Change the source for defined-op-name to include the dots so that they can be distinguished from normal symbols with the same name (e.g. you can have both ".foo." and "foo"). These symbols have names in the symbol table like ".foo.", not "operator(.foo.)", because references to them have that form. Add GenericKind enum to GenericDetails and GenericBindingDetails. This allows us to know a symbol is "assignment(=)", for example, without having to do a string comparison. Add GenericSpecInfo to handle analyzing the various kinds of generic-spec and generating symbol names and GenericKind for them. Add reference to LanguageFeatureControl to SemanticsContext so that they can be checked during semantics. For this change, if LogicalAbbreviations is enabled, report an error if the user tries to define an operator named ".T." or ".F.". Add resolve-name-utils.cc to hold utility functions and classes that don't have to be in the ResolveNamesVisitor class hierarchy. The goal is to reduce the size of resolve-names.cc where possible. Original-commit: flang-compiler/f18@3081f694e21dbcaef2554198a682c9af57f2e185 Reviewed-on: https://github.com/flang-compiler/f18/pull/338
2019-03-19 02:48:02 +08:00
namespace Fortran::semantics {
using SourceName = parser::CharBlock;
class SemanticsContext;
[flang] Name resolution for defined operators Instead of tracking just genericName_ while in a generic interface block or generic statement, now we immediately create a symbol for it. A parser::Name isn't good enough because a defined-operator or defined-io-generic-spec doesn't have a name. Change the parse tree to add a source field to GenericSpec. Use these as names for symbols for defined-operator and defined-io-generic-spec (e.g. "operator(+)" or "read(formatted)"). Change the source for defined-op-name to include the dots so that they can be distinguished from normal symbols with the same name (e.g. you can have both ".foo." and "foo"). These symbols have names in the symbol table like ".foo.", not "operator(.foo.)", because references to them have that form. Add GenericKind enum to GenericDetails and GenericBindingDetails. This allows us to know a symbol is "assignment(=)", for example, without having to do a string comparison. Add GenericSpecInfo to handle analyzing the various kinds of generic-spec and generating symbol names and GenericKind for them. Add reference to LanguageFeatureControl to SemanticsContext so that they can be checked during semantics. For this change, if LogicalAbbreviations is enabled, report an error if the user tries to define an operator named ".T." or ".F.". Add resolve-name-utils.cc to hold utility functions and classes that don't have to be in the ResolveNamesVisitor class hierarchy. The goal is to reduce the size of resolve-names.cc where possible. Original-commit: flang-compiler/f18@3081f694e21dbcaef2554198a682c9af57f2e185 Reviewed-on: https://github.com/flang-compiler/f18/pull/338
2019-03-19 02:48:02 +08:00
// Record that a Name has been resolved to a Symbol
Symbol &Resolve(const parser::Name &, Symbol &);
Symbol *Resolve(const parser::Name &, Symbol *);
// Create a copy of msg with a new isFatal value.
parser::MessageFixedText WithIsFatal(
const parser::MessageFixedText &msg, bool isFatal);
bool IsIntrinsicOperator(const SemanticsContext &, const SourceName &);
[flang] Name resolution for defined operators Instead of tracking just genericName_ while in a generic interface block or generic statement, now we immediately create a symbol for it. A parser::Name isn't good enough because a defined-operator or defined-io-generic-spec doesn't have a name. Change the parse tree to add a source field to GenericSpec. Use these as names for symbols for defined-operator and defined-io-generic-spec (e.g. "operator(+)" or "read(formatted)"). Change the source for defined-op-name to include the dots so that they can be distinguished from normal symbols with the same name (e.g. you can have both ".foo." and "foo"). These symbols have names in the symbol table like ".foo.", not "operator(.foo.)", because references to them have that form. Add GenericKind enum to GenericDetails and GenericBindingDetails. This allows us to know a symbol is "assignment(=)", for example, without having to do a string comparison. Add GenericSpecInfo to handle analyzing the various kinds of generic-spec and generating symbol names and GenericKind for them. Add reference to LanguageFeatureControl to SemanticsContext so that they can be checked during semantics. For this change, if LogicalAbbreviations is enabled, report an error if the user tries to define an operator named ".T." or ".F.". Add resolve-name-utils.cc to hold utility functions and classes that don't have to be in the ResolveNamesVisitor class hierarchy. The goal is to reduce the size of resolve-names.cc where possible. Original-commit: flang-compiler/f18@3081f694e21dbcaef2554198a682c9af57f2e185 Reviewed-on: https://github.com/flang-compiler/f18/pull/338
2019-03-19 02:48:02 +08:00
bool IsLogicalConstant(const SemanticsContext &, const SourceName &);
// Some intrinsic operators have more than one name (e.g. `operator(.eq.)` and
// `operator(==)`). GetAllNames() returns them all, including symbolName.
std::forward_list<std::string> GetAllNames(
const SemanticsContext &, const SourceName &);
template <typename T>
MaybeIntExpr EvaluateIntExpr(SemanticsContext &context, const T &expr) {
if (MaybeExpr maybeExpr{
Fold(context.foldingContext(), AnalyzeExpr(context, expr))}) {
if (auto *intExpr{evaluate::UnwrapExpr<SomeIntExpr>(*maybeExpr)}) {
return std::move(*intExpr);
}
}
return std::nullopt;
}
template <typename T>
std::optional<std::int64_t> EvaluateInt64(
SemanticsContext &context, const T &expr) {
return evaluate::ToInt64(EvaluateIntExpr(context, expr));
}
[flang] Name resolution for defined operators Instead of tracking just genericName_ while in a generic interface block or generic statement, now we immediately create a symbol for it. A parser::Name isn't good enough because a defined-operator or defined-io-generic-spec doesn't have a name. Change the parse tree to add a source field to GenericSpec. Use these as names for symbols for defined-operator and defined-io-generic-spec (e.g. "operator(+)" or "read(formatted)"). Change the source for defined-op-name to include the dots so that they can be distinguished from normal symbols with the same name (e.g. you can have both ".foo." and "foo"). These symbols have names in the symbol table like ".foo.", not "operator(.foo.)", because references to them have that form. Add GenericKind enum to GenericDetails and GenericBindingDetails. This allows us to know a symbol is "assignment(=)", for example, without having to do a string comparison. Add GenericSpecInfo to handle analyzing the various kinds of generic-spec and generating symbol names and GenericKind for them. Add reference to LanguageFeatureControl to SemanticsContext so that they can be checked during semantics. For this change, if LogicalAbbreviations is enabled, report an error if the user tries to define an operator named ".T." or ".F.". Add resolve-name-utils.cc to hold utility functions and classes that don't have to be in the ResolveNamesVisitor class hierarchy. The goal is to reduce the size of resolve-names.cc where possible. Original-commit: flang-compiler/f18@3081f694e21dbcaef2554198a682c9af57f2e185 Reviewed-on: https://github.com/flang-compiler/f18/pull/338
2019-03-19 02:48:02 +08:00
// Analyze a generic-spec and generate a symbol name and GenericKind for it.
class GenericSpecInfo {
public:
explicit GenericSpecInfo(const parser::DefinedOpName &x) { Analyze(x); }
explicit GenericSpecInfo(const parser::GenericSpec &x) { Analyze(x); }
[flang] Name resolution for defined operators Instead of tracking just genericName_ while in a generic interface block or generic statement, now we immediately create a symbol for it. A parser::Name isn't good enough because a defined-operator or defined-io-generic-spec doesn't have a name. Change the parse tree to add a source field to GenericSpec. Use these as names for symbols for defined-operator and defined-io-generic-spec (e.g. "operator(+)" or "read(formatted)"). Change the source for defined-op-name to include the dots so that they can be distinguished from normal symbols with the same name (e.g. you can have both ".foo." and "foo"). These symbols have names in the symbol table like ".foo.", not "operator(.foo.)", because references to them have that form. Add GenericKind enum to GenericDetails and GenericBindingDetails. This allows us to know a symbol is "assignment(=)", for example, without having to do a string comparison. Add GenericSpecInfo to handle analyzing the various kinds of generic-spec and generating symbol names and GenericKind for them. Add reference to LanguageFeatureControl to SemanticsContext so that they can be checked during semantics. For this change, if LogicalAbbreviations is enabled, report an error if the user tries to define an operator named ".T." or ".F.". Add resolve-name-utils.cc to hold utility functions and classes that don't have to be in the ResolveNamesVisitor class hierarchy. The goal is to reduce the size of resolve-names.cc where possible. Original-commit: flang-compiler/f18@3081f694e21dbcaef2554198a682c9af57f2e185 Reviewed-on: https://github.com/flang-compiler/f18/pull/338
2019-03-19 02:48:02 +08:00
GenericKind kind() const { return kind_; }
const SourceName &symbolName() const { return symbolName_.value(); }
[flang] Name resolution for defined operators Instead of tracking just genericName_ while in a generic interface block or generic statement, now we immediately create a symbol for it. A parser::Name isn't good enough because a defined-operator or defined-io-generic-spec doesn't have a name. Change the parse tree to add a source field to GenericSpec. Use these as names for symbols for defined-operator and defined-io-generic-spec (e.g. "operator(+)" or "read(formatted)"). Change the source for defined-op-name to include the dots so that they can be distinguished from normal symbols with the same name (e.g. you can have both ".foo." and "foo"). These symbols have names in the symbol table like ".foo.", not "operator(.foo.)", because references to them have that form. Add GenericKind enum to GenericDetails and GenericBindingDetails. This allows us to know a symbol is "assignment(=)", for example, without having to do a string comparison. Add GenericSpecInfo to handle analyzing the various kinds of generic-spec and generating symbol names and GenericKind for them. Add reference to LanguageFeatureControl to SemanticsContext so that they can be checked during semantics. For this change, if LogicalAbbreviations is enabled, report an error if the user tries to define an operator named ".T." or ".F.". Add resolve-name-utils.cc to hold utility functions and classes that don't have to be in the ResolveNamesVisitor class hierarchy. The goal is to reduce the size of resolve-names.cc where possible. Original-commit: flang-compiler/f18@3081f694e21dbcaef2554198a682c9af57f2e185 Reviewed-on: https://github.com/flang-compiler/f18/pull/338
2019-03-19 02:48:02 +08:00
// Set the GenericKind in this symbol and resolve the corresponding
// name if there is one
void Resolve(Symbol *) const;
friend llvm::raw_ostream &operator<<(
llvm::raw_ostream &, const GenericSpecInfo &);
[flang] Name resolution for defined operators Instead of tracking just genericName_ while in a generic interface block or generic statement, now we immediately create a symbol for it. A parser::Name isn't good enough because a defined-operator or defined-io-generic-spec doesn't have a name. Change the parse tree to add a source field to GenericSpec. Use these as names for symbols for defined-operator and defined-io-generic-spec (e.g. "operator(+)" or "read(formatted)"). Change the source for defined-op-name to include the dots so that they can be distinguished from normal symbols with the same name (e.g. you can have both ".foo." and "foo"). These symbols have names in the symbol table like ".foo.", not "operator(.foo.)", because references to them have that form. Add GenericKind enum to GenericDetails and GenericBindingDetails. This allows us to know a symbol is "assignment(=)", for example, without having to do a string comparison. Add GenericSpecInfo to handle analyzing the various kinds of generic-spec and generating symbol names and GenericKind for them. Add reference to LanguageFeatureControl to SemanticsContext so that they can be checked during semantics. For this change, if LogicalAbbreviations is enabled, report an error if the user tries to define an operator named ".T." or ".F.". Add resolve-name-utils.cc to hold utility functions and classes that don't have to be in the ResolveNamesVisitor class hierarchy. The goal is to reduce the size of resolve-names.cc where possible. Original-commit: flang-compiler/f18@3081f694e21dbcaef2554198a682c9af57f2e185 Reviewed-on: https://github.com/flang-compiler/f18/pull/338
2019-03-19 02:48:02 +08:00
private:
void Analyze(const parser::DefinedOpName &);
void Analyze(const parser::GenericSpec &);
[flang] Name resolution for defined operators Instead of tracking just genericName_ while in a generic interface block or generic statement, now we immediately create a symbol for it. A parser::Name isn't good enough because a defined-operator or defined-io-generic-spec doesn't have a name. Change the parse tree to add a source field to GenericSpec. Use these as names for symbols for defined-operator and defined-io-generic-spec (e.g. "operator(+)" or "read(formatted)"). Change the source for defined-op-name to include the dots so that they can be distinguished from normal symbols with the same name (e.g. you can have both ".foo." and "foo"). These symbols have names in the symbol table like ".foo.", not "operator(.foo.)", because references to them have that form. Add GenericKind enum to GenericDetails and GenericBindingDetails. This allows us to know a symbol is "assignment(=)", for example, without having to do a string comparison. Add GenericSpecInfo to handle analyzing the various kinds of generic-spec and generating symbol names and GenericKind for them. Add reference to LanguageFeatureControl to SemanticsContext so that they can be checked during semantics. For this change, if LogicalAbbreviations is enabled, report an error if the user tries to define an operator named ".T." or ".F.". Add resolve-name-utils.cc to hold utility functions and classes that don't have to be in the ResolveNamesVisitor class hierarchy. The goal is to reduce the size of resolve-names.cc where possible. Original-commit: flang-compiler/f18@3081f694e21dbcaef2554198a682c9af57f2e185 Reviewed-on: https://github.com/flang-compiler/f18/pull/338
2019-03-19 02:48:02 +08:00
GenericKind kind_;
const parser::Name *parseName_{nullptr};
std::optional<SourceName> symbolName_;
[flang] Name resolution for defined operators Instead of tracking just genericName_ while in a generic interface block or generic statement, now we immediately create a symbol for it. A parser::Name isn't good enough because a defined-operator or defined-io-generic-spec doesn't have a name. Change the parse tree to add a source field to GenericSpec. Use these as names for symbols for defined-operator and defined-io-generic-spec (e.g. "operator(+)" or "read(formatted)"). Change the source for defined-op-name to include the dots so that they can be distinguished from normal symbols with the same name (e.g. you can have both ".foo." and "foo"). These symbols have names in the symbol table like ".foo.", not "operator(.foo.)", because references to them have that form. Add GenericKind enum to GenericDetails and GenericBindingDetails. This allows us to know a symbol is "assignment(=)", for example, without having to do a string comparison. Add GenericSpecInfo to handle analyzing the various kinds of generic-spec and generating symbol names and GenericKind for them. Add reference to LanguageFeatureControl to SemanticsContext so that they can be checked during semantics. For this change, if LogicalAbbreviations is enabled, report an error if the user tries to define an operator named ".T." or ".F.". Add resolve-name-utils.cc to hold utility functions and classes that don't have to be in the ResolveNamesVisitor class hierarchy. The goal is to reduce the size of resolve-names.cc where possible. Original-commit: flang-compiler/f18@3081f694e21dbcaef2554198a682c9af57f2e185 Reviewed-on: https://github.com/flang-compiler/f18/pull/338
2019-03-19 02:48:02 +08:00
};
// Analyze a parser::ArraySpec or parser::CoarraySpec
ArraySpec AnalyzeArraySpec(SemanticsContext &, const parser::ArraySpec &);
ArraySpec AnalyzeArraySpec(
SemanticsContext &, const parser::ComponentArraySpec &);
ArraySpec AnalyzeDeferredShapeSpecList(
SemanticsContext &, const parser::DeferredShapeSpecList &);
ArraySpec AnalyzeCoarraySpec(
SemanticsContext &context, const parser::CoarraySpec &);
// Perform consistency checks on equivalence sets
class EquivalenceSets {
public:
EquivalenceSets(SemanticsContext &context) : context_{context} {}
std::vector<EquivalenceSet> &sets() { return sets_; };
// Resolve this designator and add to the current equivalence set
void AddToSet(const parser::Designator &);
// Finish the current equivalence set: determine if it overlaps
// with any of the others and perform necessary merges if it does.
void FinishSet(const parser::CharBlock &);
private:
bool CheckCanEquivalence(
const parser::CharBlock &, const Symbol &, const Symbol &);
void MergeInto(const parser::CharBlock &, EquivalenceSet &, std::size_t);
const EquivalenceObject *Find(const EquivalenceSet &, const Symbol &);
bool CheckDesignator(const parser::Designator &);
bool CheckDataRef(const parser::CharBlock &, const parser::DataRef &);
bool CheckObject(const parser::Name &);
bool CheckArrayBound(const parser::Expr &);
bool CheckSubstringBound(const parser::Expr &, bool);
bool IsCharacterSequenceType(const DeclTypeSpec *);
bool IsDefaultKindNumericType(const IntrinsicTypeSpec &);
bool IsDefaultNumericSequenceType(const DeclTypeSpec *);
static bool IsAnyNumericSequenceType(const DeclTypeSpec *);
static bool IsSequenceType(
const DeclTypeSpec *, std::function<bool(const IntrinsicTypeSpec &)>);
SemanticsContext &context_;
std::vector<EquivalenceSet> sets_; // all equivalence sets in this scope
// Map object to index of set it is in
std::map<EquivalenceObject, std::size_t> objectToSet_;
EquivalenceSet currSet_; // equivalence set currently being constructed
struct {
Symbol *symbol{nullptr};
std::vector<ConstantSubscript> subscripts;
std::optional<ConstantSubscript> substringStart;
} currObject_; // equivalence object currently being constructed
};
} // namespace Fortran::semantics
#endif // FORTRAN_SEMANTICS_RESOLVE_NAMES_H_