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
