llvm/flang/test
Tim Keith 3ec5e102e2 [flang] Name resolution for defined operators
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
2019-03-18 11:48:02 -07:00
..
evaluate [flang] More value semantics in Constant<> and GetScalarConstantValue 2019-02-01 13:37:49 -08:00
semantics [flang] Name resolution for defined operators 2019-03-18 11:48:02 -07:00
CMakeLists.txt [flang] Add name resolution tests 2018-06-15 14:54:34 -07:00