IntrinsicTypeSpec was used for all intrinsics except for character.
Change it to be a common base class for NumericTypeSpec,
LogicalTypeSpec, and CharacterTypeSpec.
Change DeclTypeSpec to categorize the intrinsics as Numeric, Logical,
and Character. Add some utility methods: AsIntrinsic() and IsNumeric().
In scope.h, give the functions that create DeclTypeSpecs better names.
In semantics.h, replace MakeIntrinsicTypeSpec() with MakeNumericType()
and MakeLogicalType() as it does not apply to character types.
Original-commit: flang-compiler/f18@8ad92d069c
Reviewed-on: https://github.com/flang-compiler/f18/pull/247
Tree-same-pre-rewrite: false
Recognize the various ways of specifying character lengths.
Define CharacterTypeSpec with length and kind and store them in the
current scope, as is done with DerivedTypeSpec (which can also have
length parameters).
Note: IntrinsicTypeSpec is no longer used for characters, so it
should have a different name. Similarly, in DeclTypeSpec::Category,
Intrinsic does not include Character.
Original-commit: flang-compiler/f18@5f84785193
Reviewed-on: https://github.com/flang-compiler/f18/pull/247
Tree-same-pre-rewrite: false
Now DeclTypeSpecs are stored in the scope so that they remain available
as long as the scope exists. DeclTypeSpecs for intrinsic types are
stored in the global scope; those for derived types are in the current
scope. They can contains type parameter values so they can't be reused.
Add `Semantics::MakeIntrinsicTypeSpec` to simplify creating
DeclTypeSpecs for intrinsic types.
Replace `std::optional<DeclTypeSpec>` with `DeclTypeSpec *` as they do
not need to be copied around.
Also fix a small bug with writing `class(t(...))` to the module file --
the type parameters were missing.
Original-commit: flang-compiler/f18@e4744418fc
Reviewed-on: https://github.com/flang-compiler/f18/pull/247
Tree-same-pre-rewrite: false
Type parameters were sorted by the order of the type-param-def-stmts.
But we need to preserve the order of the type-param-name-list.
The is the order of positional parameters in a derived-type-spec.
So add `paramNames` to `DerivedTypeDetails` to preserve the original
order. Using this allows us to write module files with both the
type-param-name-list and type-param-def-stmts in the original order.
Also fix a bug where a duplicate type-param-def caused a spurious
extra error. If `MakeTypeSymbol()` reports an error we should not
call `SetType()` because it will just report another error.
Original-commit: flang-compiler/f18@3ca55b6333
Reviewed-on: https://github.com/flang-compiler/f18/pull/239
It's not good enough to evaluate expressions in the symbol table after
name resolution has completed. This is because we need the values of
constant expressions for types, for example, we need to evaluate `k` in
`integer(k) :: x` to know the type of `x`.
So, eliminate `LazyExpr` and call `EvaluateExpr()` on expressions that
we need in the symbol table. The latter evaluates and folds an
expression in the current context. This is now possible because symbols
are added to `parser::Name` as soon as possible rather than in a pass
after name resolution. Along with `LazyExpr` we can eliminate the whole
`ResolveSymbolExprs` pass that used to resolve them.
In resolve-names.cc, many `Pre` functions are changed to `Post` so that
names are resolved before doing the associated processing. For example,
with intrinsic type specs, names in the kind expression must be resolved
before attempting to evaluate that expression.
In `GetSymbolType()` in type.cc, handle both `ObjectEntityDetails` and
`EntityDetails` by using `Symbol::GetType()`.
Add explicit declarations in label01.F90 because we can't handle
implicitly typed array bounds yet.
Original-commit: flang-compiler/f18@d67716640b
Reviewed-on: https://github.com/flang-compiler/f18/pull/238
We need access to the SemanticsContext and Walk() function everywhere,
so move them to a BaseVisitor, a base class at the root of the class
hierarchy.
Also move MessageHandler to be a data member of BaseVisitor and forward
Say calls to it.
Original-commit: flang-compiler/f18@eb9adc342a
Reviewed-on: https://github.com/flang-compiler/f18/pull/238
Tree-same-pre-rewrite: false
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@5c1a4b99d2
Reviewed-on: https://github.com/flang-compiler/f18/pull/238
Tree-same-pre-rewrite: false
Each Scope now tracks the source locations that it and its nested scopes
span. This is achieved by extending the source range of a scope for each
statement encountered while it is the current scope.
Semantics::FindScope maps a source location (from the cooked character
stream) to the narrowest scope that contains it.
Original-commit: flang-compiler/f18@7b4d2bb113
Reviewed-on: https://github.com/flang-compiler/f18/pull/230
Tree-same-pre-rewrite: false
Including a comma after the last lambda in a `common::visitors{}` list
causes clang-format to do a better job of formatting them.
Add that recommendation to C++style.md, insert the missing commas,
and reformat the changed files.
Original-commit: flang-compiler/f18@a2486ca3b6
Reviewed-on: https://github.com/flang-compiler/f18/pull/232
Add `LazyExpr` class to represent expressions in the symbol table.
Initially they contain a pointer to an expression in the parse tree.
After name resolution is complete and symbols are filled in in the parse
tree, `LazyExpr`s are resolved to `evaluate::Expr<evaluate::SomeType>`.
This is done by `ResolveSymbolExprs()`.
Change `Bound` and `ParamValue` to save their value as a `LazyExpr`.
Change `ObjectEntityDetails` and `TypeParamDetails` to save the initial
value as a `LazyExpr`.
Eliminate `IntExpr` and `IntConst` classes, which were just place-holders.
Add `Clone()` to `ShapeSpec`, `Bound`, `LazyExpr`. Normally they should
be moved but in `ObjectEntityDetails::set_shape()` we need to make copies.
Save type parameter values in `derivedTypeSpec_`. `typeParamValue_` is
not needed.
Write out initial values, type parameter values, and bounds to .mod files.
Evaluate parameter values in expressions.
Make some errors non-fatal so that tests can continue to pass.
Original-commit: flang-compiler/f18@b90cadfc53
Reviewed-on: https://github.com/flang-compiler/f18/pull/223
Tree-same-pre-rewrite: false
We don't need to copy the various Details classes. We will be adding
expressions to some of them (e.g. for bounds or initial values) and they
should generally be moved as well.
In check-do-concurrent.cc, put pointers to Symbols in the symbol
collections rather than copies.
Original-commit: flang-compiler/f18@cdedfc9b3e
Reviewed-on: https://github.com/flang-compiler/f18/pull/223
Tree-same-pre-rewrite: false
When a SeparateModuleSubprogram is encountered, check that there is a
corresponding declaration in the current module/submodule or an ancestor.
When it's the current program unit, special handling is required to
avoid trying to declare it again.
Module subprograms with the `MODULE` prefix are handled similarly.
The `hasModulePrefix` flag is passed in to `BeginSubprogram` to
distinguish this case.
Extract common part of `Post(SubroutineStmt)` and `Post(FunctionStmt)` into
`PostSubprogramStmt`. Add code there to ensure that separate module
procedures do not have `EXTERNAL` set. This requires a fix to `ModFileWriter`
to correctly decide when a subprogram is declared in an interface block.
Extract `WalkSubprogramPart` into a separate function. It walks the
internal or module subprograms collecting their names. It is needed to
handle separate module subprograms.
Original-commit: flang-compiler/f18@339b65f251
Reviewed-on: https://github.com/flang-compiler/f18/pull/218
Tree-same-pre-rewrite: false
If we have `SUBMODULE(m:s1) s2` and `s1` is already in memory (i.e. does
not need to be read from the `m-s1.mod` file), we still need to record
the fact that the name is a reference to that module symbol.
Original-commit: flang-compiler/f18@4bb42ed6a4
Reviewed-on: https://github.com/flang-compiler/f18/pull/218
Tree-same-pre-rewrite: false
Processing a SUBMODULE can cause any number of scopes to be pushed on
the scope stack. We don't know how many to pop at the end, so add
`ClearScopes()` to reset the scope stack to its original state.
Original-commit: flang-compiler/f18@0be4cebd66
Reviewed-on: https://github.com/flang-compiler/f18/pull/218
Tree-same-pre-rewrite: false
`a(i)` is parsed as a function reference and needs to be converted to an
array element reference when `a` is an object entity. That determination
was wrong if the symbol for `a` was a symbol representing host-association
or use-association. In that case we need to get to the original symbol
by calling `GetUltimate()` on the symbol.
This was causing symbol09.f90 to get a compilation error because an
array element reference looked like a call to a non-pure function, which
is prohibited inside a DO CONCURRENT.
Original-commit: flang-compiler/f18@221e6c52c5
Reviewed-on: https://github.com/flang-compiler/f18/pull/216