Flang has two CMake configurable header files that define compiler
version numbers:
* f18_version.h.in - only used in f18.cpp (uses version numbers from
LLVM's macro definitions)
* Version.inc.in - not currently used (uses version numbers hard-coded
in Flang's top CMake script)
Currently only f18_version.h.in provides version numbers consistent with
other subprojects in llvm-project. However, its location and name are
inconsistent with e.g. Clang. This patch merges the two headers
together:
* hard-coded version numbers in Flang's top CMake script are deleted
* Version.inc.in is updated to provide string versions of version
numbers (required by f18.cpp)
* f18_version.h.in is deleted as it's no longer needed
Differential Revision: https://reviews.llvm.org/D94422
As per Flang's coding guidelines
(flang/docs/C++style.md#error-messages):
```
Messages should start with a capital letter.
```
This patch updates error messages in the driver (new and old) so that
they conform with the guideline above.
This change was suggested in one of the recent reviews:
https://reviews.llvm.org/D93712. It felt like this deserved a dedicated
patch, so sending it separately.
The flang wrapper script that was created as bin/flang in an in-tree
build did not have a correct -intrinsic-module-directory option.
It was correct for out-of-tree builds and for both kinds of installs.
The fix is to pick the correct directory based on what exists.
The script is no longer configured by cmake (just copied) so that
mechanism can be deleted from the cmake file.
Differential Revision: https://reviews.llvm.org/D93496
The "flang" script that gets put into "install/bin" had an absolute path
in it. This precuded moving the install directory to a new location.
Differential Revision: https://reviews.llvm.org/D93131
Update all reference from the specification to the new OpenACC 3.1
document.
Reviewed By: SouraVX
Differential Revision: https://reviews.llvm.org/D92120
Define Fortran derived types that describe the characteristics
of derived types, and instantiations of parameterized derived
types, that are of relevance to the runtime language support
library. Define a suite of corresponding C++ structure types
for the runtime library to use to interpret instances of the
descriptions.
Create instances of these description types in Semantics as
static initializers for compiler-created objects in the scopes
that define or instantiate user derived types.
Delete obsolete code from earlier attempts to package runtime
type information.
Differential Revision: https://reviews.llvm.org/D92802
This patch plugs many holes in static initializer semantics, improves error
messages for default initial values and other component properties in
parameterized derived type instantiations, and cleans up several small
issues noticed during development. We now do proper scalar expansion,
folding, and type, rank, and shape conformance checking for component
default initializers in derived types and PDT instantiations.
The initial values of named constants are now guaranteed to have been folded
when installed in the symbol table, and are no longer folded or
scalar-expanded at each use in expression folding. Semantics documentation
was extended with information about the various kinds of initializations
in Fortran and when each of them are processed in the compiler.
Some necessary concomitant changes have bulked this patch out a bit:
* contextual messages attachments, which are now produced for parameterized
derived type instantiations so that the user can figure out which
instance caused a problem with a component, have been added as part
of ContextualMessages, and their implementation was debugged
* several APIs in evaluate::characteristics was changed so that a FoldingContext
is passed as an argument rather than just its intrinsic procedure table;
this affected client call sites in many files
* new tools in Evaluate/check-expression.cpp to determine when an Expr
actually is a single constant value and to validate a non-pointer
variable initializer or object component default value
* shape conformance checking has additional arguments that control
whether scalar expansion is allowed
* several now-unused functions and data members noticed and removed
* several crashes and bogus errors exposed by testing this new code
were fixed
* a -fdebug-stack-trace option to enable LLVM's stack tracing on
a crash, which might be useful in the future
TL;DR: Initialization processing does more and takes place at the right
times for all of the various kinds of things that can be initialized.
Differential Review: https://reviews.llvm.org/D92783
This option doesn't enable any unique feature/code-patch. Also, it is
neither tested nor documented.
Differential Revision: https://reviews.llvm.org/D91537
These options are in practice passes to the external tool (defined with
F18_FC), i.e. fall into "unrecognised" category. No need to keep them
among other options that are actually parsed.
Under current configuration, the permission of `flang` after installation is 700.
This could bring a problem for system administrators who build and install flang
for other users, which only the user who builds LLVM can execute it, and others
can not. In this patch, the explicit permission setting in the `install` command
is removed, and let CMake determine what perssion to be used like other components.
Reviewed By: DavidTruby
Differential Revision: https://reviews.llvm.org/D87783
The std::string holding the content of a CookedSource no longer
needs to be exposed in its API after the recent work that allows
the parsing context to hold multiple instances of a CookedSource.
So clean the API. These changes were extracted from some work in
progress that was made easier by the API changes.
Differential Revision: https://reviews.llvm.org/D87635
These are owned by an instance of a new class AllCookedSources.
This removes the need for a Scope to own a string containing
a module's cooked source stream, and will enable errors to be
emitted when parsing module files in the future.
Differential Revision: https://reviews.llvm.org/D86891
Fixed some version information in flang/f18:
- fixed the behavior of the -v switch: this flag enables verbosity with used with arguments, but just displays the version when used alone (related to this bug: https://bugs.llvm.org/show_bug.cgi?id=46017)
- added __FLANG, __FLANG_MAJOR__, __FLANG_MINOR__ and __FLANG_PATCHLEVEL__ (similar to their __F18* counterparts) for compatibility purpose
Reviewed By: AlexisPerry, richard.barton.arm, tskeith
Differential Revision: https://reviews.llvm.org/D84334
Fixed some version information in flang/f18:
- fixed the behavior of the -v switch: this flag enables verbosity with used with arguments, but just displays the version when used alone (related to this bug: https://bugs.llvm.org/show_bug.cgi?id=46017)
- added __FLANG, __FLANG_MAJOR__, __FLANG_MINOR__ and __FLANG_PATCHLEVEL__ (similar to their __F18* counterparts) for compatibility purpose
Reviewed By: sscalpone, AlexisPerry, richard.barton.arm, tskeith
Differential Revision: https://reviews.llvm.org/D84334
Add `-fimplicit-none-type-always` to treat each specification-part
like it has `IMPLICIT NONE`. This is helpful for enforcing good Fortran
programming practices. We might consider something similar for
`IMPLICIT NONE(EXTERNAL)` as well.
Add `-fimplicit-none-type-never` to ignore occurrences of `IMPLICIT NONE`
and `IMPLICIT NONE(TYPE)`. This is to handle cases like the one below,
which violates the standard but it accepted by some compilers:
```
subroutine s(a, n)
implicit none
real :: a(n)
integer :: n
end
```
Differential Revision: https://reviews.llvm.org/D85363
Based on https://reviews.llvm.org/D84022 with additional changes to
maintain out-of-tree builds.
Original commit message:
Currently the binaries are output directly into the bin subdirectory of
the build directory. This doesn't work correctly with multi-config
generators which should output the binaries into <CONFIG_NAME>/bin
instead.
The original patch was implemented by David Truby and the additional
changes added here were also proposed by David Truby.
Differential Revision: https://reviews.llvm.org/D85078/
Co-authored-by: David Truby <david.truby@arm.com>
Add a usage string and a defaults section that clarifies:
* If no input files are given, f18 reads from stdin
* If no input files are given, f18 dumps the parse tree.
* The default behaviour is to exec F18_FC.
* The fefault F18_FC setting is 'gfortran'
Adds a simple regression test which tests the top and tail of the help
screen and the exit status.
Depends on D84855
Differential Revision: https://reviews.llvm.org/D84856
When flang is invoked with no files it waits for input on stdin. Make it
print a message saying this to prevent the user being surprised.
Differential Revision: https://reviews.llvm.org/D84855
Summary:
Currently the binaries are output directly into the bin subdirectory of the
build directory. This doesn't work correctly with multi-config generators which
should output the binaries into <CONFIG_NAME>/bin instead.
Reviewers: sscalpone, richard.barton.arm
Subscribers: mgorny, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D84022
Add SetConvert() to the OPEN statement's runtime API.
Add ByteswapOption() to the main program's runtime API.
Check a $FORT_CONVERT environment variable, too, for
a swapping specifier.
Reviewed By: sscalpone
Differential Revision: https://reviews.llvm.org/D84284
Fix fronted shared library builds by eliminating dependences of
the parser on other component libraries, moving some code around that
wasn't in the right library, and making some dependences
explicit in the CMakeLists.txt files. The lowering library
does not yet build as a shared library due to some undefined
names.
Reviewed By: tskeith
Differential Revision: https://reviews.llvm.org/D83515
structure for upstreaming to llvm-project.
These files have had many changes since they were originally upstreamed.
Some of the changes are cosmetic. Most of the functional changes were
done to support the lowering of control-flow syntax from the front-end
parse trees to the FIR dialect.
This patch is meant to be a reviewable size. The functionality it
provides will be used by code yet to be upstreamed in lowering.
review comments:
[review D80449][NFC] make PFT ParentVariant a ReferenceVariant
ReferenceVariant had to be slightly updated to also support
non constant references (which is required for ParentType).
[review D80449] extend Variable implementation beyond a comment
When I tried Solaris builds with `-DBUILD_SHARED_LIBS=ON`, some commands failed
to link:
[ 94%] Linking CXX executable ../../../../bin/f18
Undefined first referenced
symbol in file
Fortran::common::IntrinsicTypeDefaultKinds::set_sizeIntegerKind(int) CMakeFiles/f18.dir/f18.cpp.o (symbol belongs to implicit dependency /var/llvm/local-amd64-release-shared-gcc8-make/lib/libFortranCommon.so.11git)
Fortran::common::IntrinsicTypeDefaultKinds::set_subscriptIntegerKind(int) CMakeFiles/f18.dir/f18.cpp.o (symbol belongs to implicit dependency /var/llvm/local-amd64-release-shared-gcc8-make/lib/libFortranCommon.so.11git)
Fortran::common::EnumIndexToString[abi:cxx11](int, char const*) CMakeFiles/f18.dir/f18.cpp.o (symbol belongs to implicit dependency /var/llvm/local-amd64-release-shared-gcc8-make/lib/libFortranCommon.so.11git)
Fortran::common::IntrinsicTypeDefaultKinds::set_defaultIntegerKind(int) CMakeFiles/f18.dir/f18.cpp.o (symbol belongs to implicit dependency /var/llvm/local-amd64-release-shared-gcc8-make/lib/libFortranCommon.so.11git)
Fortran::common::IntrinsicTypeDefaultKinds::IntrinsicTypeDefaultKinds() CMakeFiles/f18.dir/f18.cpp.o (symbol belongs to implicit dependency /var/llvm/local-amd64-release-shared-gcc8-make/lib/libFortranCommon.so.11git)
Fortran::common::IntrinsicTypeDefaultKinds::set_defaultRealKind(int) CMakeFiles/f18.dir/f18.cpp.o (symbol belongs to implicit dependency /var/llvm/local-amd64-release-shared-gcc8-make/lib/libFortranCommon.so.11git)
ld: fatal: symbol referencing errors
This patch fixes this by adding explicit dependencies on `libFortranCommon`
to the affected commands.
Tested on `amd64-pc-solaris2.11`, `sparcv9-sun-solaris2.11`, and
`x86-64-pc-linux-gnu`.
Differential Revision: https://reviews.llvm.org/D78761
In general all the basic functionality seems to work and removes some redundancy
and more complicated features in favor of borrowing infrastructure from LLVM
build configurations. Here's a quick summary of details and remaining issues:
* Testing has spanned Ubuntu 18.04 & 19.10, CentOS 7, RHEL 8, and
MacOS/darwin. Architectures include x86_64 and Arm. Without
access to Window nothing has been tested there yet.
* As we change file and directory naming schemes (i.e.,
capitalization) some odd things can occur on MacOS systems with
case preserving but not case senstive file system configurations.
Can be painful and certainly something to watch out for as any
any such changes continue.
* Testing infrastructure still needs to be tuned up and worked on.
Note that there do appear to be cases of some tests hanging (on
MacOS in particular). They appear unrelated to the build
process.
* Shared library configurations need testing (and probably fixing).
* Tested both standalone and 'in-mono repo' builds. Changes for
supporting the mono repo builds will require LLVM-level changes that
are straightforward when the time comes.
* The configuration contains a work-around for LLVM's C++ standard mode
passing down into Flang/F18 builds (i.e., LLVM CMake configuration would
force a -std=c++11 flag to show up in command line arguments. The
current configuration removes that automatically and is more strict in
following new CMake guidelines for enforcing C++17 mode across all the
CMake files.
* Cleaned up a lot of repetition in the command line arguments. It
is likely that more work is still needed to both allow for
customization and working around CMake defailts (or those
inherited from LLVM's configuration files). On some platforms agressive
optimization flags (e.g. -O3) can actually break builds due to the inlining
of templates in .cpp source files that then no longer are available for use
cases outside those source files (shows up as link errors). Sticking at -O2
appears to fix this. Currently this CMake configuration forces this in
release mode but at the cost of stomping on any CMake, or user customized,
settings for the release flags.
* Made the lit tests non-source directory dependent where appropriate. This is
done by configuring certain test shell files to refer to the correct paths
whether an in or out of tree build is being performed. These configured
files are output in the build directory. A %B substitution is introduced in
lit to refer to the build directory, mirroring the %S substitution for the
source directory, so that the tests can refer to the configured shell scripts.
Co-authored-by: David Truby <david.truby@arm.com>
Original-commit: flang-compiler/f18@d1c7184159
Reviewed-on: https://github.com/flang-compiler/f18/pull/1045
This patch replaces the occurrence of std::ostream by llvm::raw_ostream.
In LLVM Coding Standards[1] "All new code should use raw_ostream
instead of ostream".[1]
As a consequence, this patch also replaces the use of:
std::stringstream by llvm::raw_string_ostream or llvm::raw_ostream*
std::ofstream by llvm::raw_fd_ostream
std::endl by '\n' and flush()[2]
std::cout by llvm::outs() and
std::cerr by llvm::errs()
It also replaces std::strerro by llvm::sys::StrError** , but NOT in Fortran
runtime libraries
*std::stringstream were replaced by llvm::raw_ostream in all methods that
used std::stringstream as a parameter. Moreover, it removes the pointers to
these streams.
[1]https://llvm.org/docs/CodingStandards.html
[2]https://releases.llvm.org/2.5/docs/CodingStandards.html#ll_avoidendl
Signed-off-by: Caroline Concatto <caroline.concatto@arm.com>
Running clang-format-7
Signed-off-by: Caroline Concatto <caroline.concatto@arm.com>
Removing residue of ostream library
Signed-off-by: Caroline Concatto <caroline.concatto@arm.com>
Original-commit: flang-compiler/f18@a3507d44b8
Reviewed-on: https://github.com/flang-compiler/f18/pull/1047
This re-ordering allows building f18 with shared library using and LLVM build
with static libraries.
This reordering (that also made sens form an alphabetical point of view)
works here to do such "shared+archive" compiling because the current
dependency on LLVM is simple (only one f18 lib + an executable depends on LLVM).
As soon as two f18 libraries will depend on LLVM, one will have to use an LLVM
version built with -DBUILD_SHARED_LIBS=On if one wants to use this option
to compile f18.
Original-commit: flang-compiler/f18@bbbbe9c1aa
Reviewed-on: https://github.com/flang-compiler/f18/pull/994
The Pre-FIR Tree structure is a transient data structure that
is meant to be built from the parse tree just before lowering to
FIR and that will be deleted just afterwards. It is not meant to perfrom
optimization analysis and transformations. It only provides temporary
information, such as label target information or parse tree parent nodes,
that is meant to be used to lower the parse tree structure into
FIR operations.
A PFTBuilder class builds the Pre-Fir Tree from the parse-tree.
A pretty printer is available to visualize this data structure.
- Lit tests are added to:
1. that the PFT tree structure is as expected
2. that the PFT captures all intented nodes
- Cmake changes: Prevent warnings inisde LLVM headers when compiling flang
The issue is that some LLVM headers define functions where the usage of
the parameters depend on environment ifdef. See for instance Size in:
5f940220bf/llvm/include/llvm/Support/Compiler.h (L574)
Because flang is build with -Werror and -Wunused-parameter is default in
clang, this may breaks build in some environments (like with clang9 on macos).
A solution would be to add -Wno-unused-parameter to flang CmakLists.txt,
but it is wished to keep this warning on flang sources for quality purposes.
Fixing LLVM headers is not an easy task and `[[maybe_unused]]` is C++17 and
cannot be used yet in LLVM headers.
Hence, this fix simply silence warnings coming from LLVM headers by telling
CMake they are to be considered as if they were system headers.
- drone.io changes: remove llvm 6.0 from clang config in drone.io and link
flang with libstdc++ instead of libc++
llvm-dev resolved to llvm-6.0 in clang builds on drone.io. llvm 6.0 too old.
LLVM packages are linked with libstdc++ standard library whereas libc++ was
used for flang. This caused link time failure when building clang. Change
frone.io to build flang with libc++.
Note:
This commit does not reflect an actual work log, it is a feature based split of the
changes done in the FIR experimental branch. The related work log can be found in the
commits between:
864898cbe509d032abfe1172ec367dbd3dd92bc1
and
137c23da9c64cf90584cf81fd646053a69e91f63
Other changes come from https://github.com/flang-compiler/f18/pull/959 review.
Original-commit: flang-compiler/f18@edb0943bca
Reviewed-on: https://github.com/flang-compiler/f18/pull/959
Updated CMake files accordingly, using better regex
Updated license headers to match new extension and fit within 80 columns
Updated other comments within files that referred to the old extension
Original-commit: flang-compiler/f18@ae7721e611
Reviewed-on: https://github.com/flang-compiler/f18/pull/958
Have it wrap an optional Assignment so that we can distinguish between
unanalyzed and analyzed with error.
Change analysis of PointerAssignmentStmt to proceed with bounds even
if the DataRef or Expr has an error. Otherwise any bounds expressions
won't be analyzed in that case.
In GetExpr() and GetAssignment() if we get an internal error due to an
unanalyzed expression, dump the parse tree for the expression so we have
some context for the error. They should only be called after the
expression analysis phase. At that point, every expression and assignment
should be analyzed, though some may have resulted in errors(indicated by
returning `nullptr`).
Original-commit: flang-compiler/f18@3b865d7703
Reviewed-on: https://github.com/flang-compiler/f18/pull/944
Tree-same-pre-rewrite: false
back out -Mnolargearray default temporarily
Fix C_F_POINTER(SHAPE=) argument check, it can be any kind of integer
Revert default result kind of SIZE() & al. to standard by default
Remove needless usage of -fdebug-semantics
Original-commit: flang-compiler/f18@57058a5b16
Reviewed-on: https://github.com/flang-compiler/f18/pull/907
Add `typedAssignment` to `PointerAssignmentStmt` parse tree node and
extend `evaluate::Assignment` to include pointer assignment, including
analyzed bounds. Analyze pointer assignments and fill those in.
Emit them in unparsed output and parse tree dump when present.
Change assignment checking to use analyzed expressions and assignments
rather than calling AnalyzeExpr. Check bounds in pointer assignments
for impure function calls in FORALL context.
Add `Fold` convenience function to `ExpressionAnalyzer`.
Original-commit: flang-compiler/f18@140c983423
Reviewed-on: https://github.com/flang-compiler/f18/pull/904
Make compilation of other predefined module files depend on
__fortran_builtins.mod. Currently only iso_c_binding.f90 and
iso_fortran_env.f90 depend on it but others could in the future.
Create the .f18.mod files by copying from the .mod files so that
we don't have to worry about dependencies for those.
Original-commit: flang-compiler/f18@8209ad3d32
Reviewed-on: https://github.com/flang-compiler/f18/pull/899
This changes the license information in many of the flang source files.
- Renamed LICENSE to LICENSE.txt.
- NVIDIA Copyright lines have been removed.
- Initial lines for files follow the LLVM coding convention (file name on the first line; Emacs mode information on the first line).
- License references have been replaced with the abridged LLVM text.
- License information was removed from the test files.
- No file header was placed on test files (these weren't in most LLVM test files).
- License information was added to documentation files where it was missing.
We did not add brief file summaries to the initial line.
See http://llvm.org/docs/DeveloperPolicy.html#new-llvm-project-license-framework
for a description of the new license.
See http://llvm.org/docs/CodingStandards.html#file-headers
for a description of the new LLVM standard file header.
Original-commit: flang-compiler/f18@add6cde724
Reviewed-on: https://github.com/flang-compiler/f18/pull/887
When dumping the parse tree, if there are analyzed expressions,
assignments, or call statements, include the Fortran form of those
in the dump.
This uses the same `AnalyzedObjectsAsFortran` object that unparsing
does so it applies to the same nodes.
We already do something like this for `Name` nodes as well as some
predefined types, so abstract it into an `AsFortran` function which
returns the Fortran source for a node that is to be included in the
dump.
Original-commit: flang-compiler/f18@823b044d2a
Reviewed-on: https://github.com/flang-compiler/f18/pull/878
Tree-same-pre-rewrite: false
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
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
- -fget-definitions finds the definition of the symbol under specified source
position.
- -fget-all-symbols finds definition locations of all symbols in a document. For
symbols found in other modules, shows which module the symbol came from.
- Tests.
- New structure SourcePosition with file, line, column information.
Original-commit: flang-compiler/f18@e0099b0900
Reviewed-on: https://github.com/flang-compiler/f18/pull/698
Tree-same-pre-rewrite: false
so makefiles with "rm *.mod" will still work. Add a
new option to f18, -intrinsic-module-directory, which
supplies a directory in which f18 searches for standard
intrinsic modules. Neither the option nor the path is passed to F18_FC.
Original-commit: flang-compiler/f18@0bbda4c39e
Reviewed-on: https://github.com/flang-compiler/f18/pull/653
Add a script called flang to the bin directory that calls
f18 with the -I option pointing to the module files for the
predefined modules. The wrapper also sets the module suffix
to .fmf to avoid naming conflicts with module files generated
by other compilers. Now, the build creates and installs both
.mod and .fmf files for the predefined module files to
accommodate the flang script.
Original-commit: flang-compiler/f18@b6c30284e7
Reviewed-on: https://github.com/flang-compiler/f18/pull/653
Tree-same-pre-rewrite: false
Change the CMakeFile.txt in tools/f18 to build the predefined modules with the just-built compiler. The mod files are created in the new "include" subdirectory of the binary target directory. The mod files are installed to ${CMAKE_INSTALL_PREFIX}/include.
The f18 driver is already installed in ${CMAKE_INSTALL_PREFIX}/bin. This change change the location of the f18 binary build to a sibling directory of "include" called "bin" instead of at the top level of the binary destination directory. This change is in anticipation of changing the driver to find the include directory using a path relative to the location of f18.
Update the test scripts to find f18 in the bin subdirectory.
Remove the simple predefined module tests from test/semantics because they are compiled as part of the build and don't need to be recompiled as part of a test.
Original-commit: flang-compiler/f18@7811ccecdc
Reviewed-on: https://github.com/flang-compiler/f18/pull/526
more fixes
Access components of constant structures
Apply implicit typing to dummy args used in automatic array dimensions
SELECTED_INT_KIND and SELECTED_REAL_KIND
Finish SELECTED_{INT,REAL}_KIND and common cases of ALL()/ANY()
Original-commit: flang-compiler/f18@e9f8e53e55
Reviewed-on: https://github.com/flang-compiler/f18/pull/472
Tree-same-pre-rewrite: false
Instead of tracking just genericName_ while in a generic interface
block or generic statement, now we immediately create a symbol for it.
A parser::Name isn't good enough because a defined-operator or
defined-io-generic-spec doesn't have a name.
Change the parse tree to add a source field to GenericSpec. Use these
as names for symbols for defined-operator and defined-io-generic-spec
(e.g. "operator(+)" or "read(formatted)").
Change the source for defined-op-name to include the dots so that they
can be distinguished from normal symbols with the same name (e.g. you
can have both ".foo." and "foo"). These symbols have names in the symbol
table like ".foo.", not "operator(.foo.)", because references to them
have that form.
Add GenericKind enum to GenericDetails and GenericBindingDetails.
This allows us to know a symbol is "assignment(=)", for example,
without having to do a string comparison.
Add GenericSpecInfo to handle analyzing the various kinds of
generic-spec and generating symbol names and GenericKind for them.
Add reference to LanguageFeatureControl to SemanticsContext so that
they can be checked during semantics. For this change, if
LogicalAbbreviations is enabled, report an error if the user tries
to define an operator named ".T." or ".F.".
Add resolve-name-utils.cc to hold utility functions and classes that
don't have to be in the ResolveNamesVisitor class hierarchy. The goal
is to reduce the size of resolve-names.cc where possible.
Original-commit: flang-compiler/f18@3081f694e2
Reviewed-on: https://github.com/flang-compiler/f18/pull/338
Andrzej Warzynski