llvm/flang/lib/semantics/symbol.h

678 lines
23 KiB
C
Raw Normal View History

// Copyright (c) 2018-2019, 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
#ifndef FORTRAN_SEMANTICS_SYMBOL_H_
#define FORTRAN_SEMANTICS_SYMBOL_H_
#include "type.h"
#include "../common/Fortran.h"
[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
#include "../common/enum-set.h"
[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 <functional>
[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 <list>
#include <optional>
#include <vector>
[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
/// A Symbol consists of common information (name, owner, and attributes)
/// and details information specific to the kind of symbol, represented by the
/// *Details classes.
class Scope;
class Symbol;
[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
[flang] Merge pull request flang-compiler/f18#539 from flang-compiler/tsk1 Check that procedures of a generic are distinguishable Original-commit: flang-compiler/f18@a24701e313019dbf84179b79e234f92d61de0fa6 Reviewed-on: https://github.com/flang-compiler/f18/pull/539 Due to a conflicting rebase during the linearizing of flang-compiler/f18, this commit squashes a number of other commits: flang-compiler/f18@9b1343af36bd27b110f31dab39c3a18a657a5760 Some cleanup in characteristics.{h,cc} flang-compiler/f18@ddb70e53d2b4e2bba12686e4ac3c26052758fcc3 Merge branch 'master' of github.com:flang-compiler/f18 into tsk1 flang-compiler/f18@d1eef9506610a427f992180f6b59cafe09abb9b9 Merge branch 'master' of github.com:flang-compiler/f18 into tsk1 flang-compiler/f18@24a6d3ffbf4d26d92222b27faa155bb5b3f517f4 Make test_folding.sh stricter in test for warnings flang-compiler/f18@c2c5b640604acceb45823de8cb5716d6921da7d4 Replace SymbolList with SymbolVector flang-compiler/f18@c8499584dff12381c2ce6d4718761cd225b4d97a Add CopyAttrs to copy attributes from Symbol flang-compiler/f18@0573ffd8b2ed5757e06a4fc6d5ffc4401e800c32 Replace cascading detailsIf calls with std::visit flang-compiler/f18@28ec62b3ffeec1d25fde330069b050655bb52a5d Add name to characteristics::DummyArgument flang-compiler/f18@568eaf01145d4ee979423d06f2a65d07222f6841 Add name to CopySymbol() flang-compiler/f18@8c557b09e752da205cd300f63b5ca69806fb2e78 Check that procedures of a generic are distinguishable flang-compiler/f18@50515fd987fd5479567e1b497f6ba93974ffde76 Merge branch 'master' of github.com:flang-compiler/f18 into tsk1 flang-compiler/f18@a7963e98a4aedc97784b99903d04cdc48fd4c346 Address review comments flang-compiler/f18@edd65b3962dbaa1121c166d47c90730e39c25a04 Merge branch 'master' of github.com:flang-compiler/f18 into tsk1
2019-07-02 23:00:44 +02:00
using SymbolVector = std::vector<const Symbol *>;
// A module or submodule.
[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
class ModuleDetails {
public:
ModuleDetails(bool isSubmodule = false) : isSubmodule_{isSubmodule} {}
bool isSubmodule() const { return isSubmodule_; }
const Scope *scope() const { return scope_; }
const Scope *ancestor() const; // for submodule; nullptr for module
const Scope *parent() const; // for submodule; nullptr for module
void set_scope(const Scope *);
[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
private:
bool isSubmodule_;
const Scope *scope_{nullptr};
[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
};
class MainProgramDetails {
public:
private:
};
class SubprogramDetails {
public:
SubprogramDetails() {}
SubprogramDetails(const SubprogramDetails &that)
: dummyArgs_{that.dummyArgs_}, result_{that.result_} {}
bool isFunction() const { return result_ != nullptr; }
bool isInterface() const { return isInterface_; }
void set_isInterface(bool value = true) { isInterface_ = value; }
MaybeExpr bindName() const { return bindName_; }
void set_bindName(MaybeExpr &&expr) { bindName_ = std::move(expr); }
const Symbol &result() const {
CHECK(isFunction());
return *result_;
}
void set_result(Symbol &result) {
CHECK(result_ == nullptr);
result_ = &result;
}
const std::vector<Symbol *> &dummyArgs() const { return dummyArgs_; }
void add_dummyArg(Symbol &symbol) { dummyArgs_.push_back(&symbol); }
void add_alternateReturn() { dummyArgs_.push_back(nullptr); }
[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
private:
bool isInterface_{false}; // true if this represents an interface-body
MaybeExpr bindName_;
std::vector<Symbol *> dummyArgs_; // nullptr -> alternate return indicator
Symbol *result_{nullptr};
[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
friend std::ostream &operator<<(std::ostream &, const SubprogramDetails &);
};
// For SubprogramNameDetails, the kind indicates whether it is the name
// of a module subprogram or internal subprogram.
ENUM_CLASS(SubprogramKind, Module, Internal)
// Symbol with SubprogramNameDetails is created when we scan for module and
// internal procedure names, to record that there is a subprogram with this
// name. Later they are replaced by SubprogramDetails with dummy and result
// type information.
class SubprogramNameDetails {
public:
SubprogramNameDetails(SubprogramKind kind) : kind_{kind} {}
SubprogramNameDetails() = delete;
SubprogramKind kind() const { return kind_; }
private:
SubprogramKind kind_;
};
// A name from an entity-decl -- could be object or function.
[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
class EntityDetails {
public:
explicit EntityDetails(bool isDummy = false) : isDummy_{isDummy} {}
const DeclTypeSpec *type() const { return type_; }
void set_type(const DeclTypeSpec &);
void ReplaceType(const DeclTypeSpec &);
bool isDummy() const { return isDummy_; }
bool isFuncResult() const { return isFuncResult_; }
void set_funcResult(bool x) { isFuncResult_ = x; }
MaybeExpr bindName() const { return bindName_; }
void set_bindName(MaybeExpr &&expr) { bindName_ = std::move(expr); }
private:
bool isDummy_;
bool isFuncResult_{false};
const DeclTypeSpec *type_{nullptr};
MaybeExpr bindName_;
friend std::ostream &operator<<(std::ostream &, const EntityDetails &);
};
[flang] Resolve names in ASSOCIATE and SELECT TYPE Create `AssocEntityDetails` for symbols that represent entities identified by the associate-name in ASSOCIATE and SELECT TYPE constructs. For ASSOCIATE, create a new scope for the associated entity. For SELECT TYPE, create a new scope for each of type guard blocks. Each one contains an associated entity with the appropriate type. For SELECT TYPE, also create a place-holder symbol for the associate-name in the SELECT TYPE statement. The real symbols are in the new scopes and none of them is uniquely identified with the associate-name. Handling of `Selector` is common between these, with `associate-name => expr | variable` recorded in `ConstructVisitor::association_`. When the selector is an expression, derive the type of the associated entity from the type of the expression. This required some refactoring of how `DeclTypeSpec`s are created. The `DerivedTypeSpec` that comes from and expression is const so we can only create const `DeclTypeSpec`s from it. But there were times during name resolution when we needed to set type parameters in the current `DeclTypeSpec`. Now the non-const `DerivedTypeSpec` is saved separately from the const `DeclTypeSpec` while we are processing a declaration type spec. This makes it unnecessary to save the derived type name. Add a type alias for `common::Indirection` to reduce verbosity. Original-commit: flang-compiler/f18@b7668cebe49a122ea23c89c81eafdeba243bbfaf Reviewed-on: https://github.com/flang-compiler/f18/pull/261 Tree-same-pre-rewrite: false
2019-01-16 01:59:20 +01:00
// Symbol is associated with a name or expression in a SELECT TYPE or ASSOCIATE.
class AssocEntityDetails : public EntityDetails {
public:
AssocEntityDetails() {}
explicit AssocEntityDetails(SomeExpr &&expr) : expr_{std::move(expr)} {}
AssocEntityDetails(const AssocEntityDetails &) = default;
AssocEntityDetails(AssocEntityDetails &&) = default;
AssocEntityDetails &operator=(const AssocEntityDetails &) = default;
AssocEntityDetails &operator=(AssocEntityDetails &&) = default;
const MaybeExpr &expr() const { return expr_; }
[flang] Resolve names in ASSOCIATE and SELECT TYPE Create `AssocEntityDetails` for symbols that represent entities identified by the associate-name in ASSOCIATE and SELECT TYPE constructs. For ASSOCIATE, create a new scope for the associated entity. For SELECT TYPE, create a new scope for each of type guard blocks. Each one contains an associated entity with the appropriate type. For SELECT TYPE, also create a place-holder symbol for the associate-name in the SELECT TYPE statement. The real symbols are in the new scopes and none of them is uniquely identified with the associate-name. Handling of `Selector` is common between these, with `associate-name => expr | variable` recorded in `ConstructVisitor::association_`. When the selector is an expression, derive the type of the associated entity from the type of the expression. This required some refactoring of how `DeclTypeSpec`s are created. The `DerivedTypeSpec` that comes from and expression is const so we can only create const `DeclTypeSpec`s from it. But there were times during name resolution when we needed to set type parameters in the current `DeclTypeSpec`. Now the non-const `DerivedTypeSpec` is saved separately from the const `DeclTypeSpec` while we are processing a declaration type spec. This makes it unnecessary to save the derived type name. Add a type alias for `common::Indirection` to reduce verbosity. Original-commit: flang-compiler/f18@b7668cebe49a122ea23c89c81eafdeba243bbfaf Reviewed-on: https://github.com/flang-compiler/f18/pull/261 Tree-same-pre-rewrite: false
2019-01-16 01:59:20 +01:00
private:
MaybeExpr expr_;
[flang] Resolve names in ASSOCIATE and SELECT TYPE Create `AssocEntityDetails` for symbols that represent entities identified by the associate-name in ASSOCIATE and SELECT TYPE constructs. For ASSOCIATE, create a new scope for the associated entity. For SELECT TYPE, create a new scope for each of type guard blocks. Each one contains an associated entity with the appropriate type. For SELECT TYPE, also create a place-holder symbol for the associate-name in the SELECT TYPE statement. The real symbols are in the new scopes and none of them is uniquely identified with the associate-name. Handling of `Selector` is common between these, with `associate-name => expr | variable` recorded in `ConstructVisitor::association_`. When the selector is an expression, derive the type of the associated entity from the type of the expression. This required some refactoring of how `DeclTypeSpec`s are created. The `DerivedTypeSpec` that comes from and expression is const so we can only create const `DeclTypeSpec`s from it. But there were times during name resolution when we needed to set type parameters in the current `DeclTypeSpec`. Now the non-const `DerivedTypeSpec` is saved separately from the const `DeclTypeSpec` while we are processing a declaration type spec. This makes it unnecessary to save the derived type name. Add a type alias for `common::Indirection` to reduce verbosity. Original-commit: flang-compiler/f18@b7668cebe49a122ea23c89c81eafdeba243bbfaf Reviewed-on: https://github.com/flang-compiler/f18/pull/261 Tree-same-pre-rewrite: false
2019-01-16 01:59:20 +01:00
};
// An entity known to be an object.
class ObjectEntityDetails : public EntityDetails {
public:
explicit ObjectEntityDetails(EntityDetails &&);
ObjectEntityDetails(const ObjectEntityDetails &) = default;
ObjectEntityDetails &operator=(const ObjectEntityDetails &) = default;
ObjectEntityDetails(bool isDummy = false) : EntityDetails(isDummy) {}
MaybeExpr &init() { return init_; }
const MaybeExpr &init() const { return init_; }
void set_init(MaybeExpr &&expr) { init_ = std::move(expr); }
bool initWasValidated() const { return initWasValidated_; }
void set_initWasValidated(bool yes = true) { initWasValidated_ = yes; }
ArraySpec &shape() { return shape_; }
const ArraySpec &shape() const { return shape_; }
ArraySpec &coshape() { return coshape_; }
const ArraySpec &coshape() const { return coshape_; }
void set_shape(const ArraySpec &);
void set_coshape(const ArraySpec &);
const Symbol *commonBlock() const { return commonBlock_; }
void set_commonBlock(const Symbol &commonBlock) {
commonBlock_ = &commonBlock;
}
bool IsArray() const { return !shape_.empty(); }
bool IsCoarray() const { return !coshape_.empty(); }
bool IsAssumedShape() const {
return isDummy() && IsArray() && shape_.back().ubound().isDeferred() &&
!shape_.back().lbound().isDeferred();
}
bool IsDeferredShape() const {
return !isDummy() && IsArray() && shape_.back().ubound().isDeferred() &&
shape_.back().lbound().isDeferred();
}
bool IsAssumedSize() const {
return isDummy() && IsArray() && shape_.back().ubound().isAssumed() &&
!shape_.back().lbound().isAssumed();
}
bool IsAssumedRank() const {
return isDummy() && IsArray() && shape_.back().ubound().isAssumed() &&
shape_.back().lbound().isAssumed();
}
[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
private:
MaybeExpr init_;
bool initWasValidated_{false};
ArraySpec shape_;
ArraySpec coshape_;
const Symbol *commonBlock_{nullptr}; // common block this object is in
friend std::ostream &operator<<(std::ostream &, const ObjectEntityDetails &);
};
// Mixin for details with passed-object dummy argument.
// passIndex is set based on passName or the PASS attr.
class WithPassArg {
public:
const SourceName *passName() const { return passName_; }
void set_passName(const SourceName &passName) { passName_ = &passName; }
std::optional<int> passIndex() const { return passIndex_; }
void set_passIndex(int index) { passIndex_ = index; }
private:
const SourceName *passName_{nullptr};
std::optional<int> passIndex_;
};
// A procedure pointer, dummy procedure, or external procedure
class ProcEntityDetails : public EntityDetails, public WithPassArg {
public:
ProcEntityDetails() = default;
explicit ProcEntityDetails(EntityDetails &&d);
const ProcInterface &interface() const { return interface_; }
ProcInterface &interface() { return interface_; }
void set_interface(const ProcInterface &interface) { interface_ = interface; }
inline bool HasExplicitInterface() const;
private:
ProcInterface interface_;
friend std::ostream &operator<<(std::ostream &, const ProcEntityDetails &);
[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
};
// These derived type details represent the characteristics of a derived
// type definition that are shared by all instantiations of that type.
// The DerivedTypeSpec instances whose type symbols share these details
// each own a scope into which the components' symbols have been cloned
// and specialized for each distinct set of type parameter values.
class DerivedTypeDetails {
public:
const std::list<SourceName> &paramNames() const { return paramNames_; }
[flang] Merge pull request flang-compiler/f18#539 from flang-compiler/tsk1 Check that procedures of a generic are distinguishable Original-commit: flang-compiler/f18@a24701e313019dbf84179b79e234f92d61de0fa6 Reviewed-on: https://github.com/flang-compiler/f18/pull/539 Due to a conflicting rebase during the linearizing of flang-compiler/f18, this commit squashes a number of other commits: flang-compiler/f18@9b1343af36bd27b110f31dab39c3a18a657a5760 Some cleanup in characteristics.{h,cc} flang-compiler/f18@ddb70e53d2b4e2bba12686e4ac3c26052758fcc3 Merge branch 'master' of github.com:flang-compiler/f18 into tsk1 flang-compiler/f18@d1eef9506610a427f992180f6b59cafe09abb9b9 Merge branch 'master' of github.com:flang-compiler/f18 into tsk1 flang-compiler/f18@24a6d3ffbf4d26d92222b27faa155bb5b3f517f4 Make test_folding.sh stricter in test for warnings flang-compiler/f18@c2c5b640604acceb45823de8cb5716d6921da7d4 Replace SymbolList with SymbolVector flang-compiler/f18@c8499584dff12381c2ce6d4718761cd225b4d97a Add CopyAttrs to copy attributes from Symbol flang-compiler/f18@0573ffd8b2ed5757e06a4fc6d5ffc4401e800c32 Replace cascading detailsIf calls with std::visit flang-compiler/f18@28ec62b3ffeec1d25fde330069b050655bb52a5d Add name to characteristics::DummyArgument flang-compiler/f18@568eaf01145d4ee979423d06f2a65d07222f6841 Add name to CopySymbol() flang-compiler/f18@8c557b09e752da205cd300f63b5ca69806fb2e78 Check that procedures of a generic are distinguishable flang-compiler/f18@50515fd987fd5479567e1b497f6ba93974ffde76 Merge branch 'master' of github.com:flang-compiler/f18 into tsk1 flang-compiler/f18@a7963e98a4aedc97784b99903d04cdc48fd4c346 Address review comments flang-compiler/f18@edd65b3962dbaa1121c166d47c90730e39c25a04 Merge branch 'master' of github.com:flang-compiler/f18 into tsk1
2019-07-02 23:00:44 +02:00
const SymbolVector &paramDecls() const { return paramDecls_; }
bool sequence() const { return sequence_; }
void add_paramName(const SourceName &name) { paramNames_.push_back(name); }
void add_paramDecl(const Symbol &symbol) { paramDecls_.push_back(&symbol); }
void add_component(const Symbol &);
void set_sequence(bool x = true) { sequence_ = x; }
// Returns the complete list of derived type components in the order
// in which their declarations appear in the derived type definitions
// (parents first). Parent components appear in the list immediately
// after the components that belong to them.
[flang] Merge pull request flang-compiler/f18#539 from flang-compiler/tsk1 Check that procedures of a generic are distinguishable Original-commit: flang-compiler/f18@a24701e313019dbf84179b79e234f92d61de0fa6 Reviewed-on: https://github.com/flang-compiler/f18/pull/539 Due to a conflicting rebase during the linearizing of flang-compiler/f18, this commit squashes a number of other commits: flang-compiler/f18@9b1343af36bd27b110f31dab39c3a18a657a5760 Some cleanup in characteristics.{h,cc} flang-compiler/f18@ddb70e53d2b4e2bba12686e4ac3c26052758fcc3 Merge branch 'master' of github.com:flang-compiler/f18 into tsk1 flang-compiler/f18@d1eef9506610a427f992180f6b59cafe09abb9b9 Merge branch 'master' of github.com:flang-compiler/f18 into tsk1 flang-compiler/f18@24a6d3ffbf4d26d92222b27faa155bb5b3f517f4 Make test_folding.sh stricter in test for warnings flang-compiler/f18@c2c5b640604acceb45823de8cb5716d6921da7d4 Replace SymbolList with SymbolVector flang-compiler/f18@c8499584dff12381c2ce6d4718761cd225b4d97a Add CopyAttrs to copy attributes from Symbol flang-compiler/f18@0573ffd8b2ed5757e06a4fc6d5ffc4401e800c32 Replace cascading detailsIf calls with std::visit flang-compiler/f18@28ec62b3ffeec1d25fde330069b050655bb52a5d Add name to characteristics::DummyArgument flang-compiler/f18@568eaf01145d4ee979423d06f2a65d07222f6841 Add name to CopySymbol() flang-compiler/f18@8c557b09e752da205cd300f63b5ca69806fb2e78 Check that procedures of a generic are distinguishable flang-compiler/f18@50515fd987fd5479567e1b497f6ba93974ffde76 Merge branch 'master' of github.com:flang-compiler/f18 into tsk1 flang-compiler/f18@a7963e98a4aedc97784b99903d04cdc48fd4c346 Address review comments flang-compiler/f18@edd65b3962dbaa1121c166d47c90730e39c25a04 Merge branch 'master' of github.com:flang-compiler/f18 into tsk1
2019-07-02 23:00:44 +02:00
SymbolVector OrderComponents(const Scope &) const;
// If this derived type extends another, locate the parent component's symbol.
const Symbol *GetParentComponent(const Scope &) const;
std::optional<SourceName> GetParentComponentName() const {
if (componentNames_.empty()) {
return std::nullopt;
} else {
return componentNames_.front();
}
}
private:
// These are (1) the names of the derived type parameters in the order
// in which they appear on the type definition statement(s), and (2) the
// symbols that correspond to those names in the order in which their
// declarations appear in the derived type definition(s).
std::list<SourceName> paramNames_;
[flang] Merge pull request flang-compiler/f18#539 from flang-compiler/tsk1 Check that procedures of a generic are distinguishable Original-commit: flang-compiler/f18@a24701e313019dbf84179b79e234f92d61de0fa6 Reviewed-on: https://github.com/flang-compiler/f18/pull/539 Due to a conflicting rebase during the linearizing of flang-compiler/f18, this commit squashes a number of other commits: flang-compiler/f18@9b1343af36bd27b110f31dab39c3a18a657a5760 Some cleanup in characteristics.{h,cc} flang-compiler/f18@ddb70e53d2b4e2bba12686e4ac3c26052758fcc3 Merge branch 'master' of github.com:flang-compiler/f18 into tsk1 flang-compiler/f18@d1eef9506610a427f992180f6b59cafe09abb9b9 Merge branch 'master' of github.com:flang-compiler/f18 into tsk1 flang-compiler/f18@24a6d3ffbf4d26d92222b27faa155bb5b3f517f4 Make test_folding.sh stricter in test for warnings flang-compiler/f18@c2c5b640604acceb45823de8cb5716d6921da7d4 Replace SymbolList with SymbolVector flang-compiler/f18@c8499584dff12381c2ce6d4718761cd225b4d97a Add CopyAttrs to copy attributes from Symbol flang-compiler/f18@0573ffd8b2ed5757e06a4fc6d5ffc4401e800c32 Replace cascading detailsIf calls with std::visit flang-compiler/f18@28ec62b3ffeec1d25fde330069b050655bb52a5d Add name to characteristics::DummyArgument flang-compiler/f18@568eaf01145d4ee979423d06f2a65d07222f6841 Add name to CopySymbol() flang-compiler/f18@8c557b09e752da205cd300f63b5ca69806fb2e78 Check that procedures of a generic are distinguishable flang-compiler/f18@50515fd987fd5479567e1b497f6ba93974ffde76 Merge branch 'master' of github.com:flang-compiler/f18 into tsk1 flang-compiler/f18@a7963e98a4aedc97784b99903d04cdc48fd4c346 Address review comments flang-compiler/f18@edd65b3962dbaa1121c166d47c90730e39c25a04 Merge branch 'master' of github.com:flang-compiler/f18 into tsk1
2019-07-02 23:00:44 +02:00
SymbolVector paramDecls_;
// These are the names of the derived type's components in component
// order. A parent component, if any, appears first in this list.
std::list<SourceName> componentNames_;
bool sequence_{false};
friend std::ostream &operator<<(std::ostream &, const DerivedTypeDetails &);
};
[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
class ProcBindingDetails : public WithPassArg {
public:
explicit ProcBindingDetails(const Symbol &symbol) : symbol_{&symbol} {}
const Symbol &symbol() const { return *symbol_; }
private:
const Symbol *symbol_; // procedure bound to
};
ENUM_CLASS(GenericKind, // Kinds of generic-spec
[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-18 19:48:02 +01:00
Name, DefinedOp, // these have a Name associated with them
Assignment, // user-defined assignment
OpPower, OpMultiply, OpDivide, OpAdd, OpSubtract, OpConcat, OpLT, OpLE,
OpEQ, OpNE, OpGE, OpGT, OpNOT, OpAND, OpOR, OpXOR, OpEQV, OpNEQV,
ReadFormatted, ReadUnformatted, WriteFormatted, WriteUnformatted)
class GenericBindingDetails {
public:
GenericBindingDetails() {}
[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-18 19:48:02 +01:00
GenericKind kind() const { return kind_; }
void set_kind(GenericKind kind) { kind_ = kind; }
[flang] Merge pull request flang-compiler/f18#539 from flang-compiler/tsk1 Check that procedures of a generic are distinguishable Original-commit: flang-compiler/f18@a24701e313019dbf84179b79e234f92d61de0fa6 Reviewed-on: https://github.com/flang-compiler/f18/pull/539 Due to a conflicting rebase during the linearizing of flang-compiler/f18, this commit squashes a number of other commits: flang-compiler/f18@9b1343af36bd27b110f31dab39c3a18a657a5760 Some cleanup in characteristics.{h,cc} flang-compiler/f18@ddb70e53d2b4e2bba12686e4ac3c26052758fcc3 Merge branch 'master' of github.com:flang-compiler/f18 into tsk1 flang-compiler/f18@d1eef9506610a427f992180f6b59cafe09abb9b9 Merge branch 'master' of github.com:flang-compiler/f18 into tsk1 flang-compiler/f18@24a6d3ffbf4d26d92222b27faa155bb5b3f517f4 Make test_folding.sh stricter in test for warnings flang-compiler/f18@c2c5b640604acceb45823de8cb5716d6921da7d4 Replace SymbolList with SymbolVector flang-compiler/f18@c8499584dff12381c2ce6d4718761cd225b4d97a Add CopyAttrs to copy attributes from Symbol flang-compiler/f18@0573ffd8b2ed5757e06a4fc6d5ffc4401e800c32 Replace cascading detailsIf calls with std::visit flang-compiler/f18@28ec62b3ffeec1d25fde330069b050655bb52a5d Add name to characteristics::DummyArgument flang-compiler/f18@568eaf01145d4ee979423d06f2a65d07222f6841 Add name to CopySymbol() flang-compiler/f18@8c557b09e752da205cd300f63b5ca69806fb2e78 Check that procedures of a generic are distinguishable flang-compiler/f18@50515fd987fd5479567e1b497f6ba93974ffde76 Merge branch 'master' of github.com:flang-compiler/f18 into tsk1 flang-compiler/f18@a7963e98a4aedc97784b99903d04cdc48fd4c346 Address review comments flang-compiler/f18@edd65b3962dbaa1121c166d47c90730e39c25a04 Merge branch 'master' of github.com:flang-compiler/f18 into tsk1
2019-07-02 23:00:44 +02:00
const SymbolVector &specificProcs() const { return specificProcs_; }
void add_specificProc(const Symbol &proc) { specificProcs_.push_back(&proc); }
[flang] Merge pull request flang-compiler/f18#539 from flang-compiler/tsk1 Check that procedures of a generic are distinguishable Original-commit: flang-compiler/f18@a24701e313019dbf84179b79e234f92d61de0fa6 Reviewed-on: https://github.com/flang-compiler/f18/pull/539 Due to a conflicting rebase during the linearizing of flang-compiler/f18, this commit squashes a number of other commits: flang-compiler/f18@9b1343af36bd27b110f31dab39c3a18a657a5760 Some cleanup in characteristics.{h,cc} flang-compiler/f18@ddb70e53d2b4e2bba12686e4ac3c26052758fcc3 Merge branch 'master' of github.com:flang-compiler/f18 into tsk1 flang-compiler/f18@d1eef9506610a427f992180f6b59cafe09abb9b9 Merge branch 'master' of github.com:flang-compiler/f18 into tsk1 flang-compiler/f18@24a6d3ffbf4d26d92222b27faa155bb5b3f517f4 Make test_folding.sh stricter in test for warnings flang-compiler/f18@c2c5b640604acceb45823de8cb5716d6921da7d4 Replace SymbolList with SymbolVector flang-compiler/f18@c8499584dff12381c2ce6d4718761cd225b4d97a Add CopyAttrs to copy attributes from Symbol flang-compiler/f18@0573ffd8b2ed5757e06a4fc6d5ffc4401e800c32 Replace cascading detailsIf calls with std::visit flang-compiler/f18@28ec62b3ffeec1d25fde330069b050655bb52a5d Add name to characteristics::DummyArgument flang-compiler/f18@568eaf01145d4ee979423d06f2a65d07222f6841 Add name to CopySymbol() flang-compiler/f18@8c557b09e752da205cd300f63b5ca69806fb2e78 Check that procedures of a generic are distinguishable flang-compiler/f18@50515fd987fd5479567e1b497f6ba93974ffde76 Merge branch 'master' of github.com:flang-compiler/f18 into tsk1 flang-compiler/f18@a7963e98a4aedc97784b99903d04cdc48fd4c346 Address review comments flang-compiler/f18@edd65b3962dbaa1121c166d47c90730e39c25a04 Merge branch 'master' of github.com:flang-compiler/f18 into tsk1
2019-07-02 23:00:44 +02:00
void add_specificProcs(const SymbolVector &procs) {
specificProcs_.insert(specificProcs_.end(), procs.begin(), procs.end());
}
private:
[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-18 19:48:02 +01:00
GenericKind kind_{GenericKind::Name};
[flang] Merge pull request flang-compiler/f18#539 from flang-compiler/tsk1 Check that procedures of a generic are distinguishable Original-commit: flang-compiler/f18@a24701e313019dbf84179b79e234f92d61de0fa6 Reviewed-on: https://github.com/flang-compiler/f18/pull/539 Due to a conflicting rebase during the linearizing of flang-compiler/f18, this commit squashes a number of other commits: flang-compiler/f18@9b1343af36bd27b110f31dab39c3a18a657a5760 Some cleanup in characteristics.{h,cc} flang-compiler/f18@ddb70e53d2b4e2bba12686e4ac3c26052758fcc3 Merge branch 'master' of github.com:flang-compiler/f18 into tsk1 flang-compiler/f18@d1eef9506610a427f992180f6b59cafe09abb9b9 Merge branch 'master' of github.com:flang-compiler/f18 into tsk1 flang-compiler/f18@24a6d3ffbf4d26d92222b27faa155bb5b3f517f4 Make test_folding.sh stricter in test for warnings flang-compiler/f18@c2c5b640604acceb45823de8cb5716d6921da7d4 Replace SymbolList with SymbolVector flang-compiler/f18@c8499584dff12381c2ce6d4718761cd225b4d97a Add CopyAttrs to copy attributes from Symbol flang-compiler/f18@0573ffd8b2ed5757e06a4fc6d5ffc4401e800c32 Replace cascading detailsIf calls with std::visit flang-compiler/f18@28ec62b3ffeec1d25fde330069b050655bb52a5d Add name to characteristics::DummyArgument flang-compiler/f18@568eaf01145d4ee979423d06f2a65d07222f6841 Add name to CopySymbol() flang-compiler/f18@8c557b09e752da205cd300f63b5ca69806fb2e78 Check that procedures of a generic are distinguishable flang-compiler/f18@50515fd987fd5479567e1b497f6ba93974ffde76 Merge branch 'master' of github.com:flang-compiler/f18 into tsk1 flang-compiler/f18@a7963e98a4aedc97784b99903d04cdc48fd4c346 Address review comments flang-compiler/f18@edd65b3962dbaa1121c166d47c90730e39c25a04 Merge branch 'master' of github.com:flang-compiler/f18 into tsk1
2019-07-02 23:00:44 +02:00
SymbolVector specificProcs_;
};
class NamelistDetails {
public:
[flang] Merge pull request flang-compiler/f18#539 from flang-compiler/tsk1 Check that procedures of a generic are distinguishable Original-commit: flang-compiler/f18@a24701e313019dbf84179b79e234f92d61de0fa6 Reviewed-on: https://github.com/flang-compiler/f18/pull/539 Due to a conflicting rebase during the linearizing of flang-compiler/f18, this commit squashes a number of other commits: flang-compiler/f18@9b1343af36bd27b110f31dab39c3a18a657a5760 Some cleanup in characteristics.{h,cc} flang-compiler/f18@ddb70e53d2b4e2bba12686e4ac3c26052758fcc3 Merge branch 'master' of github.com:flang-compiler/f18 into tsk1 flang-compiler/f18@d1eef9506610a427f992180f6b59cafe09abb9b9 Merge branch 'master' of github.com:flang-compiler/f18 into tsk1 flang-compiler/f18@24a6d3ffbf4d26d92222b27faa155bb5b3f517f4 Make test_folding.sh stricter in test for warnings flang-compiler/f18@c2c5b640604acceb45823de8cb5716d6921da7d4 Replace SymbolList with SymbolVector flang-compiler/f18@c8499584dff12381c2ce6d4718761cd225b4d97a Add CopyAttrs to copy attributes from Symbol flang-compiler/f18@0573ffd8b2ed5757e06a4fc6d5ffc4401e800c32 Replace cascading detailsIf calls with std::visit flang-compiler/f18@28ec62b3ffeec1d25fde330069b050655bb52a5d Add name to characteristics::DummyArgument flang-compiler/f18@568eaf01145d4ee979423d06f2a65d07222f6841 Add name to CopySymbol() flang-compiler/f18@8c557b09e752da205cd300f63b5ca69806fb2e78 Check that procedures of a generic are distinguishable flang-compiler/f18@50515fd987fd5479567e1b497f6ba93974ffde76 Merge branch 'master' of github.com:flang-compiler/f18 into tsk1 flang-compiler/f18@a7963e98a4aedc97784b99903d04cdc48fd4c346 Address review comments flang-compiler/f18@edd65b3962dbaa1121c166d47c90730e39c25a04 Merge branch 'master' of github.com:flang-compiler/f18 into tsk1
2019-07-02 23:00:44 +02:00
const SymbolVector &objects() const { return objects_; }
void add_object(const Symbol &object) { objects_.push_back(&object); }
[flang] Merge pull request flang-compiler/f18#539 from flang-compiler/tsk1 Check that procedures of a generic are distinguishable Original-commit: flang-compiler/f18@a24701e313019dbf84179b79e234f92d61de0fa6 Reviewed-on: https://github.com/flang-compiler/f18/pull/539 Due to a conflicting rebase during the linearizing of flang-compiler/f18, this commit squashes a number of other commits: flang-compiler/f18@9b1343af36bd27b110f31dab39c3a18a657a5760 Some cleanup in characteristics.{h,cc} flang-compiler/f18@ddb70e53d2b4e2bba12686e4ac3c26052758fcc3 Merge branch 'master' of github.com:flang-compiler/f18 into tsk1 flang-compiler/f18@d1eef9506610a427f992180f6b59cafe09abb9b9 Merge branch 'master' of github.com:flang-compiler/f18 into tsk1 flang-compiler/f18@24a6d3ffbf4d26d92222b27faa155bb5b3f517f4 Make test_folding.sh stricter in test for warnings flang-compiler/f18@c2c5b640604acceb45823de8cb5716d6921da7d4 Replace SymbolList with SymbolVector flang-compiler/f18@c8499584dff12381c2ce6d4718761cd225b4d97a Add CopyAttrs to copy attributes from Symbol flang-compiler/f18@0573ffd8b2ed5757e06a4fc6d5ffc4401e800c32 Replace cascading detailsIf calls with std::visit flang-compiler/f18@28ec62b3ffeec1d25fde330069b050655bb52a5d Add name to characteristics::DummyArgument flang-compiler/f18@568eaf01145d4ee979423d06f2a65d07222f6841 Add name to CopySymbol() flang-compiler/f18@8c557b09e752da205cd300f63b5ca69806fb2e78 Check that procedures of a generic are distinguishable flang-compiler/f18@50515fd987fd5479567e1b497f6ba93974ffde76 Merge branch 'master' of github.com:flang-compiler/f18 into tsk1 flang-compiler/f18@a7963e98a4aedc97784b99903d04cdc48fd4c346 Address review comments flang-compiler/f18@edd65b3962dbaa1121c166d47c90730e39c25a04 Merge branch 'master' of github.com:flang-compiler/f18 into tsk1
2019-07-02 23:00:44 +02:00
void add_objects(const SymbolVector &objects) {
objects_.insert(objects_.end(), objects.begin(), objects.end());
}
private:
[flang] Merge pull request flang-compiler/f18#539 from flang-compiler/tsk1 Check that procedures of a generic are distinguishable Original-commit: flang-compiler/f18@a24701e313019dbf84179b79e234f92d61de0fa6 Reviewed-on: https://github.com/flang-compiler/f18/pull/539 Due to a conflicting rebase during the linearizing of flang-compiler/f18, this commit squashes a number of other commits: flang-compiler/f18@9b1343af36bd27b110f31dab39c3a18a657a5760 Some cleanup in characteristics.{h,cc} flang-compiler/f18@ddb70e53d2b4e2bba12686e4ac3c26052758fcc3 Merge branch 'master' of github.com:flang-compiler/f18 into tsk1 flang-compiler/f18@d1eef9506610a427f992180f6b59cafe09abb9b9 Merge branch 'master' of github.com:flang-compiler/f18 into tsk1 flang-compiler/f18@24a6d3ffbf4d26d92222b27faa155bb5b3f517f4 Make test_folding.sh stricter in test for warnings flang-compiler/f18@c2c5b640604acceb45823de8cb5716d6921da7d4 Replace SymbolList with SymbolVector flang-compiler/f18@c8499584dff12381c2ce6d4718761cd225b4d97a Add CopyAttrs to copy attributes from Symbol flang-compiler/f18@0573ffd8b2ed5757e06a4fc6d5ffc4401e800c32 Replace cascading detailsIf calls with std::visit flang-compiler/f18@28ec62b3ffeec1d25fde330069b050655bb52a5d Add name to characteristics::DummyArgument flang-compiler/f18@568eaf01145d4ee979423d06f2a65d07222f6841 Add name to CopySymbol() flang-compiler/f18@8c557b09e752da205cd300f63b5ca69806fb2e78 Check that procedures of a generic are distinguishable flang-compiler/f18@50515fd987fd5479567e1b497f6ba93974ffde76 Merge branch 'master' of github.com:flang-compiler/f18 into tsk1 flang-compiler/f18@a7963e98a4aedc97784b99903d04cdc48fd4c346 Address review comments flang-compiler/f18@edd65b3962dbaa1121c166d47c90730e39c25a04 Merge branch 'master' of github.com:flang-compiler/f18 into tsk1
2019-07-02 23:00:44 +02:00
SymbolVector objects_;
};
class CommonBlockDetails {
public:
std::list<Symbol *> &objects() { return objects_; }
const std::list<Symbol *> &objects() const { return objects_; }
void add_object(Symbol &object) { objects_.push_back(&object); }
MaybeExpr bindName() const { return bindName_; }
void set_bindName(MaybeExpr &&expr) { bindName_ = std::move(expr); }
private:
std::list<Symbol *> objects_;
MaybeExpr bindName_;
};
class FinalProcDetails {};
class MiscDetails {
public:
ENUM_CLASS(Kind, None, ConstructName, ScopeName, PassName, ComplexPartRe,
ComplexPartIm, KindParamInquiry, LenParamInquiry,
SelectTypeAssociateName);
MiscDetails(Kind kind) : kind_{kind} {}
Kind kind() const { return kind_; }
private:
Kind kind_;
};
class TypeParamDetails {
public:
explicit TypeParamDetails(common::TypeParamAttr attr) : attr_{attr} {}
TypeParamDetails(const TypeParamDetails &) = default;
common::TypeParamAttr attr() const { return attr_; }
MaybeIntExpr &init() { return init_; }
const MaybeIntExpr &init() const { return init_; }
void set_init(MaybeIntExpr &&expr) { init_ = std::move(expr); }
const DeclTypeSpec *type() const { return type_; }
void set_type(const DeclTypeSpec &);
void ReplaceType(const DeclTypeSpec &);
private:
common::TypeParamAttr attr_;
MaybeIntExpr init_;
const DeclTypeSpec *type_{nullptr};
};
// Record the USE of a symbol: location is where (USE statement or renaming);
// symbol is the USEd module.
class UseDetails {
public:
UseDetails(const SourceName &location, const Symbol &symbol)
[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
: location_{location}, symbol_{&symbol} {}
const SourceName &location() const { return location_; }
const Symbol &symbol() const { return *symbol_; }
const Symbol &module() const;
private:
[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
SourceName location_;
const Symbol *symbol_;
};
// A symbol with ambiguous use-associations. Record where they were so
// we can report the error if it is used.
class UseErrorDetails {
public:
UseErrorDetails(const UseDetails &);
UseErrorDetails &add_occurrence(const SourceName &, const Scope &);
[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
using listType = std::list<std::pair<SourceName, const Scope *>>;
const listType occurrences() const { return occurrences_; };
private:
listType occurrences_;
};
[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
// A symbol host-associated from an enclosing scope.
class HostAssocDetails {
public:
HostAssocDetails(const Symbol &symbol) : symbol_{&symbol} {}
const Symbol &symbol() const { return *symbol_; }
private:
const Symbol *symbol_;
};
class GenericDetails {
public:
GenericDetails() {}
[flang] Merge pull request flang-compiler/f18#539 from flang-compiler/tsk1 Check that procedures of a generic are distinguishable Original-commit: flang-compiler/f18@a24701e313019dbf84179b79e234f92d61de0fa6 Reviewed-on: https://github.com/flang-compiler/f18/pull/539 Due to a conflicting rebase during the linearizing of flang-compiler/f18, this commit squashes a number of other commits: flang-compiler/f18@9b1343af36bd27b110f31dab39c3a18a657a5760 Some cleanup in characteristics.{h,cc} flang-compiler/f18@ddb70e53d2b4e2bba12686e4ac3c26052758fcc3 Merge branch 'master' of github.com:flang-compiler/f18 into tsk1 flang-compiler/f18@d1eef9506610a427f992180f6b59cafe09abb9b9 Merge branch 'master' of github.com:flang-compiler/f18 into tsk1 flang-compiler/f18@24a6d3ffbf4d26d92222b27faa155bb5b3f517f4 Make test_folding.sh stricter in test for warnings flang-compiler/f18@c2c5b640604acceb45823de8cb5716d6921da7d4 Replace SymbolList with SymbolVector flang-compiler/f18@c8499584dff12381c2ce6d4718761cd225b4d97a Add CopyAttrs to copy attributes from Symbol flang-compiler/f18@0573ffd8b2ed5757e06a4fc6d5ffc4401e800c32 Replace cascading detailsIf calls with std::visit flang-compiler/f18@28ec62b3ffeec1d25fde330069b050655bb52a5d Add name to characteristics::DummyArgument flang-compiler/f18@568eaf01145d4ee979423d06f2a65d07222f6841 Add name to CopySymbol() flang-compiler/f18@8c557b09e752da205cd300f63b5ca69806fb2e78 Check that procedures of a generic are distinguishable flang-compiler/f18@50515fd987fd5479567e1b497f6ba93974ffde76 Merge branch 'master' of github.com:flang-compiler/f18 into tsk1 flang-compiler/f18@a7963e98a4aedc97784b99903d04cdc48fd4c346 Address review comments flang-compiler/f18@edd65b3962dbaa1121c166d47c90730e39c25a04 Merge branch 'master' of github.com:flang-compiler/f18 into tsk1
2019-07-02 23:00:44 +02:00
GenericDetails(const SymbolVector &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
GenericDetails(Symbol *specific) : specific_{specific} {}
[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-18 19:48:02 +01:00
GenericKind kind() const { return kind_; }
void set_kind(GenericKind kind) { kind_ = kind; }
[flang] Merge pull request flang-compiler/f18#539 from flang-compiler/tsk1 Check that procedures of a generic are distinguishable Original-commit: flang-compiler/f18@a24701e313019dbf84179b79e234f92d61de0fa6 Reviewed-on: https://github.com/flang-compiler/f18/pull/539 Due to a conflicting rebase during the linearizing of flang-compiler/f18, this commit squashes a number of other commits: flang-compiler/f18@9b1343af36bd27b110f31dab39c3a18a657a5760 Some cleanup in characteristics.{h,cc} flang-compiler/f18@ddb70e53d2b4e2bba12686e4ac3c26052758fcc3 Merge branch 'master' of github.com:flang-compiler/f18 into tsk1 flang-compiler/f18@d1eef9506610a427f992180f6b59cafe09abb9b9 Merge branch 'master' of github.com:flang-compiler/f18 into tsk1 flang-compiler/f18@24a6d3ffbf4d26d92222b27faa155bb5b3f517f4 Make test_folding.sh stricter in test for warnings flang-compiler/f18@c2c5b640604acceb45823de8cb5716d6921da7d4 Replace SymbolList with SymbolVector flang-compiler/f18@c8499584dff12381c2ce6d4718761cd225b4d97a Add CopyAttrs to copy attributes from Symbol flang-compiler/f18@0573ffd8b2ed5757e06a4fc6d5ffc4401e800c32 Replace cascading detailsIf calls with std::visit flang-compiler/f18@28ec62b3ffeec1d25fde330069b050655bb52a5d Add name to characteristics::DummyArgument flang-compiler/f18@568eaf01145d4ee979423d06f2a65d07222f6841 Add name to CopySymbol() flang-compiler/f18@8c557b09e752da205cd300f63b5ca69806fb2e78 Check that procedures of a generic are distinguishable flang-compiler/f18@50515fd987fd5479567e1b497f6ba93974ffde76 Merge branch 'master' of github.com:flang-compiler/f18 into tsk1 flang-compiler/f18@a7963e98a4aedc97784b99903d04cdc48fd4c346 Address review comments flang-compiler/f18@edd65b3962dbaa1121c166d47c90730e39c25a04 Merge branch 'master' of github.com:flang-compiler/f18 into tsk1
2019-07-02 23:00:44 +02:00
const SymbolVector &specificProcs() const { return specificProcs_; }
void add_specificProc(const Symbol &proc) { specificProcs_.push_back(&proc); }
[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
Symbol *specific() { return specific_; }
const Symbol *specific() const { return 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
void set_specific(Symbol &specific);
// Derived type with same name as generic, if any.
Symbol *derivedType() { return derivedType_; }
const Symbol *derivedType() const { return derivedType_; }
void set_derivedType(Symbol &derivedType);
// Check that specific is one of the specificProcs. If not, return the
// specific as a raw pointer.
const Symbol *CheckSpecific() const;
[flang] Continue semantic checking after name resolution error When an error occurs in name resolution, continue semantic processing in order to detect other errors. This means we can no longer assume that every `parser::Name` has a symbol even after name resolution completes. In `RewriteMutator`, only report internal error for unresolved symbol if there have been no fatal errors. Add `Error` flag to `Symbol` to indicate that an error occcurred related to it. Once we report an error about a symbol we should avoid reporting any more to prevent cascading errors. Add `HasError()` and `SetError()` to simplify working with this flag. Change some places that we assume that a `parser::Name` has a non-null symbol. There are probably more. `resolve-names.cc`: Set the `Error` flag when we report a fatal error related to a symbol. (This requires making some symbols non-const.) Remove `CheckScalarIntegerType()` as `ExprChecker` will take care of those constraints if they are expressed in the parse tree. One exception to that is the name in a `ConcurrentControl`. Explicitly perform that check using `EvaluateExpr()` and constraint classes so we get consistent error messages. In expression analysis, when a constraint is violated (like `Scalar<>` or `Integer<>`), reset the wrapped expression so that we don't assume it is valid. A `GenericExprWrapper` holding a std::nullopt indicates error. Change `EnforceTypeConstraint()` to return false when the constraint fails to enable this. check-do-concurrent.cc: Reorganize the Gather*VariableNames functions into one to simplify the task of filtering out unresolved names. Remove `CheckNoDuplicates()` and `CheckNoCollisions()` as those checks is already done in name resolution when the names are added to the scope. Original-commit: flang-compiler/f18@bcdb679405906575f36d3314f17da89e3e89d45c Reviewed-on: https://github.com/flang-compiler/f18/pull/429 Tree-same-pre-rewrite: false
2019-04-25 22:18:33 +02:00
Symbol *CheckSpecific();
private:
[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-18 19:48:02 +01:00
GenericKind kind_{GenericKind::Name};
// all of the specific procedures for this generic
[flang] Merge pull request flang-compiler/f18#539 from flang-compiler/tsk1 Check that procedures of a generic are distinguishable Original-commit: flang-compiler/f18@a24701e313019dbf84179b79e234f92d61de0fa6 Reviewed-on: https://github.com/flang-compiler/f18/pull/539 Due to a conflicting rebase during the linearizing of flang-compiler/f18, this commit squashes a number of other commits: flang-compiler/f18@9b1343af36bd27b110f31dab39c3a18a657a5760 Some cleanup in characteristics.{h,cc} flang-compiler/f18@ddb70e53d2b4e2bba12686e4ac3c26052758fcc3 Merge branch 'master' of github.com:flang-compiler/f18 into tsk1 flang-compiler/f18@d1eef9506610a427f992180f6b59cafe09abb9b9 Merge branch 'master' of github.com:flang-compiler/f18 into tsk1 flang-compiler/f18@24a6d3ffbf4d26d92222b27faa155bb5b3f517f4 Make test_folding.sh stricter in test for warnings flang-compiler/f18@c2c5b640604acceb45823de8cb5716d6921da7d4 Replace SymbolList with SymbolVector flang-compiler/f18@c8499584dff12381c2ce6d4718761cd225b4d97a Add CopyAttrs to copy attributes from Symbol flang-compiler/f18@0573ffd8b2ed5757e06a4fc6d5ffc4401e800c32 Replace cascading detailsIf calls with std::visit flang-compiler/f18@28ec62b3ffeec1d25fde330069b050655bb52a5d Add name to characteristics::DummyArgument flang-compiler/f18@568eaf01145d4ee979423d06f2a65d07222f6841 Add name to CopySymbol() flang-compiler/f18@8c557b09e752da205cd300f63b5ca69806fb2e78 Check that procedures of a generic are distinguishable flang-compiler/f18@50515fd987fd5479567e1b497f6ba93974ffde76 Merge branch 'master' of github.com:flang-compiler/f18 into tsk1 flang-compiler/f18@a7963e98a4aedc97784b99903d04cdc48fd4c346 Address review comments flang-compiler/f18@edd65b3962dbaa1121c166d47c90730e39c25a04 Merge branch 'master' of github.com:flang-compiler/f18 into tsk1
2019-07-02 23:00:44 +02:00
SymbolVector specificProcs_;
// a specific procedure with the same name as this generic, if any
[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
Symbol *specific_{nullptr};
[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
// a derived type with the same name as this generic, if any
Symbol *derivedType_{nullptr};
};
class UnknownDetails {};
[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
using Details = std::variant<UnknownDetails, MainProgramDetails, ModuleDetails,
SubprogramDetails, SubprogramNameDetails, EntityDetails,
[flang] Resolve names in ASSOCIATE and SELECT TYPE Create `AssocEntityDetails` for symbols that represent entities identified by the associate-name in ASSOCIATE and SELECT TYPE constructs. For ASSOCIATE, create a new scope for the associated entity. For SELECT TYPE, create a new scope for each of type guard blocks. Each one contains an associated entity with the appropriate type. For SELECT TYPE, also create a place-holder symbol for the associate-name in the SELECT TYPE statement. The real symbols are in the new scopes and none of them is uniquely identified with the associate-name. Handling of `Selector` is common between these, with `associate-name => expr | variable` recorded in `ConstructVisitor::association_`. When the selector is an expression, derive the type of the associated entity from the type of the expression. This required some refactoring of how `DeclTypeSpec`s are created. The `DerivedTypeSpec` that comes from and expression is const so we can only create const `DeclTypeSpec`s from it. But there were times during name resolution when we needed to set type parameters in the current `DeclTypeSpec`. Now the non-const `DerivedTypeSpec` is saved separately from the const `DeclTypeSpec` while we are processing a declaration type spec. This makes it unnecessary to save the derived type name. Add a type alias for `common::Indirection` to reduce verbosity. Original-commit: flang-compiler/f18@b7668cebe49a122ea23c89c81eafdeba243bbfaf Reviewed-on: https://github.com/flang-compiler/f18/pull/261 Tree-same-pre-rewrite: false
2019-01-16 01:59:20 +01:00
ObjectEntityDetails, ProcEntityDetails, AssocEntityDetails,
DerivedTypeDetails, UseDetails, UseErrorDetails, HostAssocDetails,
GenericDetails, ProcBindingDetails, GenericBindingDetails, NamelistDetails,
CommonBlockDetails, FinalProcDetails, TypeParamDetails, MiscDetails>;
std::ostream &operator<<(std::ostream &, const Details &);
[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 &);
[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
class Symbol {
public:
ENUM_CLASS(Flag,
[flang] Continue semantic checking after name resolution error When an error occurs in name resolution, continue semantic processing in order to detect other errors. This means we can no longer assume that every `parser::Name` has a symbol even after name resolution completes. In `RewriteMutator`, only report internal error for unresolved symbol if there have been no fatal errors. Add `Error` flag to `Symbol` to indicate that an error occcurred related to it. Once we report an error about a symbol we should avoid reporting any more to prevent cascading errors. Add `HasError()` and `SetError()` to simplify working with this flag. Change some places that we assume that a `parser::Name` has a non-null symbol. There are probably more. `resolve-names.cc`: Set the `Error` flag when we report a fatal error related to a symbol. (This requires making some symbols non-const.) Remove `CheckScalarIntegerType()` as `ExprChecker` will take care of those constraints if they are expressed in the parse tree. One exception to that is the name in a `ConcurrentControl`. Explicitly perform that check using `EvaluateExpr()` and constraint classes so we get consistent error messages. In expression analysis, when a constraint is violated (like `Scalar<>` or `Integer<>`), reset the wrapped expression so that we don't assume it is valid. A `GenericExprWrapper` holding a std::nullopt indicates error. Change `EnforceTypeConstraint()` to return false when the constraint fails to enable this. check-do-concurrent.cc: Reorganize the Gather*VariableNames functions into one to simplify the task of filtering out unresolved names. Remove `CheckNoDuplicates()` and `CheckNoCollisions()` as those checks is already done in name resolution when the names are added to the scope. Original-commit: flang-compiler/f18@bcdb679405906575f36d3314f17da89e3e89d45c Reviewed-on: https://github.com/flang-compiler/f18/pull/429 Tree-same-pre-rewrite: false
2019-04-25 22:18:33 +02:00
Error, // an error has been reported on this symbol
Function, // symbol is a function
Subroutine, // symbol is a subroutine
Implicit, // symbol is implicitly typed
ModFile, // symbol came from .mod file
[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
ParentComp, // symbol is the "parent component" of an extended type
LocalityLocal, // named in LOCAL locality-spec
LocalityLocalInit, // named in LOCAL_INIT locality-spec
LocalityShared // named in SHARED locality-spec
);
using Flags = common::EnumSet<Flag, Flag_enumSize>;
[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
const Scope &owner() const { return *owner_; }
[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
const SourceName &name() const { return name_; }
Attrs &attrs() { return attrs_; }
[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 Attrs &attrs() const { return attrs_; }
Flags &flags() { return flags_; }
const Flags &flags() const { return flags_; }
bool test(Flag flag) const { return flags_.test(flag); }
void set(Flag flag, bool value = true) { flags_.set(flag, value); }
[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
// The Scope introduced by this symbol, if any.
Scope *scope() { return scope_; }
const Scope *scope() const { return scope_; }
void set_scope(Scope *scope) { scope_ = scope; }
[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
// Does symbol have this type of details?
template<typename D> bool has() const {
return std::holds_alternative<D>(details_);
}
// Return a non-owning pointer to details if it is type D, else nullptr.
template<typename D> D *detailsIf() { return std::get_if<D>(&details_); }
template<typename D> const D *detailsIf() const {
return std::get_if<D>(&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 a reference to the details which must be of type D.
template<typename D> D &get() {
return const_cast<D &>(const_cast<const Symbol *>(this)->get<D>());
[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
}
template<typename D> const D &get() const {
const auto *p{detailsIf<D>()};
CHECK(p != nullptr);
return *p;
[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 &details() { return details_; }
const Details &details() const { return 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
// Assign the details of the symbol from one of the variants.
// Only allowed in certain cases.
void set_details(Details &&);
// Can the details of this symbol be replaced with the given details?
bool CanReplaceDetails(const Details &details) const;
[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
// Follow use-associations to get the ultimate entity.
Symbol &GetUltimate();
const Symbol &GetUltimate() const;
DeclTypeSpec *GetType() {
return const_cast<DeclTypeSpec *>(
const_cast<const Symbol *>(this)->GetType());
}
const DeclTypeSpec *GetType() const {
return std::visit(
common::visitors{
[](const EntityDetails &x) { return x.type(); },
[](const ObjectEntityDetails &x) { return x.type(); },
[](const AssocEntityDetails &x) { return x.type(); },
[](const SubprogramDetails &x) {
return x.isFunction() ? x.result().GetType() : nullptr;
},
[](const ProcEntityDetails &x) {
if (const Symbol * symbol{x.interface().symbol()}) {
return symbol->GetType();
} else {
return x.interface().type();
}
},
[](const TypeParamDetails &x) { return x.type(); },
[](const UseDetails &x) { return x.symbol().GetType(); },
[](const auto &) -> const DeclTypeSpec * { return nullptr; },
},
details_);
}
void SetType(const DeclTypeSpec &);
bool IsDummy() const;
bool IsFuncResult() const;
bool IsObjectArray() const;
bool IsSubprogram() const;
bool IsSeparateModuleProc() const;
[flang] Merge pull request flang-compiler/f18#539 from flang-compiler/tsk1 Check that procedures of a generic are distinguishable Original-commit: flang-compiler/f18@a24701e313019dbf84179b79e234f92d61de0fa6 Reviewed-on: https://github.com/flang-compiler/f18/pull/539 Due to a conflicting rebase during the linearizing of flang-compiler/f18, this commit squashes a number of other commits: flang-compiler/f18@9b1343af36bd27b110f31dab39c3a18a657a5760 Some cleanup in characteristics.{h,cc} flang-compiler/f18@ddb70e53d2b4e2bba12686e4ac3c26052758fcc3 Merge branch 'master' of github.com:flang-compiler/f18 into tsk1 flang-compiler/f18@d1eef9506610a427f992180f6b59cafe09abb9b9 Merge branch 'master' of github.com:flang-compiler/f18 into tsk1 flang-compiler/f18@24a6d3ffbf4d26d92222b27faa155bb5b3f517f4 Make test_folding.sh stricter in test for warnings flang-compiler/f18@c2c5b640604acceb45823de8cb5716d6921da7d4 Replace SymbolList with SymbolVector flang-compiler/f18@c8499584dff12381c2ce6d4718761cd225b4d97a Add CopyAttrs to copy attributes from Symbol flang-compiler/f18@0573ffd8b2ed5757e06a4fc6d5ffc4401e800c32 Replace cascading detailsIf calls with std::visit flang-compiler/f18@28ec62b3ffeec1d25fde330069b050655bb52a5d Add name to characteristics::DummyArgument flang-compiler/f18@568eaf01145d4ee979423d06f2a65d07222f6841 Add name to CopySymbol() flang-compiler/f18@8c557b09e752da205cd300f63b5ca69806fb2e78 Check that procedures of a generic are distinguishable flang-compiler/f18@50515fd987fd5479567e1b497f6ba93974ffde76 Merge branch 'master' of github.com:flang-compiler/f18 into tsk1 flang-compiler/f18@a7963e98a4aedc97784b99903d04cdc48fd4c346 Address review comments flang-compiler/f18@edd65b3962dbaa1121c166d47c90730e39c25a04 Merge branch 'master' of github.com:flang-compiler/f18 into tsk1
2019-07-02 23:00:44 +02:00
bool IsFromModFile() const;
bool HasExplicitInterface() const {
return std::visit(
common::visitors{
[](const SubprogramDetails &) { return true; },
[](const SubprogramNameDetails &) { return true; },
[&](const ProcEntityDetails &x) {
return attrs_.test(Attr::INTRINSIC) || x.HasExplicitInterface();
},
[](const UseDetails &x) {
return x.symbol().HasExplicitInterface();
},
[](const auto &) { return false; },
},
details_);
}
bool operator==(const Symbol &that) const { return this == &that; }
bool operator!=(const Symbol &that) const { return this != &that; }
int Rank() const {
return std::visit(
common::visitors{
[](const SubprogramDetails &sd) {
return sd.isFunction() ? sd.result().Rank() : 0;
},
[](const GenericDetails &) {
return 0; /*TODO*/
},
[](const UseDetails &x) { return x.symbol().Rank(); },
[](const HostAssocDetails &x) { return x.symbol().Rank(); },
[](const ObjectEntityDetails &oed) {
return static_cast<int>(oed.shape().size());
},
[](const AssocEntityDetails &aed) {
if (const auto &expr{aed.expr()}) {
return expr->Rank();
} else {
return 0;
}
},
[](const auto &) { return 0; },
},
details_);
}
int Corank() const {
return std::visit(
common::visitors{
[](const SubprogramDetails &sd) {
return sd.isFunction() ? sd.result().Corank() : 0;
},
[](const GenericDetails &) {
return 0; /*TODO*/
},
[](const UseDetails &x) { return x.symbol().Corank(); },
[](const HostAssocDetails &x) { return x.symbol().Corank(); },
[](const ObjectEntityDetails &oed) {
return static_cast<int>(oed.coshape().size());
},
[](const auto &) { return 0; },
},
details_);
}
// If there is a parent component, return a pointer to its derived type spec.
// The Scope * argument defaults to this->scope_ but should be overridden
// for a parameterized derived type instantiation with the instance's scope.
const DerivedTypeSpec *GetParentTypeSpec(const Scope * = nullptr) const;
[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
private:
[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
const Scope *owner_;
[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
SourceName name_;
Attrs attrs_;
Flags flags_;
[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
Scope *scope_{nullptr};
[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 details_;
[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
Symbol() {} // only created in class Symbols
const std::string GetDetailsName() const;
[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
friend std::ostream &operator<<(std::ostream &, const Symbol &);
friend std::ostream &DumpForUnparse(std::ostream &, const Symbol &, bool);
// If a derived type's symbol refers to an extended derived type,
// return the parent component's symbol. The scope of the derived type
// can be overridden.
const Symbol *GetParentComponent(const Scope * = nullptr) 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
template<std::size_t> friend class Symbols;
template<class, std::size_t> friend struct std::array;
[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 &, Symbol::Flag);
[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
// Manage memory for all symbols. BLOCK_SIZE symbols at a time are allocated.
// Make() returns a reference to the next available one. They are never
// deleted.
template<std::size_t BLOCK_SIZE> class Symbols {
public:
Symbol &Make(const Scope &owner, const SourceName &name, const Attrs &attrs,
Details &&details) {
[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
Symbol &symbol = Get();
symbol.owner_ = &owner;
[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
symbol.name_ = name;
[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
symbol.attrs_ = attrs;
symbol.details_ = std::move(details);
[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 symbol;
}
private:
using blockType = std::array<Symbol, BLOCK_SIZE>;
std::list<blockType *> blocks_;
std::size_t nextIndex_{0};
blockType *currBlock_{nullptr};
Symbol &Get() {
if (nextIndex_ == 0) {
blocks_.push_back(new blockType());
currBlock_ = blocks_.back();
}
Symbol &result = (*currBlock_)[nextIndex_];
if (++nextIndex_ >= BLOCK_SIZE) {
nextIndex_ = 0; // allocate a new block next time
}
return result;
}
};
// Define a few member functions here in the header so that they
// can be used by lib/evaluate without inducing a dependence cycle
// between the two shared libraries.
inline bool ProcEntityDetails::HasExplicitInterface() const {
if (auto *symbol{interface_.symbol()}) {
return symbol->HasExplicitInterface();
}
return false;
}
}
[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
#endif // FORTRAN_SEMANTICS_SYMBOL_H_