- CFI_CDESC_T can now be cast to CFI_cdesc_t without using
reinterpret_cast.
- Use {} initialization everywhere according to style guideline
- Avoid useless parentheses
- Do not use static storage when useless in tests.
- Reodered some loops that were confusing in tests
Original-commit: flang-compiler/f18@d0ed631dfd
Reviewed-on: https://github.com/flang-compiler/f18/pull/227
Tree-same-pre-rewrite: false
remove needless template<> on some function overloads
dodge bogus compiler warning from gcc 8.1.0 only
stricter typing of expressions in symbols
adjust modfile12.f90 expected test results
add Unwrap, massage folding a bit
Use Unwrap to simplify folding
Move KindSelector analysis into expression semantics
fix crash
checkpoint
updates to TypeParamInquiry
support of %KIND type parameter inquiry
equality testing for expressions
checkpoint during PDT implementation
reformat
checkpoint derived type instantiation
checkpoint
resolve merge
debugging failed tests
fix failing resolve37.f90 test
all existing tests pass
clean up all build warnings
fix bug
update copyright dates
fix copyright dates
address review comments
review comment
merge with master after peeling off changes
bugfixing new feature
fix warning from old g++s
tweaks after merging with latest head
more bugfixing
making modfile17.f90 test work
Make kinds into expressions in symbol table types
big refactor for deferring kinds in intrinsic types
modfile17.f90 test passes
clean up TODOs
Simplify types as stored in scopes
Test KIND parameter default init expressions, debug them
Update copyright dates
address comments
remove dead line
address comments
Original-commit: flang-compiler/f18@1f43d0a048
Reviewed-on: https://github.com/flang-compiler/f18/pull/260
Tree-same-pre-rewrite: false
We need to be able to analyze the `Variable` in a `Selector` and an
expression. That worked in a previous iteration of `expression.h` by
analyzing each variant of `Variable`.
This fix adds an explicit public function to analyze a Variable and
return a `MaybeExpr`.
Original-commit: flang-compiler/f18@9848a5d48f
Reviewed-on: https://github.com/flang-compiler/f18/pull/262
Create `AssocEntityDetails` for symbols that represent entities
identified by the associate-name in ASSOCIATE and SELECT TYPE
constructs.
For ASSOCIATE, create a new scope for the associated entity.
For SELECT TYPE, create a new scope for each of type guard blocks.
Each one contains an associated entity with the appropriate type.
For SELECT TYPE, also create a place-holder symbol for the
associate-name in the SELECT TYPE statement. The real symbols
are in the new scopes and none of them is uniquely identified
with the associate-name.
Handling of `Selector` is common between these, with
`associate-name => expr | variable` recorded in
`ConstructVisitor::association_`.
When the selector is an expression, derive the type of the associated
entity from the type of the expression. This required some refactoring
of how `DeclTypeSpec`s are created. The `DerivedTypeSpec` that comes
from and expression is const so we can only create const `DeclTypeSpec`s
from it. But there were times during name resolution when we needed to
set type parameters in the current `DeclTypeSpec`. Now the non-const
`DerivedTypeSpec` is saved separately from the const `DeclTypeSpec`
while we are processing a declaration type spec. This makes it
unnecessary to save the derived type name.
Add a type alias for `common::Indirection` to reduce verbosity.
Original-commit: flang-compiler/f18@b7668cebe4
Reviewed-on: https://github.com/flang-compiler/f18/pull/261
Tree-same-pre-rewrite: false
A `part-ref` can be `%kind` on an entity of any intrinsic type or
`%len` on a character entity. During name resolution, recognize these
and don't report an error as if they are component references.
Create symbols for these names as well as `%re` and `%im`. This is
partly for completeness so that we don't get warnings about unresolve
names. It also allows us to avoid having to do string comparisons on
these names in more than one place.
Rework `AnalyzeExpr` on structure components to make use of these
symbols and also not treat `%kind` and `%len` as derived type component
references.
Original-commit: flang-compiler/f18@65ae81ebac
Reviewed-on: https://github.com/flang-compiler/f18/pull/256
If we fail to evaluate the kind expression we were getting an invalid
optional reference. Instead, fail with an assert. This can happen if an
intrinsic function is not folded, but that will be implemented
eventually.
Original-commit: flang-compiler/f18@3bdbfc34bb
Reviewed-on: https://github.com/flang-compiler/f18/pull/256
Tree-same-pre-rewrite: false
These are recognized along with other attributes and saved in
`passName_` and `bindName_`. The functions `SetPassNameOn()` and
`SetBindNameOn()` set them in a symbol if they are present.
They are also written to `.mod` files.
Add `MakePlaceholder()` to make symbols for names that otherwise
wouldn't have one. This allows us to assign a symbol to every name
and report errors for those that don't have one. Make use of this
for PASS names, which don't have explicit symbols.
Change `ObjectEntityDetails` and `ProcEntityDetails` to be sub-classes
of `EntityDetails`. They each contain a superset of the information in
`EntityDetails` so this reduces some duplication.
Original-commit: flang-compiler/f18@404c920840
Reviewed-on: https://github.com/flang-compiler/f18/pull/256
Tree-same-pre-rewrite: false
of ExpressionBase::derived(). gcc-8.2 on macOS was choosing to create
non-inline instances of derived() during the explicit instantiations of
ExpressionBase in expression.cc and fold.cc. During linking of any
executable, the linker failed when it found these duplicate definitions.
While this solution works, it removes the opportunity to inline the trivial
derived() functions. Another solution would be to make all of the
templates related to ExpressionBase in expression.cc and fold.cc available
in a single .cc file, where the explicit instantiation
FOR_EACH_TYPE_AND_KIND(template class ExpressionBase) is done once. This
approach would allow inlining, but require something like template
implementation headers that could be included into the instantiation .cc
file.
Original-commit: flang-compiler/f18@074de39418
Reviewed-on: https://github.com/flang-compiler/f18/pull/248
Tree-same-pre-rewrite: false