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
We weren't handling MainProgram with no ProgramStmt correctly in
ProgramTree. When building it we were dereferencing an empty optional.
And in ResolveSpecificationParts we were dereferencing a null pointer.
Original-commit: flang-compiler/f18@1bda90d005
Reviewed-on: https://github.com/flang-compiler/f18/pull/827
Using debug build of f18, `omp-resolve01.f90` sometimes crashed in
`OmpVisitor::ResolveOmpObject`. This was because when the designator was
analyzed it could be rewritten from an `ArrayElement` to a `Substring`.
That made the reference to the `Name` inside the designator no longer
valid so the crash happened when it was referenced later. The fix is to
return when the substring is detected so the name is not referenced.
Also, the name returned from `ResolveDesignator` can but null so it must
be checked.
The crash in `RewriteOpenMPLoopConstruct` happened intermittently on
`omp-loop-association.f90`. It happened when the DO construct was the
last element of the block. In that case `block.erase()` returns an
iterator pointing to `block.end()` which must not be dereferenced.
Original-commit: flang-compiler/f18@3299972d04
Reviewed-on: https://github.com/flang-compiler/f18/pull/824
Update the grammar to handle logical abbreviations (e.g. `.A.` for `.AND.`)
when the feature is enabled. Only support `.X.` when both XOR and
logical abbreviations are enabled.
Fix the driver to enable logical abbreviations with the
`-flogical-abbreviations` option. This was already documented in
`documentation/Extensions.md`.
Remove `parser::Expr::XOR` from the parse tree and immediately map
`.XOR.` to `.NEQV.` if that feature is enabled. This was already being
done during expression analysis anyway.
Add `LanguageFeatureControl::GetNames` to return all of the names of
a logical or relational operator, depending on which features are
enabled. Use these in both name resolution and expression analysis.
Add `Not` to `LogicalOperator` to help in those cases.
Fix handling of BOZ literals: A numeric operation with one real or
integer operand and the other a BOZ literal is intrinsic.
Also, unary plus with a BOZ literal operand is also intrinsic.
Original-commit: flang-compiler/f18@956bd50bc7
Reviewed-on: https://github.com/flang-compiler/f18/pull/815
* Use Extremum<T> FoldOperation to fold MIN and MAX
* Fix Extremum<T> FolOperation
* For character, the length is the one of the longest argument.
Define and use `CharacterUtils<Kind>::Resize` helper to do this.
* For array of all types, Extremum<T> with Ordering::Less was
behaving like Ordering::Greater. This is because the default
`ApplyElementwise` for `Operation` was selected and it then
called the Extremum<T> constructor without the ordering
argument (which was an optional defaulted to Greater).
Define a specific handler for Extremum<T> and make the ordering
argument mandatory to prevent this kind of bug to pass
f18 compilation in the futur.
* Fix intrinsic.cc for MIN and MAX
* When provided with two arguments, `Match` was adding an empty
3rd optional actual argument. Later code working on min and
max was not expecting this and failing. The fix prevent this
empty argument to be created by changing the initial size of
`actualForDummy` to actually be the number of dummies that do
not have `Optionality::Repeats`
This commit fixes issue flang-compiler/f18#677.
Original-commit: flang-compiler/f18@acb62f240b
Reviewed-on: https://github.com/flang-compiler/f18/pull/803
Change `AllFortranNames()` to return a `std::vector` rather than a
`std::initialization_list`. The latter doesn't own its underlying
storage and so can't be returned as a value. clang detects this and
issues a warning.
Two tests in `resolve63.f90` behave differently with clang and require
further investigation.
Original-commit: flang-compiler/f18@1ed3a3cfee
Reviewed-on: https://github.com/flang-compiler/f18/pull/810
Enhance `ArgumentAnalyzer` to do most of the work for this.
For each kind of operator that might have a user-defined form we follow
this process:
- analyze the arguments
- if the types and shapes match the intrinsic operator do the usual
processing
- otherwise attempt to interpret it as a user-defined operator with
`TryDefinedOp`
When we fail to resolve an operator, produce different errors depending
on whether there is a user-defined operator available or not.
If there is, report that neither user-defined nor intrinsic operator
worked. If there is not, describe the rules for the intrinsic operator.
In either case, include the type(s) of the operand(s).
Most of the uses of `ArgumentAnalyzer` are in helper functions that
apply to classes of operators.
For consistency, rename `BinaryOperationHelper` to `NumericBinaryOperator`
and `LogicalHelper` to `LogicalBinaryHelper` and introduce `NumericUnaryHelper`
for unary `+` and `-`. `.NOT.` and `//` are not implemented in helpers.
Replace `success_` with `fatalErrors_` in `ArgumentAnalyzer` for
consistency with `ExpressionAnalyzer`.
Add `NumericOperator` and `LogicalOperator` enums to `Fortran.h` to go
with `RelationalOperator`. Add `AddFortran` functions to each to convert
to a Fortran source string. `RelationalOperator` also has `AllFortranNames`
because there are multiple names for each operator. This replaces
`LogicalOperator` in `expression.h` and the string representation of
the operators in `formatting.cc`.
Original-commit: flang-compiler/f18@3bb9d664e8
Reviewed-on: https://github.com/flang-compiler/f18/pull/807
