llvm/flang/lib/semantics/symbol.cc

502 lines
15 KiB
C++
Raw Normal View History

// Copyright (c) 2018, NVIDIA CORPORATION. All rights reserved.
//
// Licensed under the Apache License, Version 2.0 (the "License");
// you may not use this file except in compliance with the License.
// You may obtain a copy of the License at
//
// http://www.apache.org/licenses/LICENSE-2.0
//
// Unless required by applicable law or agreed to in writing, software
// distributed under the License is distributed on an "AS IS" BASIS,
// WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
// See the License for the specific language governing permissions and
// limitations under the License.
[flang] Partial implementation of Symbols and Scopes. A Symbol consists of a common part (in class Symbol) containing name, owner, attributes. Information for a specific kind of symbol is in a variant containing one of the *Details classes. So the kind of symbol is determined by the type of details class stored in the details_ variant. For scopes there is a single Scope class with an enum indicating the kind. So far there isn't a need for extra kind-specific details as with Symbols but that could change. Symbols defined in a Scope are stored there in a simple map. resolve-names.cc is a partial implementation of a parse-tree walker that resolves names to Symbols. Currently is only handles functions (which introduce a new Scope) and entity-decls. The test-type executable was reused as a driver for this to avoid the need for a new one. Sample output is below. When each "end function" is encountered the scope is dumped, which shows the symbols defined in it. $ cat a.f90 pure integer(8) function foo(arg1, arg2) result(res) integer :: arg1 real :: arg2 contains function bar(arg1) real :: bar real :: arg1 end function end function $ Debug/tools/f18/test-type a.f90 Subprogram scope: 0 children arg1: Entity type: REAL bar: Entity type: REAL Subprogram scope: 1 children arg1: Entity type: INTEGER arg2: Entity type: REAL bar: Subprogram (arg1) foo: Subprogram (arg1, arg2) result(res) res: Entity type: INTEGER(8) Original-commit: flang-compiler/f18@1cd2fbc04da1d6bb2ef5bc1cf07c808460ea7547 Reviewed-on: https://github.com/flang-compiler/f18/pull/30 Tree-same-pre-rewrite: false
2018-03-23 01:08:20 +01:00
#include "symbol.h"
#include "scope.h"
#include "../common/idioms.h"
[flang] Change when symbol is set in parser::Name Rework how `parser::Name` is resolved to contain a `Symbol`. so that constants in types can be evaluated. For example: ``` integer, parameter :: k = 8 integer(k) :: i ``` The old approach of collecting the symbols at the end of name resolution and filling in the `parser::Name` does not work because the type of `i` needs to be set in the symbol table. The symbol field in `parser::Name` is now mutable so that we can set it during name resolution. `RewriteParseTree` no longer needs to do that (it still warns about unresolved ones), so it does not need to collect symbols and fill them in. Consequently, we can eliminate "occurrences" from symbols -- we just need the name where each is first defined. This requires a lot of refactoring in `resolve-names.cc` to pass around `parser::Name` rather than `SourceName` so that we can resolve the name to a symbol. Fix some bugs where we stored `SourceName *` instead of `SourceName` in the symbol table. The pointers were into the parse tree, so they were only valid as long as the parse tree was around. The symbol table needs to remain valid longer than that, so the names need to be copied. `parser::Name` is not used in the symbol table. Eliminate `GenericSpec`. Currently all we need to do is to resolve the kinds of GenericSpec that contain names. Add `ScopeName` kind of `MiscDetails` for when we need a symbol in the scope to match the name of the scope. For example, `module m` cannot contain a declaration of a new `m`. Subprograms need real details because they can be called recursively. Fix output of partially resolved modules where we know it is a submodule but have not yet resolved the ancestor. Original-commit: flang-compiler/f18@5c1a4b99d2421f5b32e83426488d3fdf7951cfba Reviewed-on: https://github.com/flang-compiler/f18/pull/238 Tree-same-pre-rewrite: false
2018-11-16 21:43:08 +01:00
#include <ostream>
#include <string>
[flang] Partial implementation of Symbols and Scopes. A Symbol consists of a common part (in class Symbol) containing name, owner, attributes. Information for a specific kind of symbol is in a variant containing one of the *Details classes. So the kind of symbol is determined by the type of details class stored in the details_ variant. For scopes there is a single Scope class with an enum indicating the kind. So far there isn't a need for extra kind-specific details as with Symbols but that could change. Symbols defined in a Scope are stored there in a simple map. resolve-names.cc is a partial implementation of a parse-tree walker that resolves names to Symbols. Currently is only handles functions (which introduce a new Scope) and entity-decls. The test-type executable was reused as a driver for this to avoid the need for a new one. Sample output is below. When each "end function" is encountered the scope is dumped, which shows the symbols defined in it. $ cat a.f90 pure integer(8) function foo(arg1, arg2) result(res) integer :: arg1 real :: arg2 contains function bar(arg1) real :: bar real :: arg1 end function end function $ Debug/tools/f18/test-type a.f90 Subprogram scope: 0 children arg1: Entity type: REAL bar: Entity type: REAL Subprogram scope: 1 children arg1: Entity type: INTEGER arg2: Entity type: REAL bar: Subprogram (arg1) foo: Subprogram (arg1, arg2) result(res) res: Entity type: INTEGER(8) Original-commit: flang-compiler/f18@1cd2fbc04da1d6bb2ef5bc1cf07c808460ea7547 Reviewed-on: https://github.com/flang-compiler/f18/pull/30 Tree-same-pre-rewrite: false
2018-03-23 01:08:20 +01:00
namespace Fortran::semantics {
[flang] Partial implementation of Symbols and Scopes. A Symbol consists of a common part (in class Symbol) containing name, owner, attributes. Information for a specific kind of symbol is in a variant containing one of the *Details classes. So the kind of symbol is determined by the type of details class stored in the details_ variant. For scopes there is a single Scope class with an enum indicating the kind. So far there isn't a need for extra kind-specific details as with Symbols but that could change. Symbols defined in a Scope are stored there in a simple map. resolve-names.cc is a partial implementation of a parse-tree walker that resolves names to Symbols. Currently is only handles functions (which introduce a new Scope) and entity-decls. The test-type executable was reused as a driver for this to avoid the need for a new one. Sample output is below. When each "end function" is encountered the scope is dumped, which shows the symbols defined in it. $ cat a.f90 pure integer(8) function foo(arg1, arg2) result(res) integer :: arg1 real :: arg2 contains function bar(arg1) real :: bar real :: arg1 end function end function $ Debug/tools/f18/test-type a.f90 Subprogram scope: 0 children arg1: Entity type: REAL bar: Entity type: REAL Subprogram scope: 1 children arg1: Entity type: INTEGER arg2: Entity type: REAL bar: Subprogram (arg1) foo: Subprogram (arg1, arg2) result(res) res: Entity type: INTEGER(8) Original-commit: flang-compiler/f18@1cd2fbc04da1d6bb2ef5bc1cf07c808460ea7547 Reviewed-on: https://github.com/flang-compiler/f18/pull/30 Tree-same-pre-rewrite: false
2018-03-23 01:08:20 +01:00
std::ostream &operator<<(std::ostream &os, const parser::CharBlock &name) {
return os << name.ToString();
}
const Scope *ModuleDetails::parent() const {
[flang] Change when symbol is set in parser::Name Rework how `parser::Name` is resolved to contain a `Symbol`. so that constants in types can be evaluated. For example: ``` integer, parameter :: k = 8 integer(k) :: i ``` The old approach of collecting the symbols at the end of name resolution and filling in the `parser::Name` does not work because the type of `i` needs to be set in the symbol table. The symbol field in `parser::Name` is now mutable so that we can set it during name resolution. `RewriteParseTree` no longer needs to do that (it still warns about unresolved ones), so it does not need to collect symbols and fill them in. Consequently, we can eliminate "occurrences" from symbols -- we just need the name where each is first defined. This requires a lot of refactoring in `resolve-names.cc` to pass around `parser::Name` rather than `SourceName` so that we can resolve the name to a symbol. Fix some bugs where we stored `SourceName *` instead of `SourceName` in the symbol table. The pointers were into the parse tree, so they were only valid as long as the parse tree was around. The symbol table needs to remain valid longer than that, so the names need to be copied. `parser::Name` is not used in the symbol table. Eliminate `GenericSpec`. Currently all we need to do is to resolve the kinds of GenericSpec that contain names. Add `ScopeName` kind of `MiscDetails` for when we need a symbol in the scope to match the name of the scope. For example, `module m` cannot contain a declaration of a new `m`. Subprograms need real details because they can be called recursively. Fix output of partially resolved modules where we know it is a submodule but have not yet resolved the ancestor. Original-commit: flang-compiler/f18@5c1a4b99d2421f5b32e83426488d3fdf7951cfba Reviewed-on: https://github.com/flang-compiler/f18/pull/238 Tree-same-pre-rewrite: false
2018-11-16 21:43:08 +01:00
return isSubmodule_ && scope_ ? &scope_->parent() : nullptr;
}
const Scope *ModuleDetails::ancestor() const {
[flang] Change when symbol is set in parser::Name Rework how `parser::Name` is resolved to contain a `Symbol`. so that constants in types can be evaluated. For example: ``` integer, parameter :: k = 8 integer(k) :: i ``` The old approach of collecting the symbols at the end of name resolution and filling in the `parser::Name` does not work because the type of `i` needs to be set in the symbol table. The symbol field in `parser::Name` is now mutable so that we can set it during name resolution. `RewriteParseTree` no longer needs to do that (it still warns about unresolved ones), so it does not need to collect symbols and fill them in. Consequently, we can eliminate "occurrences" from symbols -- we just need the name where each is first defined. This requires a lot of refactoring in `resolve-names.cc` to pass around `parser::Name` rather than `SourceName` so that we can resolve the name to a symbol. Fix some bugs where we stored `SourceName *` instead of `SourceName` in the symbol table. The pointers were into the parse tree, so they were only valid as long as the parse tree was around. The symbol table needs to remain valid longer than that, so the names need to be copied. `parser::Name` is not used in the symbol table. Eliminate `GenericSpec`. Currently all we need to do is to resolve the kinds of GenericSpec that contain names. Add `ScopeName` kind of `MiscDetails` for when we need a symbol in the scope to match the name of the scope. For example, `module m` cannot contain a declaration of a new `m`. Subprograms need real details because they can be called recursively. Fix output of partially resolved modules where we know it is a submodule but have not yet resolved the ancestor. Original-commit: flang-compiler/f18@5c1a4b99d2421f5b32e83426488d3fdf7951cfba Reviewed-on: https://github.com/flang-compiler/f18/pull/238 Tree-same-pre-rewrite: false
2018-11-16 21:43:08 +01:00
if (!isSubmodule_ || !scope_) {
return nullptr;
}
for (auto *scope{scope_};;) {
auto *parent{&scope->parent()};
if (parent->kind() != Scope::Kind::Module) {
return scope;
}
scope = parent;
}
}
void ModuleDetails::set_scope(const Scope *scope) {
CHECK(!scope_);
bool scopeIsSubmodule{scope->parent().kind() == Scope::Kind::Module};
CHECK(isSubmodule_ == scopeIsSubmodule);
scope_ = scope;
}
void EntityDetails::set_type(const DeclTypeSpec &type) {
CHECK(!type_);
type_ = &type;
}
void ObjectEntityDetails::set_type(const DeclTypeSpec &type) {
CHECK(!type_);
type_ = &type;
}
void ObjectEntityDetails::set_shape(const ArraySpec &shape) {
CHECK(shape_.empty());
for (const auto &shapeSpec : shape) {
shape_.emplace_back(shapeSpec.Clone());
}
}
ProcEntityDetails::ProcEntityDetails(const EntityDetails &d) {
if (auto type{d.type()}) {
interface_.set_type(*type);
}
}
const Symbol &UseDetails::module() const {
// owner is a module so it must have a symbol:
return *symbol_->owner().symbol();
}
UseErrorDetails::UseErrorDetails(const UseDetails &useDetails) {
add_occurrence(useDetails.location(), *useDetails.module().scope());
}
UseErrorDetails &UseErrorDetails::add_occurrence(
const SourceName &location, const Scope &module) {
[flang] Change when symbol is set in parser::Name Rework how `parser::Name` is resolved to contain a `Symbol`. so that constants in types can be evaluated. For example: ``` integer, parameter :: k = 8 integer(k) :: i ``` The old approach of collecting the symbols at the end of name resolution and filling in the `parser::Name` does not work because the type of `i` needs to be set in the symbol table. The symbol field in `parser::Name` is now mutable so that we can set it during name resolution. `RewriteParseTree` no longer needs to do that (it still warns about unresolved ones), so it does not need to collect symbols and fill them in. Consequently, we can eliminate "occurrences" from symbols -- we just need the name where each is first defined. This requires a lot of refactoring in `resolve-names.cc` to pass around `parser::Name` rather than `SourceName` so that we can resolve the name to a symbol. Fix some bugs where we stored `SourceName *` instead of `SourceName` in the symbol table. The pointers were into the parse tree, so they were only valid as long as the parse tree was around. The symbol table needs to remain valid longer than that, so the names need to be copied. `parser::Name` is not used in the symbol table. Eliminate `GenericSpec`. Currently all we need to do is to resolve the kinds of GenericSpec that contain names. Add `ScopeName` kind of `MiscDetails` for when we need a symbol in the scope to match the name of the scope. For example, `module m` cannot contain a declaration of a new `m`. Subprograms need real details because they can be called recursively. Fix output of partially resolved modules where we know it is a submodule but have not yet resolved the ancestor. Original-commit: flang-compiler/f18@5c1a4b99d2421f5b32e83426488d3fdf7951cfba Reviewed-on: https://github.com/flang-compiler/f18/pull/238 Tree-same-pre-rewrite: false
2018-11-16 21:43:08 +01:00
occurrences_.push_back(std::make_pair(location, &module));
return *this;
}
GenericDetails::GenericDetails(const SymbolList &specificProcs) {
for (const auto *proc : specificProcs) {
add_specificProc(*proc);
}
}
[flang] Name resolution for derived types. This consists of: - a new kind of symbols to represent them with DerivedTypeDetails - creating symbols for derived types when they are declared - creating a new kind of scope for the type to hold component symbols - resolving entity declarations of objects of derived type - resolving references to objects of derived type and to components - handling derived types with same name as generic Type parameters are not yet implemented. Refactor DeclTypeSpec to be a value class wrapping an IntrinsicTypeSpec or a DerivedTypeSpec (or neither in the TypeStar and ClassStar cases). Store DerivedTypeSpec objects in a new structure the current scope MakeDerivedTypeSpec so that DeclTypeSpec can just contain a pointer to them, as it currently does for intrinsic types. In GenericDetails, add derivedType field to handle case where generic and derived type have the same name. The generic is in the scope and the derived type is referenced from the generic, similar to the case where a generic and specific have the same name. When one of these names is mis-recognized, we sometimes have to fix up the 'occurrences' lists of the symbols. Assign implicit types as soon as an entity is encountered that requires one. Otherwise implicit derived types won't work. When we see 'x%y' we have to know the type of x in order to resolve y. Add an Implicit flag to mark symbols that were implicitly typed For symbols that introduce a new scope, include a pointer back to that scope. Add CurrNonTypeScope() for the times when we want the current scope but ignoring derived type scopes. For example, that happens when looking for types or parameters, or creating implicit symbols. Original-commit: flang-compiler/f18@9bd16da020b64b78ed3928e0244765cd2e2d8068 Reviewed-on: https://github.com/flang-compiler/f18/pull/109
2018-06-22 17:21:19 +02:00
void GenericDetails::set_specific(Symbol &specific) {
CHECK(!specific_);
[flang] Name resolution for derived types. This consists of: - a new kind of symbols to represent them with DerivedTypeDetails - creating symbols for derived types when they are declared - creating a new kind of scope for the type to hold component symbols - resolving entity declarations of objects of derived type - resolving references to objects of derived type and to components - handling derived types with same name as generic Type parameters are not yet implemented. Refactor DeclTypeSpec to be a value class wrapping an IntrinsicTypeSpec or a DerivedTypeSpec (or neither in the TypeStar and ClassStar cases). Store DerivedTypeSpec objects in a new structure the current scope MakeDerivedTypeSpec so that DeclTypeSpec can just contain a pointer to them, as it currently does for intrinsic types. In GenericDetails, add derivedType field to handle case where generic and derived type have the same name. The generic is in the scope and the derived type is referenced from the generic, similar to the case where a generic and specific have the same name. When one of these names is mis-recognized, we sometimes have to fix up the 'occurrences' lists of the symbols. Assign implicit types as soon as an entity is encountered that requires one. Otherwise implicit derived types won't work. When we see 'x%y' we have to know the type of x in order to resolve y. Add an Implicit flag to mark symbols that were implicitly typed For symbols that introduce a new scope, include a pointer back to that scope. Add CurrNonTypeScope() for the times when we want the current scope but ignoring derived type scopes. For example, that happens when looking for types or parameters, or creating implicit symbols. Original-commit: flang-compiler/f18@9bd16da020b64b78ed3928e0244765cd2e2d8068 Reviewed-on: https://github.com/flang-compiler/f18/pull/109
2018-06-22 17:21:19 +02:00
specific_ = &specific;
}
void GenericDetails::set_derivedType(Symbol &derivedType) {
CHECK(!derivedType_);
derivedType_ = &derivedType;
}
const Symbol *GenericDetails::CheckSpecific() const {
[flang] Change how memory for Symbol instances is managed. With this change, all instances Symbol are stored in class Symbols. Scope.symbols_, which used to own the symbol memory, now maps names to Symbol* instead. This causes a bunch of reference-to-pointer changes because of the change in type of key-value pairs. It also requires a default constructor for Symbol, which means owner_ can't be a reference. Symbols manages Symbol instances by allocating a block of them at a time and returning the next one when needed. They are never freed. The reason for the change is that there are a few cases where we need to have a two symbols with the same name, so they can't both live in the map in Scope. Those are: 1. When there is an erroneous redeclaration of a name we may delete the first symbol and replace it with a new one. If we have saved a pointer to the first one it is now dangling. This can be seen by running `f18 -fdebug-dump-symbols -fparse-only test/semantics/resolve19.f90` under valgrind. Subroutine s is declared twice: each results in a scope that contains a pointer back to the symbol for the subroutine. After the second symbol for s is created the first is gone so the pointer in the scope is invalid. 2. A generic and one of its specifics can have the same name. We currently handle that by moving the symbol for the specific into a unique_ptr in the generic. So in that case the symbol is owned by another symbol instead of by the scope. It is simpler if we only have to deal with moving the raw pointer around. 3. A generic and a derived type can have the same name. This case isn't handled yet, but it can be done like flang-compiler/f18#2 above. It's more complicated because the derived type and the generic can be declared in either order. Original-commit: flang-compiler/f18@55a68cf0235c8a3ac855de7dc0e2b08690866be0 Reviewed-on: https://github.com/flang-compiler/f18/pull/107
2018-06-20 01:06:41 +02:00
if (specific_) {
for (const auto *proc : specificProcs_) {
[flang] Change how memory for Symbol instances is managed. With this change, all instances Symbol are stored in class Symbols. Scope.symbols_, which used to own the symbol memory, now maps names to Symbol* instead. This causes a bunch of reference-to-pointer changes because of the change in type of key-value pairs. It also requires a default constructor for Symbol, which means owner_ can't be a reference. Symbols manages Symbol instances by allocating a block of them at a time and returning the next one when needed. They are never freed. The reason for the change is that there are a few cases where we need to have a two symbols with the same name, so they can't both live in the map in Scope. Those are: 1. When there is an erroneous redeclaration of a name we may delete the first symbol and replace it with a new one. If we have saved a pointer to the first one it is now dangling. This can be seen by running `f18 -fdebug-dump-symbols -fparse-only test/semantics/resolve19.f90` under valgrind. Subroutine s is declared twice: each results in a scope that contains a pointer back to the symbol for the subroutine. After the second symbol for s is created the first is gone so the pointer in the scope is invalid. 2. A generic and one of its specifics can have the same name. We currently handle that by moving the symbol for the specific into a unique_ptr in the generic. So in that case the symbol is owned by another symbol instead of by the scope. It is simpler if we only have to deal with moving the raw pointer around. 3. A generic and a derived type can have the same name. This case isn't handled yet, but it can be done like flang-compiler/f18#2 above. It's more complicated because the derived type and the generic can be declared in either order. Original-commit: flang-compiler/f18@55a68cf0235c8a3ac855de7dc0e2b08690866be0 Reviewed-on: https://github.com/flang-compiler/f18/pull/107
2018-06-20 01:06:41 +02:00
if (proc == specific_) {
return nullptr;
}
}
[flang] Change how memory for Symbol instances is managed. With this change, all instances Symbol are stored in class Symbols. Scope.symbols_, which used to own the symbol memory, now maps names to Symbol* instead. This causes a bunch of reference-to-pointer changes because of the change in type of key-value pairs. It also requires a default constructor for Symbol, which means owner_ can't be a reference. Symbols manages Symbol instances by allocating a block of them at a time and returning the next one when needed. They are never freed. The reason for the change is that there are a few cases where we need to have a two symbols with the same name, so they can't both live in the map in Scope. Those are: 1. When there is an erroneous redeclaration of a name we may delete the first symbol and replace it with a new one. If we have saved a pointer to the first one it is now dangling. This can be seen by running `f18 -fdebug-dump-symbols -fparse-only test/semantics/resolve19.f90` under valgrind. Subroutine s is declared twice: each results in a scope that contains a pointer back to the symbol for the subroutine. After the second symbol for s is created the first is gone so the pointer in the scope is invalid. 2. A generic and one of its specifics can have the same name. We currently handle that by moving the symbol for the specific into a unique_ptr in the generic. So in that case the symbol is owned by another symbol instead of by the scope. It is simpler if we only have to deal with moving the raw pointer around. 3. A generic and a derived type can have the same name. This case isn't handled yet, but it can be done like flang-compiler/f18#2 above. It's more complicated because the derived type and the generic can be declared in either order. Original-commit: flang-compiler/f18@55a68cf0235c8a3ac855de7dc0e2b08690866be0 Reviewed-on: https://github.com/flang-compiler/f18/pull/107
2018-06-20 01:06:41 +02:00
return specific_;
} else {
return nullptr;
}
}
// The name of the kind of details for this symbol.
// This is primarily for debugging.
[flang] Support writing interfaces in module files. Write symbols for external subprogram interfaces as interface-stmts. Those go in the decls part of the module file, as opposed to contained subprograms which go in the contains part. See modfile06.f90. Write symbols with GenericDetails to module files. The specific procedures of a generic interface are always written as procedure-stmts. If they also have specific interfaces those are written in a separate interface-stmt. See modfile07.f90. Fix a bug where `real, external :: f` was not written like `real f; external f`. We have to notice the EXTERNAL attribute on the type-declaration-stmt and convert the entity to a procedure entity. See modfile08.f90. Fix a bug where a use-associated symbol is referenced in a procedure-designator. We were not resolving that correctly. Change ModFileWriter::PutEntity to include the kind of Details when it reports an internal error due to a kind it can't handle. Make DetailsToString public to support that. Change test_errors.sh to fail if the f18 command exits due to a signal. We were missing bugs where the correct errors were written out but then module file writing crashed (due to failure to handle generics mentioned above). Non-zero exit status is okay because we are expecting compilation errors. Change test_modfile.sh to allow for the expected module file contents to be indented so the tests are easier to read. Original-commit: flang-compiler/f18@82a7931e51c63ba21f17261727e1e9dc4167dcc9 Reviewed-on: https://github.com/flang-compiler/f18/pull/132 Tree-same-pre-rewrite: false
2018-07-19 22:28:24 +02:00
std::string DetailsToString(const Details &details) {
return std::visit(
common::visitors{
[](const UnknownDetails &) { return "Unknown"; },
[](const MainProgramDetails &) { return "MainProgram"; },
[](const ModuleDetails &) { return "Module"; },
[](const SubprogramDetails &) { return "Subprogram"; },
[](const SubprogramNameDetails &) { return "SubprogramName"; },
[](const EntityDetails &) { return "Entity"; },
[](const ObjectEntityDetails &) { return "ObjectEntity"; },
[](const ProcEntityDetails &) { return "ProcEntity"; },
[flang] Name resolution for derived types. This consists of: - a new kind of symbols to represent them with DerivedTypeDetails - creating symbols for derived types when they are declared - creating a new kind of scope for the type to hold component symbols - resolving entity declarations of objects of derived type - resolving references to objects of derived type and to components - handling derived types with same name as generic Type parameters are not yet implemented. Refactor DeclTypeSpec to be a value class wrapping an IntrinsicTypeSpec or a DerivedTypeSpec (or neither in the TypeStar and ClassStar cases). Store DerivedTypeSpec objects in a new structure the current scope MakeDerivedTypeSpec so that DeclTypeSpec can just contain a pointer to them, as it currently does for intrinsic types. In GenericDetails, add derivedType field to handle case where generic and derived type have the same name. The generic is in the scope and the derived type is referenced from the generic, similar to the case where a generic and specific have the same name. When one of these names is mis-recognized, we sometimes have to fix up the 'occurrences' lists of the symbols. Assign implicit types as soon as an entity is encountered that requires one. Otherwise implicit derived types won't work. When we see 'x%y' we have to know the type of x in order to resolve y. Add an Implicit flag to mark symbols that were implicitly typed For symbols that introduce a new scope, include a pointer back to that scope. Add CurrNonTypeScope() for the times when we want the current scope but ignoring derived type scopes. For example, that happens when looking for types or parameters, or creating implicit symbols. Original-commit: flang-compiler/f18@9bd16da020b64b78ed3928e0244765cd2e2d8068 Reviewed-on: https://github.com/flang-compiler/f18/pull/109
2018-06-22 17:21:19 +02:00
[](const DerivedTypeDetails &) { return "DerivedType"; },
[](const UseDetails &) { return "Use"; },
[](const UseErrorDetails &) { return "UseError"; },
[flang] More name resolution for construct entities Push a new scope for constructs and statements that require one (DataStmt, DO CONCURRENT, ForallConstruct, ForallStmt -- there are more to do). Currently we use the Block kind of scope because there is no difference. Perhaps that kind should be renamed to Construct, though it does apply to statements as well as constructs. Add DeclareConstructEntity to create a construct or statement entity. When the type is not specified it can come from the type of a symbol in the enclosing scope with the same name. Change DeclareObjectEntity et al. to return the symbol declared, for the benefit of DeclareConstructEntity. Use DeclareConstructEntity for DO CONCURRENT index-name, LOCAL, and LOCAL_INIT variables and the data-i-do-variable in DataImpliedDo Names in SHARED locality spec need special handling: create a new kinds of symbol with HostAssocDetails to represent the host-association of the shared variables within the construct scope. That symbol gets the LocalityShared flag without affecting the symbol in the outer scope. HostAssoc symbols may be useful in other contexts, e.g. up-level references to local variables. Add parser::DoConstruct::IsDoConcurrent() because DO CONCURRENT loops introduce a construct scope while other DO loops do not. Move CanonicalizeDo to before name resolution so that name resolution doesn't have to deal with labeled DO CONCURRENT loops. Allow for type of index name to be specified in ConcurrentHeader. Resolve the derived type name in an AllocateStmt, StructureConstructor Original-commit: flang-compiler/f18@bc7b9891367f3174c9b5018ce5636a36a5a76c1c Reviewed-on: https://github.com/flang-compiler/f18/pull/214
2018-10-18 16:55:48 +02:00
[](const HostAssocDetails &) { return "HostAssoc"; },
[](const GenericDetails &) { return "Generic"; },
[](const ProcBindingDetails &) { return "ProcBinding"; },
[](const GenericBindingDetails &) { return "GenericBinding"; },
[](const FinalProcDetails &) { return "FinalProc"; },
[](const TypeParamDetails &) { return "TypeParam"; },
[](const MiscDetails &) { return "Misc"; },
[](const auto &) { return "unknown"; },
},
details);
}
const std::string Symbol::GetDetailsName() const {
return DetailsToString(details_);
}
void Symbol::set_details(Details &&details) {
CHECK(CanReplaceDetails(details));
details_ = std::move(details);
}
bool Symbol::CanReplaceDetails(const Details &details) const {
if (has<UnknownDetails>()) {
return true; // can always replace UnknownDetails
} else {
return std::visit(
common::visitors{
[](const UseErrorDetails &) { return true; },
[=](const ObjectEntityDetails &) { return has<EntityDetails>(); },
[=](const ProcEntityDetails &) { return has<EntityDetails>(); },
[=](const SubprogramDetails &) {
return has<SubprogramNameDetails>();
},
[](const auto &) { return false; },
},
details);
}
}
Symbol &Symbol::GetUltimate() {
return const_cast<Symbol &>(static_cast<const Symbol *>(this)->GetUltimate());
}
const Symbol &Symbol::GetUltimate() const {
if (const auto *details{detailsIf<UseDetails>()}) {
return details->symbol().GetUltimate();
[flang] More name resolution for construct entities Push a new scope for constructs and statements that require one (DataStmt, DO CONCURRENT, ForallConstruct, ForallStmt -- there are more to do). Currently we use the Block kind of scope because there is no difference. Perhaps that kind should be renamed to Construct, though it does apply to statements as well as constructs. Add DeclareConstructEntity to create a construct or statement entity. When the type is not specified it can come from the type of a symbol in the enclosing scope with the same name. Change DeclareObjectEntity et al. to return the symbol declared, for the benefit of DeclareConstructEntity. Use DeclareConstructEntity for DO CONCURRENT index-name, LOCAL, and LOCAL_INIT variables and the data-i-do-variable in DataImpliedDo Names in SHARED locality spec need special handling: create a new kinds of symbol with HostAssocDetails to represent the host-association of the shared variables within the construct scope. That symbol gets the LocalityShared flag without affecting the symbol in the outer scope. HostAssoc symbols may be useful in other contexts, e.g. up-level references to local variables. Add parser::DoConstruct::IsDoConcurrent() because DO CONCURRENT loops introduce a construct scope while other DO loops do not. Move CanonicalizeDo to before name resolution so that name resolution doesn't have to deal with labeled DO CONCURRENT loops. Allow for type of index name to be specified in ConcurrentHeader. Resolve the derived type name in an AllocateStmt, StructureConstructor Original-commit: flang-compiler/f18@bc7b9891367f3174c9b5018ce5636a36a5a76c1c Reviewed-on: https://github.com/flang-compiler/f18/pull/214
2018-10-18 16:55:48 +02:00
} else if (const auto *details{detailsIf<HostAssocDetails>()}) {
return details->symbol().GetUltimate();
} else {
return *this;
}
}
DeclTypeSpec *Symbol::GetType() {
return const_cast<DeclTypeSpec *>(
const_cast<const Symbol *>(this)->GetType());
}
const DeclTypeSpec *Symbol::GetType() const {
return std::visit(
common::visitors{
[](const EntityDetails &x) { return x.type(); },
[](const ObjectEntityDetails &x) { return x.type(); },
[](const ProcEntityDetails &x) { return x.interface().type(); },
[](const TypeParamDetails &x) { return x.type(); },
[flang] More name resolution for construct entities Push a new scope for constructs and statements that require one (DataStmt, DO CONCURRENT, ForallConstruct, ForallStmt -- there are more to do). Currently we use the Block kind of scope because there is no difference. Perhaps that kind should be renamed to Construct, though it does apply to statements as well as constructs. Add DeclareConstructEntity to create a construct or statement entity. When the type is not specified it can come from the type of a symbol in the enclosing scope with the same name. Change DeclareObjectEntity et al. to return the symbol declared, for the benefit of DeclareConstructEntity. Use DeclareConstructEntity for DO CONCURRENT index-name, LOCAL, and LOCAL_INIT variables and the data-i-do-variable in DataImpliedDo Names in SHARED locality spec need special handling: create a new kinds of symbol with HostAssocDetails to represent the host-association of the shared variables within the construct scope. That symbol gets the LocalityShared flag without affecting the symbol in the outer scope. HostAssoc symbols may be useful in other contexts, e.g. up-level references to local variables. Add parser::DoConstruct::IsDoConcurrent() because DO CONCURRENT loops introduce a construct scope while other DO loops do not. Move CanonicalizeDo to before name resolution so that name resolution doesn't have to deal with labeled DO CONCURRENT loops. Allow for type of index name to be specified in ConcurrentHeader. Resolve the derived type name in an AllocateStmt, StructureConstructor Original-commit: flang-compiler/f18@bc7b9891367f3174c9b5018ce5636a36a5a76c1c Reviewed-on: https://github.com/flang-compiler/f18/pull/214
2018-10-18 16:55:48 +02:00
[](const auto &) -> const DeclTypeSpec * { return nullptr; },
},
details_);
}
void Symbol::SetType(const DeclTypeSpec &type) {
std::visit(
common::visitors{
[&](EntityDetails &x) { x.set_type(type); },
[&](ObjectEntityDetails &x) { x.set_type(type); },
[&](ProcEntityDetails &x) { x.interface().set_type(type); },
[&](TypeParamDetails &x) { x.set_type(type); },
[](auto &) {},
},
details_);
}
bool Symbol::IsSubprogram() const {
return std::visit(
common::visitors{
[](const SubprogramDetails &) { return true; },
[](const SubprogramNameDetails &) { return true; },
[](const GenericDetails &) { return true; },
[](const UseDetails &x) { return x.symbol().IsSubprogram(); },
[](const auto &) { return false; },
},
details_);
}
bool Symbol::HasExplicitInterface() const {
return std::visit(
common::visitors{
[](const SubprogramDetails &) { return true; },
[](const SubprogramNameDetails &) { return true; },
[](const ProcEntityDetails &x) { return x.HasExplicitInterface(); },
[](const UseDetails &x) { return x.symbol().HasExplicitInterface(); },
[](const auto &) { return false; },
},
details_);
}
bool Symbol::IsSeparateModuleProc() const {
if (attrs().test(Attr::MODULE)) {
if (auto *details{detailsIf<SubprogramDetails>()}) {
return details->isInterface();
}
}
return false;
}
int Symbol::Rank() const {
return std::visit(
common::visitors{
[](const SubprogramDetails &sd) {
if (sd.isFunction()) {
return sd.result().Rank();
} else {
return 0;
}
},
[](const GenericDetails &) {
return 0; /*TODO*/
},
[](const UseDetails &x) { return x.symbol().Rank(); },
[flang] More name resolution for construct entities Push a new scope for constructs and statements that require one (DataStmt, DO CONCURRENT, ForallConstruct, ForallStmt -- there are more to do). Currently we use the Block kind of scope because there is no difference. Perhaps that kind should be renamed to Construct, though it does apply to statements as well as constructs. Add DeclareConstructEntity to create a construct or statement entity. When the type is not specified it can come from the type of a symbol in the enclosing scope with the same name. Change DeclareObjectEntity et al. to return the symbol declared, for the benefit of DeclareConstructEntity. Use DeclareConstructEntity for DO CONCURRENT index-name, LOCAL, and LOCAL_INIT variables and the data-i-do-variable in DataImpliedDo Names in SHARED locality spec need special handling: create a new kinds of symbol with HostAssocDetails to represent the host-association of the shared variables within the construct scope. That symbol gets the LocalityShared flag without affecting the symbol in the outer scope. HostAssoc symbols may be useful in other contexts, e.g. up-level references to local variables. Add parser::DoConstruct::IsDoConcurrent() because DO CONCURRENT loops introduce a construct scope while other DO loops do not. Move CanonicalizeDo to before name resolution so that name resolution doesn't have to deal with labeled DO CONCURRENT loops. Allow for type of index name to be specified in ConcurrentHeader. Resolve the derived type name in an AllocateStmt, StructureConstructor Original-commit: flang-compiler/f18@bc7b9891367f3174c9b5018ce5636a36a5a76c1c Reviewed-on: https://github.com/flang-compiler/f18/pull/214
2018-10-18 16:55:48 +02:00
[](const HostAssocDetails &x) { return x.symbol().Rank(); },
[](const ObjectEntityDetails &oed) {
return static_cast<int>(oed.shape().size());
},
[](const auto &) { return 0; },
},
details_);
}
ObjectEntityDetails::ObjectEntityDetails(const EntityDetails &d)
[flang] Name resolution for derived types. This consists of: - a new kind of symbols to represent them with DerivedTypeDetails - creating symbols for derived types when they are declared - creating a new kind of scope for the type to hold component symbols - resolving entity declarations of objects of derived type - resolving references to objects of derived type and to components - handling derived types with same name as generic Type parameters are not yet implemented. Refactor DeclTypeSpec to be a value class wrapping an IntrinsicTypeSpec or a DerivedTypeSpec (or neither in the TypeStar and ClassStar cases). Store DerivedTypeSpec objects in a new structure the current scope MakeDerivedTypeSpec so that DeclTypeSpec can just contain a pointer to them, as it currently does for intrinsic types. In GenericDetails, add derivedType field to handle case where generic and derived type have the same name. The generic is in the scope and the derived type is referenced from the generic, similar to the case where a generic and specific have the same name. When one of these names is mis-recognized, we sometimes have to fix up the 'occurrences' lists of the symbols. Assign implicit types as soon as an entity is encountered that requires one. Otherwise implicit derived types won't work. When we see 'x%y' we have to know the type of x in order to resolve y. Add an Implicit flag to mark symbols that were implicitly typed For symbols that introduce a new scope, include a pointer back to that scope. Add CurrNonTypeScope() for the times when we want the current scope but ignoring derived type scopes. For example, that happens when looking for types or parameters, or creating implicit symbols. Original-commit: flang-compiler/f18@9bd16da020b64b78ed3928e0244765cd2e2d8068 Reviewed-on: https://github.com/flang-compiler/f18/pull/109
2018-06-22 17:21:19 +02:00
: isDummy_{d.isDummy()}, type_{d.type()} {}
std::ostream &operator<<(std::ostream &os, const EntityDetails &x) {
if (x.type()) {
os << " type: " << *x.type();
}
return os;
}
std::ostream &operator<<(std::ostream &os, const ObjectEntityDetails &x) {
if (x.type()) {
os << " type: " << *x.type();
}
if (!x.shape().empty()) {
os << " shape:";
for (const auto &s : x.shape()) {
os << ' ' << s;
}
}
if (x.init_) {
x.init_->AsFortran(os << " init:");
}
return os;
}
bool ProcEntityDetails::HasExplicitInterface() const {
if (auto *symbol{interface_.symbol()}) {
return symbol->HasExplicitInterface();
}
return false;
}
std::ostream &operator<<(std::ostream &os, const ProcEntityDetails &x) {
if (auto *symbol{x.interface_.symbol()}) {
os << ' ' << symbol->name().ToString();
} else if (auto *type{x.interface_.type()}) {
os << ' ' << *type;
}
return os;
}
[flang] Name resolution for derived types. This consists of: - a new kind of symbols to represent them with DerivedTypeDetails - creating symbols for derived types when they are declared - creating a new kind of scope for the type to hold component symbols - resolving entity declarations of objects of derived type - resolving references to objects of derived type and to components - handling derived types with same name as generic Type parameters are not yet implemented. Refactor DeclTypeSpec to be a value class wrapping an IntrinsicTypeSpec or a DerivedTypeSpec (or neither in the TypeStar and ClassStar cases). Store DerivedTypeSpec objects in a new structure the current scope MakeDerivedTypeSpec so that DeclTypeSpec can just contain a pointer to them, as it currently does for intrinsic types. In GenericDetails, add derivedType field to handle case where generic and derived type have the same name. The generic is in the scope and the derived type is referenced from the generic, similar to the case where a generic and specific have the same name. When one of these names is mis-recognized, we sometimes have to fix up the 'occurrences' lists of the symbols. Assign implicit types as soon as an entity is encountered that requires one. Otherwise implicit derived types won't work. When we see 'x%y' we have to know the type of x in order to resolve y. Add an Implicit flag to mark symbols that were implicitly typed For symbols that introduce a new scope, include a pointer back to that scope. Add CurrNonTypeScope() for the times when we want the current scope but ignoring derived type scopes. For example, that happens when looking for types or parameters, or creating implicit symbols. Original-commit: flang-compiler/f18@9bd16da020b64b78ed3928e0244765cd2e2d8068 Reviewed-on: https://github.com/flang-compiler/f18/pull/109
2018-06-22 17:21:19 +02:00
std::ostream &operator<<(std::ostream &os, const DerivedTypeDetails &x) {
if (const Symbol * extends{x.extends()}) {
os << " extends:" << extends->name();
}
if (x.sequence()) {
os << " sequence";
}
[flang] Name resolution for derived types. This consists of: - a new kind of symbols to represent them with DerivedTypeDetails - creating symbols for derived types when they are declared - creating a new kind of scope for the type to hold component symbols - resolving entity declarations of objects of derived type - resolving references to objects of derived type and to components - handling derived types with same name as generic Type parameters are not yet implemented. Refactor DeclTypeSpec to be a value class wrapping an IntrinsicTypeSpec or a DerivedTypeSpec (or neither in the TypeStar and ClassStar cases). Store DerivedTypeSpec objects in a new structure the current scope MakeDerivedTypeSpec so that DeclTypeSpec can just contain a pointer to them, as it currently does for intrinsic types. In GenericDetails, add derivedType field to handle case where generic and derived type have the same name. The generic is in the scope and the derived type is referenced from the generic, similar to the case where a generic and specific have the same name. When one of these names is mis-recognized, we sometimes have to fix up the 'occurrences' lists of the symbols. Assign implicit types as soon as an entity is encountered that requires one. Otherwise implicit derived types won't work. When we see 'x%y' we have to know the type of x in order to resolve y. Add an Implicit flag to mark symbols that were implicitly typed For symbols that introduce a new scope, include a pointer back to that scope. Add CurrNonTypeScope() for the times when we want the current scope but ignoring derived type scopes. For example, that happens when looking for types or parameters, or creating implicit symbols. Original-commit: flang-compiler/f18@9bd16da020b64b78ed3928e0244765cd2e2d8068 Reviewed-on: https://github.com/flang-compiler/f18/pull/109
2018-06-22 17:21:19 +02:00
return os;
}
static std::ostream &DumpType(std::ostream &os, const Symbol &symbol) {
if (const auto *type{symbol.GetType()}) {
os << *type << ' ';
}
return os;
}
std::ostream &operator<<(std::ostream &os, const Details &details) {
os << DetailsToString(details);
[flang] Partial implementation of Symbols and Scopes. A Symbol consists of a common part (in class Symbol) containing name, owner, attributes. Information for a specific kind of symbol is in a variant containing one of the *Details classes. So the kind of symbol is determined by the type of details class stored in the details_ variant. For scopes there is a single Scope class with an enum indicating the kind. So far there isn't a need for extra kind-specific details as with Symbols but that could change. Symbols defined in a Scope are stored there in a simple map. resolve-names.cc is a partial implementation of a parse-tree walker that resolves names to Symbols. Currently is only handles functions (which introduce a new Scope) and entity-decls. The test-type executable was reused as a driver for this to avoid the need for a new one. Sample output is below. When each "end function" is encountered the scope is dumped, which shows the symbols defined in it. $ cat a.f90 pure integer(8) function foo(arg1, arg2) result(res) integer :: arg1 real :: arg2 contains function bar(arg1) real :: bar real :: arg1 end function end function $ Debug/tools/f18/test-type a.f90 Subprogram scope: 0 children arg1: Entity type: REAL bar: Entity type: REAL Subprogram scope: 1 children arg1: Entity type: INTEGER arg2: Entity type: REAL bar: Subprogram (arg1) foo: Subprogram (arg1, arg2) result(res) res: Entity type: INTEGER(8) Original-commit: flang-compiler/f18@1cd2fbc04da1d6bb2ef5bc1cf07c808460ea7547 Reviewed-on: https://github.com/flang-compiler/f18/pull/30 Tree-same-pre-rewrite: false
2018-03-23 01:08:20 +01:00
std::visit(
common::visitors{
[&](const UnknownDetails &x) {},
[&](const MainProgramDetails &x) {},
[&](const ModuleDetails &x) {
if (x.isSubmodule()) {
[flang] Change when symbol is set in parser::Name Rework how `parser::Name` is resolved to contain a `Symbol`. so that constants in types can be evaluated. For example: ``` integer, parameter :: k = 8 integer(k) :: i ``` The old approach of collecting the symbols at the end of name resolution and filling in the `parser::Name` does not work because the type of `i` needs to be set in the symbol table. The symbol field in `parser::Name` is now mutable so that we can set it during name resolution. `RewriteParseTree` no longer needs to do that (it still warns about unresolved ones), so it does not need to collect symbols and fill them in. Consequently, we can eliminate "occurrences" from symbols -- we just need the name where each is first defined. This requires a lot of refactoring in `resolve-names.cc` to pass around `parser::Name` rather than `SourceName` so that we can resolve the name to a symbol. Fix some bugs where we stored `SourceName *` instead of `SourceName` in the symbol table. The pointers were into the parse tree, so they were only valid as long as the parse tree was around. The symbol table needs to remain valid longer than that, so the names need to be copied. `parser::Name` is not used in the symbol table. Eliminate `GenericSpec`. Currently all we need to do is to resolve the kinds of GenericSpec that contain names. Add `ScopeName` kind of `MiscDetails` for when we need a symbol in the scope to match the name of the scope. For example, `module m` cannot contain a declaration of a new `m`. Subprograms need real details because they can be called recursively. Fix output of partially resolved modules where we know it is a submodule but have not yet resolved the ancestor. Original-commit: flang-compiler/f18@5c1a4b99d2421f5b32e83426488d3fdf7951cfba Reviewed-on: https://github.com/flang-compiler/f18/pull/238 Tree-same-pre-rewrite: false
2018-11-16 21:43:08 +01:00
os << " (";
if (x.ancestor()) {
auto &ancestor{x.ancestor()->name()};
os << ancestor;
if (x.parent()) {
auto &parent{x.parent()->name()};
if (ancestor != parent) {
os << ':' << parent;
}
}
}
os << ")";
}
},
[flang] Partial implementation of Symbols and Scopes. A Symbol consists of a common part (in class Symbol) containing name, owner, attributes. Information for a specific kind of symbol is in a variant containing one of the *Details classes. So the kind of symbol is determined by the type of details class stored in the details_ variant. For scopes there is a single Scope class with an enum indicating the kind. So far there isn't a need for extra kind-specific details as with Symbols but that could change. Symbols defined in a Scope are stored there in a simple map. resolve-names.cc is a partial implementation of a parse-tree walker that resolves names to Symbols. Currently is only handles functions (which introduce a new Scope) and entity-decls. The test-type executable was reused as a driver for this to avoid the need for a new one. Sample output is below. When each "end function" is encountered the scope is dumped, which shows the symbols defined in it. $ cat a.f90 pure integer(8) function foo(arg1, arg2) result(res) integer :: arg1 real :: arg2 contains function bar(arg1) real :: bar real :: arg1 end function end function $ Debug/tools/f18/test-type a.f90 Subprogram scope: 0 children arg1: Entity type: REAL bar: Entity type: REAL Subprogram scope: 1 children arg1: Entity type: INTEGER arg2: Entity type: REAL bar: Subprogram (arg1) foo: Subprogram (arg1, arg2) result(res) res: Entity type: INTEGER(8) Original-commit: flang-compiler/f18@1cd2fbc04da1d6bb2ef5bc1cf07c808460ea7547 Reviewed-on: https://github.com/flang-compiler/f18/pull/30 Tree-same-pre-rewrite: false
2018-03-23 01:08:20 +01:00
[&](const SubprogramDetails &x) {
os << " (";
[flang] Partial implementation of Symbols and Scopes. A Symbol consists of a common part (in class Symbol) containing name, owner, attributes. Information for a specific kind of symbol is in a variant containing one of the *Details classes. So the kind of symbol is determined by the type of details class stored in the details_ variant. For scopes there is a single Scope class with an enum indicating the kind. So far there isn't a need for extra kind-specific details as with Symbols but that could change. Symbols defined in a Scope are stored there in a simple map. resolve-names.cc is a partial implementation of a parse-tree walker that resolves names to Symbols. Currently is only handles functions (which introduce a new Scope) and entity-decls. The test-type executable was reused as a driver for this to avoid the need for a new one. Sample output is below. When each "end function" is encountered the scope is dumped, which shows the symbols defined in it. $ cat a.f90 pure integer(8) function foo(arg1, arg2) result(res) integer :: arg1 real :: arg2 contains function bar(arg1) real :: bar real :: arg1 end function end function $ Debug/tools/f18/test-type a.f90 Subprogram scope: 0 children arg1: Entity type: REAL bar: Entity type: REAL Subprogram scope: 1 children arg1: Entity type: INTEGER arg2: Entity type: REAL bar: Subprogram (arg1) foo: Subprogram (arg1, arg2) result(res) res: Entity type: INTEGER(8) Original-commit: flang-compiler/f18@1cd2fbc04da1d6bb2ef5bc1cf07c808460ea7547 Reviewed-on: https://github.com/flang-compiler/f18/pull/30 Tree-same-pre-rewrite: false
2018-03-23 01:08:20 +01:00
int n = 0;
for (const auto &dummy : x.dummyArgs()) {
[flang] Partial implementation of Symbols and Scopes. A Symbol consists of a common part (in class Symbol) containing name, owner, attributes. Information for a specific kind of symbol is in a variant containing one of the *Details classes. So the kind of symbol is determined by the type of details class stored in the details_ variant. For scopes there is a single Scope class with an enum indicating the kind. So far there isn't a need for extra kind-specific details as with Symbols but that could change. Symbols defined in a Scope are stored there in a simple map. resolve-names.cc is a partial implementation of a parse-tree walker that resolves names to Symbols. Currently is only handles functions (which introduce a new Scope) and entity-decls. The test-type executable was reused as a driver for this to avoid the need for a new one. Sample output is below. When each "end function" is encountered the scope is dumped, which shows the symbols defined in it. $ cat a.f90 pure integer(8) function foo(arg1, arg2) result(res) integer :: arg1 real :: arg2 contains function bar(arg1) real :: bar real :: arg1 end function end function $ Debug/tools/f18/test-type a.f90 Subprogram scope: 0 children arg1: Entity type: REAL bar: Entity type: REAL Subprogram scope: 1 children arg1: Entity type: INTEGER arg2: Entity type: REAL bar: Subprogram (arg1) foo: Subprogram (arg1, arg2) result(res) res: Entity type: INTEGER(8) Original-commit: flang-compiler/f18@1cd2fbc04da1d6bb2ef5bc1cf07c808460ea7547 Reviewed-on: https://github.com/flang-compiler/f18/pull/30 Tree-same-pre-rewrite: false
2018-03-23 01:08:20 +01:00
if (n++ > 0) os << ", ";
DumpType(os, *dummy);
os << dummy->name();
[flang] Partial implementation of Symbols and Scopes. A Symbol consists of a common part (in class Symbol) containing name, owner, attributes. Information for a specific kind of symbol is in a variant containing one of the *Details classes. So the kind of symbol is determined by the type of details class stored in the details_ variant. For scopes there is a single Scope class with an enum indicating the kind. So far there isn't a need for extra kind-specific details as with Symbols but that could change. Symbols defined in a Scope are stored there in a simple map. resolve-names.cc is a partial implementation of a parse-tree walker that resolves names to Symbols. Currently is only handles functions (which introduce a new Scope) and entity-decls. The test-type executable was reused as a driver for this to avoid the need for a new one. Sample output is below. When each "end function" is encountered the scope is dumped, which shows the symbols defined in it. $ cat a.f90 pure integer(8) function foo(arg1, arg2) result(res) integer :: arg1 real :: arg2 contains function bar(arg1) real :: bar real :: arg1 end function end function $ Debug/tools/f18/test-type a.f90 Subprogram scope: 0 children arg1: Entity type: REAL bar: Entity type: REAL Subprogram scope: 1 children arg1: Entity type: INTEGER arg2: Entity type: REAL bar: Subprogram (arg1) foo: Subprogram (arg1, arg2) result(res) res: Entity type: INTEGER(8) Original-commit: flang-compiler/f18@1cd2fbc04da1d6bb2ef5bc1cf07c808460ea7547 Reviewed-on: https://github.com/flang-compiler/f18/pull/30 Tree-same-pre-rewrite: false
2018-03-23 01:08:20 +01:00
}
os << ')';
if (x.isFunction()) {
os << " result(";
DumpType(os, x.result());
os << x.result().name() << ')';
[flang] Partial implementation of Symbols and Scopes. A Symbol consists of a common part (in class Symbol) containing name, owner, attributes. Information for a specific kind of symbol is in a variant containing one of the *Details classes. So the kind of symbol is determined by the type of details class stored in the details_ variant. For scopes there is a single Scope class with an enum indicating the kind. So far there isn't a need for extra kind-specific details as with Symbols but that could change. Symbols defined in a Scope are stored there in a simple map. resolve-names.cc is a partial implementation of a parse-tree walker that resolves names to Symbols. Currently is only handles functions (which introduce a new Scope) and entity-decls. The test-type executable was reused as a driver for this to avoid the need for a new one. Sample output is below. When each "end function" is encountered the scope is dumped, which shows the symbols defined in it. $ cat a.f90 pure integer(8) function foo(arg1, arg2) result(res) integer :: arg1 real :: arg2 contains function bar(arg1) real :: bar real :: arg1 end function end function $ Debug/tools/f18/test-type a.f90 Subprogram scope: 0 children arg1: Entity type: REAL bar: Entity type: REAL Subprogram scope: 1 children arg1: Entity type: INTEGER arg2: Entity type: REAL bar: Subprogram (arg1) foo: Subprogram (arg1, arg2) result(res) res: Entity type: INTEGER(8) Original-commit: flang-compiler/f18@1cd2fbc04da1d6bb2ef5bc1cf07c808460ea7547 Reviewed-on: https://github.com/flang-compiler/f18/pull/30 Tree-same-pre-rewrite: false
2018-03-23 01:08:20 +01:00
}
if (x.isInterface()) {
os << " interface";
}
},
[&](const SubprogramNameDetails &x) {
os << ' ' << EnumToString(x.kind());
[flang] Partial implementation of Symbols and Scopes. A Symbol consists of a common part (in class Symbol) containing name, owner, attributes. Information for a specific kind of symbol is in a variant containing one of the *Details classes. So the kind of symbol is determined by the type of details class stored in the details_ variant. For scopes there is a single Scope class with an enum indicating the kind. So far there isn't a need for extra kind-specific details as with Symbols but that could change. Symbols defined in a Scope are stored there in a simple map. resolve-names.cc is a partial implementation of a parse-tree walker that resolves names to Symbols. Currently is only handles functions (which introduce a new Scope) and entity-decls. The test-type executable was reused as a driver for this to avoid the need for a new one. Sample output is below. When each "end function" is encountered the scope is dumped, which shows the symbols defined in it. $ cat a.f90 pure integer(8) function foo(arg1, arg2) result(res) integer :: arg1 real :: arg2 contains function bar(arg1) real :: bar real :: arg1 end function end function $ Debug/tools/f18/test-type a.f90 Subprogram scope: 0 children arg1: Entity type: REAL bar: Entity type: REAL Subprogram scope: 1 children arg1: Entity type: INTEGER arg2: Entity type: REAL bar: Subprogram (arg1) foo: Subprogram (arg1, arg2) result(res) res: Entity type: INTEGER(8) Original-commit: flang-compiler/f18@1cd2fbc04da1d6bb2ef5bc1cf07c808460ea7547 Reviewed-on: https://github.com/flang-compiler/f18/pull/30 Tree-same-pre-rewrite: false
2018-03-23 01:08:20 +01:00
},
[&](const EntityDetails &x) { os << x; },
[&](const ObjectEntityDetails &x) { os << x; },
[&](const ProcEntityDetails &x) { os << x; },
[flang] Name resolution for derived types. This consists of: - a new kind of symbols to represent them with DerivedTypeDetails - creating symbols for derived types when they are declared - creating a new kind of scope for the type to hold component symbols - resolving entity declarations of objects of derived type - resolving references to objects of derived type and to components - handling derived types with same name as generic Type parameters are not yet implemented. Refactor DeclTypeSpec to be a value class wrapping an IntrinsicTypeSpec or a DerivedTypeSpec (or neither in the TypeStar and ClassStar cases). Store DerivedTypeSpec objects in a new structure the current scope MakeDerivedTypeSpec so that DeclTypeSpec can just contain a pointer to them, as it currently does for intrinsic types. In GenericDetails, add derivedType field to handle case where generic and derived type have the same name. The generic is in the scope and the derived type is referenced from the generic, similar to the case where a generic and specific have the same name. When one of these names is mis-recognized, we sometimes have to fix up the 'occurrences' lists of the symbols. Assign implicit types as soon as an entity is encountered that requires one. Otherwise implicit derived types won't work. When we see 'x%y' we have to know the type of x in order to resolve y. Add an Implicit flag to mark symbols that were implicitly typed For symbols that introduce a new scope, include a pointer back to that scope. Add CurrNonTypeScope() for the times when we want the current scope but ignoring derived type scopes. For example, that happens when looking for types or parameters, or creating implicit symbols. Original-commit: flang-compiler/f18@9bd16da020b64b78ed3928e0244765cd2e2d8068 Reviewed-on: https://github.com/flang-compiler/f18/pull/109
2018-06-22 17:21:19 +02:00
[&](const DerivedTypeDetails &x) { os << x; },
[&](const UseDetails &x) {
os << " from " << x.symbol().name() << " in " << x.module().name();
},
[&](const UseErrorDetails &x) {
os << " uses:";
[flang] Change when symbol is set in parser::Name Rework how `parser::Name` is resolved to contain a `Symbol`. so that constants in types can be evaluated. For example: ``` integer, parameter :: k = 8 integer(k) :: i ``` The old approach of collecting the symbols at the end of name resolution and filling in the `parser::Name` does not work because the type of `i` needs to be set in the symbol table. The symbol field in `parser::Name` is now mutable so that we can set it during name resolution. `RewriteParseTree` no longer needs to do that (it still warns about unresolved ones), so it does not need to collect symbols and fill them in. Consequently, we can eliminate "occurrences" from symbols -- we just need the name where each is first defined. This requires a lot of refactoring in `resolve-names.cc` to pass around `parser::Name` rather than `SourceName` so that we can resolve the name to a symbol. Fix some bugs where we stored `SourceName *` instead of `SourceName` in the symbol table. The pointers were into the parse tree, so they were only valid as long as the parse tree was around. The symbol table needs to remain valid longer than that, so the names need to be copied. `parser::Name` is not used in the symbol table. Eliminate `GenericSpec`. Currently all we need to do is to resolve the kinds of GenericSpec that contain names. Add `ScopeName` kind of `MiscDetails` for when we need a symbol in the scope to match the name of the scope. For example, `module m` cannot contain a declaration of a new `m`. Subprograms need real details because they can be called recursively. Fix output of partially resolved modules where we know it is a submodule but have not yet resolved the ancestor. Original-commit: flang-compiler/f18@5c1a4b99d2421f5b32e83426488d3fdf7951cfba Reviewed-on: https://github.com/flang-compiler/f18/pull/238 Tree-same-pre-rewrite: false
2018-11-16 21:43:08 +01:00
for (const auto &[location, module] : x.occurrences()) {
os << " from " << module->name() << " at " << location;
}
},
[flang] More name resolution for construct entities Push a new scope for constructs and statements that require one (DataStmt, DO CONCURRENT, ForallConstruct, ForallStmt -- there are more to do). Currently we use the Block kind of scope because there is no difference. Perhaps that kind should be renamed to Construct, though it does apply to statements as well as constructs. Add DeclareConstructEntity to create a construct or statement entity. When the type is not specified it can come from the type of a symbol in the enclosing scope with the same name. Change DeclareObjectEntity et al. to return the symbol declared, for the benefit of DeclareConstructEntity. Use DeclareConstructEntity for DO CONCURRENT index-name, LOCAL, and LOCAL_INIT variables and the data-i-do-variable in DataImpliedDo Names in SHARED locality spec need special handling: create a new kinds of symbol with HostAssocDetails to represent the host-association of the shared variables within the construct scope. That symbol gets the LocalityShared flag without affecting the symbol in the outer scope. HostAssoc symbols may be useful in other contexts, e.g. up-level references to local variables. Add parser::DoConstruct::IsDoConcurrent() because DO CONCURRENT loops introduce a construct scope while other DO loops do not. Move CanonicalizeDo to before name resolution so that name resolution doesn't have to deal with labeled DO CONCURRENT loops. Allow for type of index name to be specified in ConcurrentHeader. Resolve the derived type name in an AllocateStmt, StructureConstructor Original-commit: flang-compiler/f18@bc7b9891367f3174c9b5018ce5636a36a5a76c1c Reviewed-on: https://github.com/flang-compiler/f18/pull/214
2018-10-18 16:55:48 +02:00
[](const HostAssocDetails &) {},
[&](const GenericDetails &x) {
for (const auto *proc : x.specificProcs()) {
os << ' ' << proc->name();
}
},
[&](const ProcBindingDetails &x) {
os << " => " << x.symbol().name();
},
[&](const GenericBindingDetails &x) {
os << " =>";
char sep{' '};
for (const auto *proc : x.specificProcs()) {
os << sep << proc->name().ToString();
sep = ',';
}
},
[&](const FinalProcDetails &) {},
[&](const TypeParamDetails &x) {
if (x.type()) {
os << ' ' << *x.type();
}
os << ' ' << common::EnumToString(x.attr());
if (x.init()) {
x.init()->AsFortran(os << " init:");
}
},
[&](const MiscDetails &x) {
os << ' ' << MiscDetails::EnumToString(x.kind());
},
[flang] Partial implementation of Symbols and Scopes. A Symbol consists of a common part (in class Symbol) containing name, owner, attributes. Information for a specific kind of symbol is in a variant containing one of the *Details classes. So the kind of symbol is determined by the type of details class stored in the details_ variant. For scopes there is a single Scope class with an enum indicating the kind. So far there isn't a need for extra kind-specific details as with Symbols but that could change. Symbols defined in a Scope are stored there in a simple map. resolve-names.cc is a partial implementation of a parse-tree walker that resolves names to Symbols. Currently is only handles functions (which introduce a new Scope) and entity-decls. The test-type executable was reused as a driver for this to avoid the need for a new one. Sample output is below. When each "end function" is encountered the scope is dumped, which shows the symbols defined in it. $ cat a.f90 pure integer(8) function foo(arg1, arg2) result(res) integer :: arg1 real :: arg2 contains function bar(arg1) real :: bar real :: arg1 end function end function $ Debug/tools/f18/test-type a.f90 Subprogram scope: 0 children arg1: Entity type: REAL bar: Entity type: REAL Subprogram scope: 1 children arg1: Entity type: INTEGER arg2: Entity type: REAL bar: Subprogram (arg1) foo: Subprogram (arg1, arg2) result(res) res: Entity type: INTEGER(8) Original-commit: flang-compiler/f18@1cd2fbc04da1d6bb2ef5bc1cf07c808460ea7547 Reviewed-on: https://github.com/flang-compiler/f18/pull/30 Tree-same-pre-rewrite: false
2018-03-23 01:08:20 +01:00
},
details);
return os;
}
std::ostream &operator<<(std::ostream &o, Symbol::Flag flag) {
return o << Symbol::EnumToString(flag);
}
std::ostream &operator<<(std::ostream &o, const Symbol::Flags &flags) {
std::size_t n{flags.count()};
std::size_t seen{0};
for (std::size_t j{0}; seen < n; ++j) {
Symbol::Flag flag{static_cast<Symbol::Flag>(j)};
if (flags.test(flag)) {
if (seen++ > 0) {
o << ", ";
}
o << flag;
}
}
return o;
}
std::ostream &operator<<(std::ostream &os, const Symbol &symbol) {
os << symbol.name();
if (!symbol.attrs().empty()) {
os << ", " << symbol.attrs();
}
if (!symbol.flags().empty()) {
os << " (" << symbol.flags() << ')';
}
os << ": " << symbol.details_;
[flang] Partial implementation of Symbols and Scopes. A Symbol consists of a common part (in class Symbol) containing name, owner, attributes. Information for a specific kind of symbol is in a variant containing one of the *Details classes. So the kind of symbol is determined by the type of details class stored in the details_ variant. For scopes there is a single Scope class with an enum indicating the kind. So far there isn't a need for extra kind-specific details as with Symbols but that could change. Symbols defined in a Scope are stored there in a simple map. resolve-names.cc is a partial implementation of a parse-tree walker that resolves names to Symbols. Currently is only handles functions (which introduce a new Scope) and entity-decls. The test-type executable was reused as a driver for this to avoid the need for a new one. Sample output is below. When each "end function" is encountered the scope is dumped, which shows the symbols defined in it. $ cat a.f90 pure integer(8) function foo(arg1, arg2) result(res) integer :: arg1 real :: arg2 contains function bar(arg1) real :: bar real :: arg1 end function end function $ Debug/tools/f18/test-type a.f90 Subprogram scope: 0 children arg1: Entity type: REAL bar: Entity type: REAL Subprogram scope: 1 children arg1: Entity type: INTEGER arg2: Entity type: REAL bar: Subprogram (arg1) foo: Subprogram (arg1, arg2) result(res) res: Entity type: INTEGER(8) Original-commit: flang-compiler/f18@1cd2fbc04da1d6bb2ef5bc1cf07c808460ea7547 Reviewed-on: https://github.com/flang-compiler/f18/pull/30 Tree-same-pre-rewrite: false
2018-03-23 01:08:20 +01:00
return os;
}
// Output a unique name for a scope by qualifying it with the names of
// parent scopes. For scopes without corresponding symbols, use the kind
// with an index (e.g. Block1, Block2, etc.).
static void DumpUniqueName(std::ostream &os, const Scope &scope) {
if (scope.kind() != Scope::Kind::Global) {
DumpUniqueName(os, scope.parent());
os << '/';
if (auto *scopeSymbol{scope.symbol()}) {
os << scopeSymbol->name().ToString();
} else {
int index{1};
for (auto &child : scope.parent().children()) {
if (child == scope) {
break;
}
if (child.kind() == scope.kind()) {
++index;
}
}
os << Scope::EnumToString(scope.kind()) << index;
}
}
}
// Dump a symbol for UnparseWithSymbols. This will be used for tests so the
// format should be reasonably stable.
std::ostream &DumpForUnparse(
std::ostream &os, const Symbol &symbol, bool isDef) {
DumpUniqueName(os, symbol.owner());
os << '/' << symbol.name().ToString();
if (isDef) {
if (!symbol.attrs().empty()) {
os << ' ' << symbol.attrs();
}
if (symbol.test(Symbol::Flag::Implicit)) {
os << " (implicit)";
}
[flang] More name resolution for construct entities Push a new scope for constructs and statements that require one (DataStmt, DO CONCURRENT, ForallConstruct, ForallStmt -- there are more to do). Currently we use the Block kind of scope because there is no difference. Perhaps that kind should be renamed to Construct, though it does apply to statements as well as constructs. Add DeclareConstructEntity to create a construct or statement entity. When the type is not specified it can come from the type of a symbol in the enclosing scope with the same name. Change DeclareObjectEntity et al. to return the symbol declared, for the benefit of DeclareConstructEntity. Use DeclareConstructEntity for DO CONCURRENT index-name, LOCAL, and LOCAL_INIT variables and the data-i-do-variable in DataImpliedDo Names in SHARED locality spec need special handling: create a new kinds of symbol with HostAssocDetails to represent the host-association of the shared variables within the construct scope. That symbol gets the LocalityShared flag without affecting the symbol in the outer scope. HostAssoc symbols may be useful in other contexts, e.g. up-level references to local variables. Add parser::DoConstruct::IsDoConcurrent() because DO CONCURRENT loops introduce a construct scope while other DO loops do not. Move CanonicalizeDo to before name resolution so that name resolution doesn't have to deal with labeled DO CONCURRENT loops. Allow for type of index name to be specified in ConcurrentHeader. Resolve the derived type name in an AllocateStmt, StructureConstructor Original-commit: flang-compiler/f18@bc7b9891367f3174c9b5018ce5636a36a5a76c1c Reviewed-on: https://github.com/flang-compiler/f18/pull/214
2018-10-18 16:55:48 +02:00
if (symbol.test(Symbol::Flag::LocalityLocal)) {
os << " (local)";
}
if (symbol.test(Symbol::Flag::LocalityLocalInit)) {
os << " (local_init)";
}
if (symbol.test(Symbol::Flag::LocalityShared)) {
os << " (shared)";
}
os << ' ' << symbol.GetDetailsName();
if (const auto *type{symbol.GetType()}) {
os << ' ' << *type;
}
}
return os;
}
}