identification of their index in the dummy argument list,
simplifying their representation, completing the representation
of their actual arguments, and (while I'm here) resolving
calls to type-bound procedures whose bindings are known at
compilation time.
Button up class ActualArgument by making remaining data
members private and adding accessors & mutators.
Original-commit: flang-compiler/f18@5eb60ec419
Reviewed-on: https://github.com/flang-compiler/f18/pull/855
1. Dump negative parts in complex constants without parentheses
(-1., 0.) was dumped as ((-1.), 0.) from f18 expression format.
The latter format is only valid with the complex constructor extension
that is not supported by all compilers.
This commit ensure the former fromat is used in dumps so that dumps can
be used by all fortran compilers. It turns out the parenthesis added
by REAL::AsFortran are not required because operation lowering is
already taking care of this.
2. Dump evaluate::ComplexComponent with REAL/IMAG instead of %RE/%IM
f18 was failing to reparse its own dump in some cases involving
complex expressions like `-z**i`.
The reason was %RE and %IM were used to dump ComplexComponents.
%RE and %IM can only be used on designators but ComplexComponent can
contain arbitrary complex expressions.
Hence, %RE and %IM cannot be used to dump ComplexComponent.
This commit replace them with call to intrinsic function
REAL/IMAG.
Note that this may unfortunatly be unsafe if the user
shadowed REAL or IMAG but I do not see an easy way to solve
this... The current dump is not correct.
Original-commit: flang-compiler/f18@4550a23d0b
Reviewed-on: https://github.com/flang-compiler/f18/pull/851
A symbol that represents a procedure binding is PURE if the procedure
it is bound to is PURE. Fix `IsPureProcedure` to check that.
Make use of `IsPureProcedure` in `CheckSpecificationExprHelper`.
Original-commit: flang-compiler/f18@c95f2eb4fb
Reviewed-on: https://github.com/flang-compiler/f18/pull/849
This is prohibited by Section 11.1.7.4.1, paragraph 1.
Note also that we allow for REAL step expressions. But the check I
added only works for INTEGER step expressions.
I added a function to tools.cc to test to see if an expression is zero,
and I added calls to check-do.cc for regular and CONCURRENT DO
statements to this function. I made the regular DO a warning and the DO
CONCURRENT message an error. I added tests for the DO CONCURRENT case,
including a test that uses an integer constant.
Original-commit: flang-compiler/f18@8c4fadfe00
Reviewed-on: https://github.com/flang-compiler/f18/pull/834
Section 15.4.3.4.2 specifies restrictions on functions that may be used
to implement an "extended-intrinsic-op". These checkw are implemented in
`CheckHelper::CheckDefinedOperator`.
Move `IsIntrinsicRelational` et al. to `semantics/tools.h` so that
the same logic is used to check both dummy and actual arguments.
Fix up tests that had errors that are now detected.
Original-commit: flang-compiler/f18@b900762eed
Reviewed-on: https://github.com/flang-compiler/f18/pull/846
Change expression analysis to do assignment statements as it currently
does call statements. Check there for defined assignment and set
`typedAssignment` in the `AssignmentStmt` node to contain the analyzed
assignment, either intrinsic or user-defined.
When `var = expr` is implemented by subroutine `sub`, the analyzed
assignment contains a procedure reference to `sub(var, (expr))`.
Add `IsDefinedAssignment` to decide based on types and ranks of lhs
and rhs whether is can be a defined assignment. The result is
tri-state because when they are both the same derived type it can
be either intrinsic or defined. Use this where a similar decision
is made in `check-declarations.cc`.
Change "Procedure referenced in PURE subprogram" error message to
contain the name of the procedure. If the reference is from a defined
assignment that name won't appear on the highlighted source line.
Original-commit: flang-compiler/f18@5c87071210
Reviewed-on: https://github.com/flang-compiler/f18/pull/841
Add `typedAssignment` to the `AssignmentStmt` node, analagous to
`typedExpr` in `Expr`. This represents the analyzed form of an assignment.
It may be a subroutine call in the case of a user-defined assignment.
Add `GetAssignment` function to get it from the parse tree node if present.
Original-commit: flang-compiler/f18@675b0b9bb7
Reviewed-on: https://github.com/flang-compiler/f18/pull/841
Tree-same-pre-rewrite: false
Move the code to parenthesize an expression from `ExpressionAnalyzer`
into `evaluate/tools.h` so that it can be used to parenthesize an
`ActualArgument`. This will be needed for defined assignment calls.
Original-commit: flang-compiler/f18@6180d1fb9b
Reviewed-on: https://github.com/flang-compiler/f18/pull/841
Tree-same-pre-rewrite: false
Perform the checks from 15.4.3.4.3 to determine what procedures are
valid to implement defined assignment. This requires characterizing
procedures, so share the result of that with
`CheckSpecificsAreDistinguishable`.
Original-commit: flang-compiler/f18@9e0d79f173
Reviewed-on: https://github.com/flang-compiler/f18/pull/841
Tree-same-pre-rewrite: false
The check that specific procedures of a generic are distinguishable
doesn't need to be done in `resolve-names.cc`. It can be deferred until
`check-declarations.cc` because it only depends on the symbol table.
Make use of `AttachDeclaration` when reporting errors
Refactor checks for different symbol details into separate functions
as they are getting more numerous.
Original-commit: flang-compiler/f18@cd0d6930bb
Reviewed-on: https://github.com/flang-compiler/f18/pull/841
Tree-same-pre-rewrite: false
AttachDeclaration (and so also SayWithDeclaration) don't do anything
when passed a null pointer for the symbol and in all but one place they
are called the symbol can't be null. So change both function to take
`const Symbol &` rather than `const Symbol *`. Change it to handle
procedure bindings as well.
Add `SayWithDeclaration` to `CheckHelper` to simplify calling the one in
`evaluate` and prevent attaching the declaration when it would point at
the same line.
Original-commit: flang-compiler/f18@5f1c2ff663
Reviewed-on: https://github.com/flang-compiler/f18/pull/841
Tree-same-pre-rewrite: false
`GenericDetails` and `GenericBindingDetails` were almost identical:
the former has optional data members to handle the case when a specific
procedure or derived type has the same name as the generic symbol.
Most places they are handled the same way so it simplifies things to
have only one type. In the case where we want to know if it is a generic
binding (e.g. in `mod-file.cc`) we can check the kind of scope that owns
the symbol.
Save name from the generic binding for better location of error messages.
Original-commit: flang-compiler/f18@f65a9edca2
Reviewed-on: https://github.com/flang-compiler/f18/pull/841
Tree-same-pre-rewrite: false
Change GenericKind from an enum class to a variant that includes the
`NumericOperator`, `LogicalOperator`, and `RelationalOperator` from `common`.
This allows for better tests like `IsIntrinsicOperator` (which used to
check for being in a range of the `GenericKind` enumeration) and
simplifies mapping the kind to a string representation.
Original-commit: flang-compiler/f18@c74327c393
Reviewed-on: https://github.com/flang-compiler/f18/pull/841
Tree-same-pre-rewrite: false
This constraint prohibits deallocation of polymorphic entities in a DO
CONCURRENT.
Section 9.7.3.2 specifies the situations that might cause deallocation
of a polymorphic entity. The ones that are applicable to a DO CONCURRENT
are exiting from a block that declares such variables, intrinsic
assignment, and an actual DEALLOCATE statement. This section also
specifies (paragraph 8) that deallocation of a derived type causes
deallocation of all of its allocatable subobjects.
Section 10.2.1.3 specifies what happens during intrinsic assignment.
Paragraph 3 states If the variable is an allocated allocatable variable,
it is deallocated if expr is an array of different shape, any
corresponding length type parameter values of the variable and expr
differ, or the variable is polymorphic and the dynamic type or any
corresponding kind type parameter values of the variable and expr
differ." Thus, an allocatable polymorphic variable on the left hand side
of an assignment statement gets deallocated. Paragraph 13 states that
"For a noncoarray allocatable component the following sequence of
operations is applied.
(1) If the component of the variable is allocated, it is deallocated."
Thus, a variable on the left-hand side of an assignment statement might have noncorray allocatable components. Such components will be deallocated.
Deallocation can be caused by exiting from a block where the entity is
declared, from an assignment, and from direct deallocation.
Original-commit: flang-compiler/f18@7d1932d344
Reviewed-on: https://github.com/flang-compiler/f18/pull/814
peter klausler