ActualArgument was modified in the master branch from
a struct to class. In order to compile once merged, this PR
required the related access paterns to be adapted to match
the new ActualArgument.
As a consequence, this PR does not compile anymore on its own,
it needs to be merged with the master branch to work.
Original-commit: flang-compiler/f18@48cdd2ed0e
Tree-same-pre-rewrite: false
After more reflexion, dynamic loading brings to much uncertainty
regarding which library is actually being use for folding.
It is removed to avoid pushing people to use it.
A static linking to libpgmath will be provided in a later commit.
Original-commit: flang-compiler/f18@2161627d28
Tree-same-pre-rewrite: false
The issue addressed here is the use of cast between object pointers
and function pointers. It is implementation defined because C++,
just like C, does not mandate that function and object pointers
must have the same size.
It is needed to have such cast because it is a will to ba able to
call inside F18 numerical function from libraries linked during
a Fortran program compilation in order to perform folding.
dlopen returns function pointers as void* that need to be cast to
pointer before use.
This change limits the usage of such cast inside ifdefs where POSIX
is required. In POSIX context, such cast is defined. Dlopen is
anyway used only if the environment is POSIX compliant.
In the rest of the code, opaque function pointers have been changed
from void* to void*(*)(). reinterpret_cast from function pointer to
function pointer are standard compliant.
Original-commit: flang-compiler/f18@4b2f29a128
Tree-same-pre-rewrite: false
Commit was: Draft of elemental intrinsics function folding
Simplification was made in order to solve conflicts and
to prepare for commit of host math library indirection.
Conflicts:
lib/evaluate/fold.cc
Original-commit: flang-compiler/f18@45678bc44c
Tree-same-pre-rewrite: false
Parse tree nodes have `source` fields that map the node back to
a range in the cooked input stream. These are used for names and
to locate error messages.
This change strips spaces from the beginning and end of those
source ranges before they are saved. This fixes two problems:
1. For a statement like this: `generic :: operator(+) => ...`,
the name of the symbol we want to create is "operator(+)" but
the parser was including the following space in the CharBlock
it captured.
2. Error messages referring to parts of expressions sometimes included
extra spaces in the source locations. For example:
```
t.f90:9:29: error: subscripts may be applied only to an object or component
integer, parameter :: b = a(1) + 1
^^^^^
t.f90:4:8: error: operands to LOGICAL operation must be LOGICAL
i = j .or. k
^^^^^^^
```
Original-commit: flang-compiler/f18@fa14297967
Reviewed-on: https://github.com/flang-compiler/f18/pull/343
Tree-same-pre-rewrite: false
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@3081f694e2
Reviewed-on: https://github.com/flang-compiler/f18/pull/338
`Semantics::Perform` is mostly a series of calls followed by a check
for fatal errors. There is more error checking logic than real code.
To make it clearer, change each of the phases it calls to return true
on success so that `Perform` can just call them one after the other.
Original-commit: flang-compiler/f18@a218cac788
Reviewed-on: https://github.com/flang-compiler/f18/pull/317
DoConcurrentChecker depends on expressions being fully resolved so it
can't be in the same pass as ExprChecker. The same will probably
apply to AssignmentChecker when its finished.
Checks that don't depend on expressions can go in the first pass
with ExprChecker.
Original-commit: flang-compiler/f18@c0785ec06f
Reviewed-on: https://github.com/flang-compiler/f18/pull/315
Add `SemanticsVisitor` as the visitor class to perform statement
semantics checks. Its template parameters are "checker" classes
that perform the checks. They have `Enter` and `Leave` functions
that are called for the corresponding parse tree nodes (`Enter`
before the children, `Leave` after). Unlike `Pre` and `Post` in
visitors they cannot prevent the parse tree walker from visiting
child nodes.
Existing checks have been incorporated into this framework:
- `ExprChecker` replaces `AnalyzeExpressions()`
- `AssignmentChecker` replaces `AnalyzeAssignments()`
- `DoConcurrentChecker` replaces `CheckDoConcurrentConstraints()`
Adding a new checker requires:
- defining the checker class:
- with BaseChecker as virtual base class
- constructible from `SemanticsContext`
- with Enter/Leave functions for nodes of interest
- add the checker class to the template parameters of `StatementSemantics`
Because these checkers and also `ResolveNamesVisitor` require tracking
the current statement source location, that has been moved into
`SemanticsContext`. `ResolveNamesVisitor` and `SemanticsVisitor`
update the location when `Statement` nodes are encountered, making it
available for error messages.
`AnalyzeKindSelector()` now has access to the current statement through
the context and so no longer needs to have it passed in.
Test `assign01.f90` was added to verify that `AssignmentChecker` is
actually doing something.
Original-commit: flang-compiler/f18@3a222c3673
Reviewed-on: https://github.com/flang-compiler/f18/pull/315
Tree-same-pre-rewrite: false
This showed up in procinterface01. A function can have more than one
PrefixSpec (e.g. `real elemental f()`). We need to ignore that ones
that aren't types.
Also, process the type after the ImplicitPart rather than after the
SpecificationPart. The type of the function result variable could
be accessed between those places.
Original-commit: flang-compiler/f18@df85eedb92
Reviewed-on: https://github.com/flang-compiler/f18/pull/305
A module procedure interface body can access entities in its host
without an IMPORT statement. So the `ImportKind` of the scope created
for such an interface body should be `Default`, not `None` as it is
for other interface bodies.
Original-commit: flang-compiler/f18@24bb2668fd
Reviewed-on: https://github.com/flang-compiler/f18/pull/305
Tree-same-pre-rewrite: false
The `GenericDetails::CheckSpecific()` check was happening too early.
We have to wait until all procedures of the generic have been seen.
The generic can have the same name as a module procedure only if that
module procedure is a specific procedure of the generic.
Improve the `SayAlreadyDeclared` error message when the previous
declaration is a use-association
Original-commit: flang-compiler/f18@269e3db602
Reviewed-on: https://github.com/flang-compiler/f18/pull/305
Tree-same-pre-rewrite: false
When a generic has the same name as a module procedure or derived type,
the latter weren't being written to the `.mod` file. Fix that by calling
`PutSymbol()` on those symbols from the generic. Change `PutSymbol()` to
accept `Symbol *` to make that more convenient.
Original-commit: flang-compiler/f18@1778efe981
Reviewed-on: https://github.com/flang-compiler/f18/pull/305
Tree-same-pre-rewrite: false
When a function-stmt has a type in the prefix (`type(t) function f()`),
the type cannot be resolve until after processing the USE and IMPLICIT
statements. So save the parse-tree of the type and process it at the
end of the specification section.
Add `ProcessTypeSpec()` to handle the process of setting up to walk
a type spec, walking it, restoring the state, and returning the type
spec. We do this several other places too.
Original-commit: flang-compiler/f18@bcde294d0e
Reviewed-on: https://github.com/flang-compiler/f18/pull/305
Tree-same-pre-rewrite: false
A statement entity (`data-i-do-variable` or `ac-do-variable`) that
doesn't have a type specified gets the type it would have in the
enclosing scope. That means if there is a visible variable with the
same name, the statement entity gets its type. We were failing to
do that and just applying the implicit rules.
Original-commit: flang-compiler/f18@72bc7c29ba
Reviewed-on: https://github.com/flang-compiler/f18/pull/305
Tree-same-pre-rewrite: false
If an external subprogram is called and then declared, we have to
replace the `ProcEntityDetails` with `SubprogramDetails` in the symbol.
While doing so we can also check that the call was consistent with the
declaration for function vs. subprogram.
Original-commit: flang-compiler/f18@e43a2dae79
Reviewed-on: https://github.com/flang-compiler/f18/pull/305
Tree-same-pre-rewrite: false
We were setting `expectedProcFlag_` to indicate if a `ProcedureDesignator`
was used in a function or subroutine context. That didn't work if they
were nested, for example: `call f(g())`.
Instead, at the point we know function vs. subroutine (i.e. in the
`CallStmt` and `FunctionReference` nodes), explicitly walk the children,
passing in the flag.
Original-commit: flang-compiler/f18@8a13283f98
Reviewed-on: https://github.com/flang-compiler/f18/pull/305
Tree-same-pre-rewrite: false
Fortran IR is hierarchical: A Program contains Procedures. Procedures
contain Basic Blocks. Groups of Basic Blocks can be grouped as Regions.
This structure follows those one finds in SIL and LLVM IR, etc.
Original-commit: flang-compiler/f18@e2291016df
Reviewed-on: https://github.com/flang-compiler/f18/pull/293
Tree-same-pre-rewrite: false
Moving one of the `Pre(ImplicitStmt)` functions up to
`DeclarationVisitor` seemed to cause clang to complain that the `Pre`
call from the `Walk` function was ambiguous. So this change moves
it back to `ResolveNameVisitor`.
Also, remove an unused variable that was causing a warning.
Original-commit: flang-compiler/f18@766d000e25
Reviewed-on: https://github.com/flang-compiler/f18/pull/299
As with COMMON blocks, we can't completely check SAVE statements and
attributes until the end of the specification part when we have seen
full declarations of entities. So when SAVE is specified, add it to one
of the two sets in `saveInfo_`. At the end of the specification part,
check that those entities can have SAVE applied and set it if it is
not already implicitly set (e.g. due to being in a module). Also apply
the "global" SAVE if present (i.e. setting it on every applicable
entity).
Add `IsDummy()` and `IsFuncResult()` to `Symbol` to simplify some of
the checks. Also detect attempts to put a function result in a common
block.
Original-commit: flang-compiler/f18@af19c02bac
Reviewed-on: https://github.com/flang-compiler/f18/pull/298
The parser can't distinguish `saved-entity -> object-name` from
`saved-entity -> proc-pointer-name`. So just use `kind` == `Entity`
for those cases. Name resolution will verify it is the right kind
of entity name.
Original-commit: flang-compiler/f18@69d7c0e025
Reviewed-on: https://github.com/flang-compiler/f18/pull/298
Tree-same-pre-rewrite: false
Common block names can't clash with other names, so add `commonBlocks_`
to `Scope` to record the common blocks of a scoping unit. This requires
changes to how scopes are dumped and written to `.mod` files.
Support common blocks in BIND statements. Add optional bind-name to
`CommonBlockDetails`.
Add `CheckNotInBlock()` for checking statements that are not allowed in
block constructs.
In `rewrite-parse-tree.cc`, no longer skip check for resolved names in
common statements. But do skip the checks in compiler directives.
Original-commit: flang-compiler/f18@805a1ffd9b
Reviewed-on: https://github.com/flang-compiler/f18/pull/298
Tree-same-pre-rewrite: false
Previously `BIND(C, NAME="...")` caused `bindName` to be set but not
the `BIND` attribute. This made writing the `.mod` file easier, but it
makes it hard to ask: does this symbol have a C binding.
This change causes the `BIND` attribute to be set whenever there is
`BIND(C)` in the source, regardless of whether there is a name or not.
`bindName` is only set when the `BIND` attribute is also set.
Original-commit: flang-compiler/f18@5a6706ffcb
Reviewed-on: https://github.com/flang-compiler/f18/pull/298
Tree-same-pre-rewrite: false
A symbol for a common block has `CommonBlockDetails` which contains
a list of the symbols that are in the common block.
The name of the symbol for the blank common block is the empty string.
That preserves the property that every symbol name is a substring of
the cooked source. We use the 0-length substring starting at the COMMON
statement so that when symbols are sorted by the location of the start
of the name it ends up in the right place.
Some of the checks on members of common blocks don't happen until the
end of the scope. They can't happen earlier because we don't necessarily
know the type and attributes.
Enhance `test_errors.sh` so that multiple errors can be expected for
a single line.
Original-commit: flang-compiler/f18@2c4ca6b5d3
Reviewed-on: https://github.com/flang-compiler/f18/pull/286
The grammar requires parsing the first common block in a common stmt
differently from the others: the '//' is optional for the blank common.
But once it's parsed, it is easier to work with if each is represented
as a `parser::CommonStmt::Block`. This is achieved by using the same
constructor for `CommonStmt` but then including the first block in
the list of blocks.
Original-commit: flang-compiler/f18@dd46afd6b5
Reviewed-on: https://github.com/flang-compiler/f18/pull/284
When an association selector is an expression, we get the type of the
associate-name from the type of the expression. If that is a derived
type, we were failing to get the derived type scope in copy of the
type that was made. That meant the component names were not resolved.
The fix is to copy the scope in the copy and move constructors of
`DerivedTypeSpec`. As a result, `DerivedTypeSpec::Instantiate` cannot
assume that the `scope_` is not set.
Original-commit: flang-compiler/f18@79eaa8c47f
Reviewed-on: https://github.com/flang-compiler/f18/pull/281
Tree-same-pre-rewrite: false
When the kind parameter is a constant name, that name must be resolved.
Add `CheckIntrinsicKind` and `CheckIntrinsicSize` for common checking of
valid intrinsic kinds. Previous we had different forms of the error
message depending on the context ( "unsupported INTEGER(KIND=47)" and
"INTEGER(KIND=47) is not a supported type").
Report error for parameters without initialization where are they
declared (in `Post(EntityDecl)`) rather than where they are referenced
(in `AnalyzeExpr`).
Remove error message from `AnalyzeKindParam`: `AnalyzeExpr` will report
the error (e.g. not integer, not constant, etc.).
Remove "name was not resolved" error from `AnalyzeExpr`: it should be
reported by name resolution.
Original-commit: flang-compiler/f18@9b0a99ce66
Reviewed-on: https://github.com/flang-compiler/f18/pull/281
Tree-same-pre-rewrite: false
Enhance `FindInTypeOrParents()` to also accept a `parser::Name` argument
and to resolve that name when the symbol is found. This causes binding
names in type-bound generic statements to be resolved. Move this process
to the beginning of the handling of such statements so that they are
resolve even if the generic spec is not and we return early.
Also resolve type parameter keywords in derived type specs
(e.g. `k` in `type(k=1) :: x`). That involves collecting and searching
the symbols of the `TypeParamDetails` to match the name with the symbol.
Original-commit: flang-compiler/f18@7387fb436d
Reviewed-on: https://github.com/flang-compiler/f18/pull/281
Tree-same-pre-rewrite: false
Handle variables in data statements differently from implied dos:
If a variable is first mentioned in a data statement, it is implicitly
declared in the current scope (and subsequent type declarations only
confirm the type).
In the implied do case, the only variables that can be implicitly
declared are the iteration variables. They must be created in the new
ImpliedDos scope. There must be one such scope for each data-stmt-object
because the variable name can be reused.
Resolve references to named constants, e.g. in complex-literal-constant
and data-stmt-value. This requires changing the handling of
named-constant-def as that is a definition, not a reference.
Original-commit: flang-compiler/f18@9952b56af0
Reviewed-on: https://github.com/flang-compiler/f18/pull/277
Tree-same-pre-rewrite: false
Namelist groups are represents by symbols with `NamelistDetails`.
Those contain a list of symbols representing the objects in the group.
References to namelist groups in io-control-spec are resolved.
In `.mod` files, namelist groups are written out at the end of the
module specification section. This is so that the declarations of the
objects in the namelist group appear before they are referenced.
Original-commit: flang-compiler/f18@8b70dbcac7
Reviewed-on: https://github.com/flang-compiler/f18/pull/277
Tree-same-pre-rewrite: false
