* [OpenMP] Add Sections and Single Construct check
Parse tree for OmpEndSingle needs to be modified to save the provenance
of END SINGLE directive and check its own clauses
* Update on reviews
1. PushContext is created to push new context with source provenance
2. Tweak the logic for SECTION nesting, treak Orphaned or wrong nesting
as the same error type
3. Make sure the check for NOWAIT clause only applies to the ones that
are not handled by parser.
Note that the case for DO or DO_SIMD will take effect after the
loop association work (parse tree change) is done. But I still list
them there for completeness.
4. Happen to find that NOWAIT is not accepted by PARALLEL SECTIONS,
fixed it in the parser.
Original-commit: flang-compiler/f18@236cf1efea
Reviewed-on: https://github.com/flang-compiler/f18/pull/585
When we use-associate a generic interface name and then add more
procedures to the generic, we create a new symbol for the merged
generic. That symbol has to include a pointer to the derived type
or procedure with the same name, just as the original generic did.
To achieve that, change `AddSpecificProcsFrom` to also copy those
fields from the original symbol and change its name to `CopyFrom`
to reflect its new purpose. Also, change it to take `GenericDetails`
instead of `Symbol` as its argument so we can't call it on the wrong
kind of symbol.
Original-commit: flang-compiler/f18@1e22970e43
Reviewed-on: https://github.com/flang-compiler/f18/pull/614
When a generic interface had no specific procedures, we were writing
it the `.mod` file as `generic::g=>`, which is not valid Fortran.
Change to writing generics as interface blocks rather than generic
statements so that this case is handled. Include an access stmt if it
was declared private.
Also fix a bug in `test_errors.sh` where the expected/actual error
messages weren't sorted by line number correctly.
Original-commit: flang-compiler/f18@1c32a289b5
Reviewed-on: https://github.com/flang-compiler/f18/pull/614
Tree-same-pre-rewrite: false
Create symbols for generics in a pre-pass over the specification part so
it is easier to handle cases when they have the same name as a derived
type or subprogram. This is done by calling `PreSpecificationConstruct`
on each `SpecificationConstruct` of a specification part before we
continue walking it. The generics symbols are created there and the same
mechanism will be used to handle forward references to derived types.
Report an error when the same name is used for a generic interface,
derived type, and subprogram.
Improve the error message issued when a procedure and generic interface
have the same name but the procedure is not a specific of the generic.
Change `SayAlreadyDeclared` to report the error on the second occurence
of the name when possible. This can arise for declarations the are
processed out of order, e.g. contained subprograms and generic interfaces.
Avoid multiple "already declared" errors for the case when a contained
subprogram has the same name as a declared entity. We first create the
symbol with SubprogramNameDetails, then replace it with the entity (and
report the error), then replace it with the real subprogram (and get the
error again). By setting and checking the error flag we avoid the second
error.
Original-commit: flang-compiler/f18@48fc076783
Reviewed-on: https://github.com/flang-compiler/f18/pull/614
Tree-same-pre-rewrite: false
It is common to get a pointer, check it is not null, and dereference it.
Sometimes that requires a named temporary just to be able to do the check.
The macro `DEREF(p)` provides this capability: it asserts that `p` is not null
and returns `*p`. This is analagous to `.value()` on an `std::optional`.
We might want to add a way to disable `CHECK` and the check in `DEREF` together.
This change also includes some examples of making use of `DEREF`.
Original-commit: flang-compiler/f18@d7aa90e55a
Reviewed-on: https://github.com/flang-compiler/f18/pull/608
- resolve-names.cc: I reworded the message when a name appears in a
locality-spec when a name is used that cannot appear in a variable
definition context.
- tools.cc: I removed the unused functions ```IsValueDummy()``` and
```IsModifiable()```. I made the function ```GetAssociatedVariable()```
static. I cleaned up the code in ```GetAssociationRoot()```. I cleaned up
the code in ```IsOrContainsEventOrLockComponent()```. I added a TODO to
```WhyNotModifiable()``` and made some other improvements to it.
- tools.h: Removed some deleted and unnecessary functions.
- I fixed up a couple of tests related to the changes in error messages.
Original-commit: flang-compiler/f18@47da8ff9c8
Reviewed-on: https://github.com/flang-compiler/f18/pull/596
- expression.cc - fixed an error message. This required changing the tests
structconst0[3,4].f90
- tools.[h,cc] - Added a new function called ```WhyNotModifiable()``` to see
if a name can be modified. This function returns a string that describes why
the name cannot be modified. I changed the existing function
```IsModifiable()``` to call ```WhyNotModifiable()```. I fixed and
restructured the code for ```GetAssociationRoot()```. This involved creating
the mutually recursive function ```GetAssociatedVariable()```. I added a
check to see if a name is an INTENT(IN) dummy argument to the function
```IsVariableName()```.
- resolve-names.cc - Wrote the function ```SayWithReason()``` that allows an
arbitrary message to be added to an existing message. I changed the code in
```PassesLocalityChecks()``` to call the new function ```WhyNotModifiable()```
to get the specifics of why a variable name cannot be used in a variable
modification context and then call the new function ```SayWithReason()``` to
report the error. I also cleaned up the code as per Jean's suggestion.
Original-commit: flang-compiler/f18@8a2f4bdfd2
Reviewed-on: https://github.com/flang-compiler/f18/pull/596
Tree-same-pre-rewrite: false
Specifically, these changes enforce the last sentence of the constraint, which
prohibits names that cannot appear in a variable definition context from
appearing in a locality-spec. Here are the details.
- Created the function "IsModifiableName" to return "true" when its parameter
is the name of a variable that can appear in a variable definition context.
- Created the function "GetAssociationRoot" to follow construct associations
to potentially get to an underlying variable. This function is similar to
the existing "GetUltimate" function that follows use associations and host
associations. One difference is that "GetAssociationRoot" requires access
to the types "MaybeExpr" and "SomeExpr", which makes is inappropriate to put
into symbol.cc, which is where "GetUltimate" lives. Perhaps we should move
"GetUltimate" to tools.[h,cc].
- Generalized the functions "IsPureFunction" to "IsPureProcedure" since either
a pure function or subroutine can provide a context for variables that
cannot be modified. Changed "FindPureFunctionContaining" to
"FindPureProcedueContaining" to go along with this.
- Added the function "IsExternalInPureContext" to detect the case where a
nominally pure procedure potentially modifies a variable.
- Created the function "IsOrContainsEventOrLockComponent" to detect variables
that either are of EVENT_TYPE or LOCK_TYPE or contain components of these
types. Such variables cannot appear in variable definition contexts.
- Added the test resolve56.f90 to test most of these conditions. Note that I
only tested the new code from the perspective of locality-specs.
Original-commit: flang-compiler/f18@c9d2507b74
Reviewed-on: https://github.com/flang-compiler/f18/pull/596
Tree-same-pre-rewrite: false
When the same generic is use-associated from two different modules,
they must be merged together into a symbol with GenericDetails.
After that merger, if there is a use association of the same name
with a non-generic we have to report an error. So save the UseDetails
from the original USE in GenericDetails so we can create the
appropriate UseErrorDetails.
Fixesflang-compiler/f18#586.
Original-commit: flang-compiler/f18@5067345f70
Reviewed-on: https://github.com/flang-compiler/f18/pull/591
Fix issue 598 and related issues.
Transform resolve-names.cc ConstructVisitor association_ member into a
stack so that different association construct (select-type, select-rank,
change-team, associate) imbrication/succession do not interfere with each
other leading to wrong erronous symbol resolution.
Original-commit: flang-compiler/f18@5781f29ed6
Reviewed-on: https://github.com/flang-compiler/f18/pull/600
Tree-same-pre-rewrite: false
Type-bound generic statements can have binding names that refer to
bindings that occur later in the type. So save a map of generic to
binding names and process them when we get to the end of the
type-bound procedure part. This is similar to how specific procedures
of generic identifiers are handled.
Also detect duplicate binding names for a type-bound generic.
Fixes issue flang-compiler/f18#572.
Original-commit: flang-compiler/f18@d58bb77cfa
Reviewed-on: https://github.com/flang-compiler/f18/pull/577
* The warning was already here, this commit only refactors things so that
it can be controled with -Mstandard.
* Also makes the warning point to the do-stmt and adds a note to the warning
pointing to the statements where it ends.
Original-commit: flang-compiler/f18@11e1eb6edd
Reviewed-on: https://github.com/flang-compiler/f18/pull/552
Tree-same-pre-rewrite: false
- Only allow out-of-scope label target for label-do-stmt
when the label is on an end-stmt of a scope directly nested
into the one of the label-do-stmt.
- Also transform label-do-stmt into non-label-do constructs
so that later phases do not have to handle label-do-stmt.
Original-commit: flang-compiler/f18@91cff2f296
Reviewed-on: https://github.com/flang-compiler/f18/pull/552
Tree-same-pre-rewrite: false
Generic operators and assignment have different rules than generic
names for their procedures being distinguishable.
Implement those rules in `DistinguishableOpOrAssign`. The rules are
considerably simpler: they must have the name number of dummy arguments
and at least one pair in the same position must be distinguishable.
Fixes issue flang-compiler/f18#563.
Original-commit: flang-compiler/f18@276bb08206
Reviewed-on: https://github.com/flang-compiler/f18/pull/576
Complete the checks for distinguishable specifics procedure in a generic
by considering any passed-object dummy arguments.
C1514 rule 3 is implemented and the checks for the other rules are
extended to consider the PASS attribute, including the concept of the
"effective" position of an argument in an argument list, computed by
ignoring passed-object arguments.
Add `pass` to `characteristics::DummyArgument` to mark each
passed-object dummy argument.
Change symbols to store the index of the passed-object dummy argument
rather than its symbol.
Check that specifics of a type-bound generic are distinguishable only
after all of the procedure bindings have been processed. They don't have
to be before the generic.
Original-commit: flang-compiler/f18@2751490f95
Reviewed-on: https://github.com/flang-compiler/f18/pull/567
* Examples of Composite and Combined constructs
2.8.3 Loop SIMD Construct
2.11.1 Parallel Loop Construct
2.11.3 Parallel Loop SIMD Construct
Not in the implementation:
2.8.3 DO SIMD: A list item may appear in a linear or firstprivate clause but not both
Original-commit: flang-compiler/f18@75d9c1a081
Reviewed-on: https://github.com/flang-compiler/f18/pull/558
In `OrderParameterNames` and `OrderParameterDeclarations` it was
always true that `this == &type.get<DerivedTypeDetails>()` which
meant that `this` was redundant.
So convert them to non-member functions in `tools.h` that get the
details from the symbol passed in. This makes life simpler for the
callers.
Original-commit: flang-compiler/f18@81710d4e6e
Reviewed-on: https://github.com/flang-compiler/f18/pull/559
Move these functions from scope.cc, symbol.cc, type.cc into tools.cc:
Scope::FindOrInstantiateDerivedType
Scope::InstantiateDerivedType
Scope::InstantiateIntrinsicType
Symbol::Instantiate
DerivedTypeSpec::ProcessParameterExpressions
DerivedTypeSpec::Instantiate
This eliminates some dependencies in these files on SemanticsContext,
FoldingContext, etc.
It also allows three of the functions to be private to tools.cc
because they are only called from the others.
Original-commit: flang-compiler/f18@48c6efbf95
Reviewed-on: https://github.com/flang-compiler/f18/pull/559
Tree-same-pre-rewrite: false
