Generic name resolution in expression analysis #778

tskeith · 2019-10-09T23:10:13Z

Implement the basics of resolving generic names in expressions.

ExpressionAnalyzer::ResolveGeneric maps the symbol for a generic
name to the specific procedure appropriate for the actual arguments.
Extract CheckExplicitInterface out of CheckArguments so that it
can be tried for each specific procedure of the generic as part of
the test to see which is compatible.

Note that it may be there is an elemental and non-elemental specific
procedure that is compatible with the actual arguments. In that case
the generic is resolved to the non-elemental one.

Test this by using generic functions in specification expressions
that must be written to module files. Verify how the generics were
resolved by looking at the generated .mod files.

There is more work to be done in this area: the passed-object dummy
argument is not considered and in some cases generated module files
are not correct.

klausler

This all looks good. I've been working on these files myself and am in the process of moving them from one directory to another, but it shouldn't be too hard to merge our work together.

lib/evaluate/check-call.cc

lib/semantics/expression.cc

tskeith · 2019-10-09T23:26:22Z

lib/semantics/expression.cc

-                !symbol->owner().sourceRange().Contains(callSite)));
+    return symbol->has<semantics::SubprogramDetails>() &&
+        symbol->owner().IsGlobal() &&
+        !symbol->scope()->sourceRange().Contains(callSite);


I'm not positive this condition is correct. This change fixes some incorrect warnings I was getting when a generic resolved to a specific in another module. symbol->owner() was the module and it did not contain the call site.

psteinfeld

Looks good to me.

jeanPerier

I fail to grasp the differences between some of the checks, but it will probably make more sens when the TODOs in these functions are done. Otherwise looks good to me.

jeanPerier · 2019-10-10T15:59:48Z

lib/semantics/expression.cc

+  for (std::size_t i{0}; i < dummies.size(); ++i) {
+    const characteristics::DummyArgument &dummy{dummies[i]};
+    const std::optional<ActualArgument> &actual{actuals[i]};
+    if (!actual || !CheckCompatibleArgument(isElemental, *actual, dummy)) {


shouldn't this condition allow the actual argument to be absent if the dummy is optional ?

Yes, you're right, the check for actual was backwards. I'll fix this and add a test for this case.

jeanPerier · 2019-10-10T16:20:49Z

lib/semantics/expression.cc

+      FoldingContext localContext{context_.foldingContext(), messages};
+      ActualArguments localActuals{actuals};
+      if (CheckExplicitInterface(*procedure, localActuals, localContext) &&
+          CheckCompatibleArguments(*procedure, localActuals)) {


It is not clear to me why CheckExplicitInterface does not imply CheckCompatibleArguments. CheckExplicitInterfaceArg and CheckCompatibleArgument look very similar. Obviously, if you are doing it, there is a reason. I see that CheckCompatibleArguments seems to deal with elemental aspect when CheckExplicitInterface does not seem to do so.
Could you explain a bit more what is the difference between these two checks ?

The goal here is just to narrow down the specific procedures to the right one, thought it still might not perfectly match the actual arguments. This is just an initial implementation -- it may take more work to get the best error messages from bad calls to generics procedures.

Implement the basics of resolving generic names in expressions. `ExpressionAnalyzer::ResolveGeneric` maps the symbol for a generic name to the specific procedure appropriate for the actual arguments. Extract `CheckExplicitInterface` out of `CheckArguments` so that it can be tried for each specific procedure of the generic as part of the test to see which is compatible. Note that it may be there is an elemental and non-elemental specific procedure that is compatible with the actual arguments. In that case the generic is resolved to the non-elemental one. Test this by using generic functions in specification expressions that must be written to module files. Verify how the generics were resolved by looking at the generated `.mod` files. There is more work to be done in this area: the passed-object dummy argument is not considered and in some cases generated module files are not correct.

Implement the basics of resolving generic names in expressions. `ExpressionAnalyzer::ResolveGeneric` maps the symbol for a generic name to the specific procedure appropriate for the actual arguments. Extract `CheckExplicitInterface` out of `CheckArguments` so that it can be tried for each specific procedure of the generic as part of the test to see which is compatible. Note that it may be there is an elemental and non-elemental specific procedure that is compatible with the actual arguments. In that case the generic is resolved to the non-elemental one. Test this by using generic functions in specification expressions that must be written to module files. Verify how the generics were resolved by looking at the generated `.mod` files. There is more work to be done in this area: the passed-object dummy argument is not considered and in some cases generated module files are not correct. Original-commit: flang-compiler/f18@50e4580 Reviewed-on: flang-compiler/f18#778

…/tsk-generics Generic name resolution in expression analysis Original-commit: flang-compiler/f18@1688bef Reviewed-on: flang-compiler/f18#778

Implement the basics of resolving generic names in expressions. `ExpressionAnalyzer::ResolveGeneric` maps the symbol for a generic name to the specific procedure appropriate for the actual arguments. Extract `CheckExplicitInterface` out of `CheckArguments` so that it can be tried for each specific procedure of the generic as part of the test to see which is compatible. Note that it may be there is an elemental and non-elemental specific procedure that is compatible with the actual arguments. In that case the generic is resolved to the non-elemental one. Test this by using generic functions in specification expressions that must be written to module files. Verify how the generics were resolved by looking at the generated `.mod` files. There is more work to be done in this area: the passed-object dummy argument is not considered and in some cases generated module files are not correct. Original-commit: flang-compiler/f18@50e4580 Reviewed-on: flang-compiler/f18#778

tskeith requested review from jeanPerier, klausler and psteinfeld October 9, 2019 23:10

klausler approved these changes Oct 9, 2019

View reviewed changes

lib/evaluate/check-call.cc Outdated Show resolved Hide resolved

lib/semantics/expression.cc Outdated Show resolved Hide resolved

tskeith commented Oct 9, 2019

View reviewed changes

psteinfeld approved these changes Oct 10, 2019

View reviewed changes

jeanPerier approved these changes Oct 10, 2019

View reviewed changes

tskeith force-pushed the tsk-generics branch from 889f928 to 50e4580 Compare October 10, 2019 18:46

tskeith merged commit 1688bef into master Oct 10, 2019

tskeith deleted the tsk-generics branch October 10, 2019 18:47

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Generic name resolution in expression analysis #778

Generic name resolution in expression analysis #778

tskeith commented Oct 9, 2019

klausler left a comment

tskeith Oct 9, 2019

psteinfeld left a comment

jeanPerier left a comment

jeanPerier Oct 10, 2019

tskeith Oct 10, 2019

jeanPerier Oct 10, 2019

tskeith Oct 10, 2019

Generic name resolution in expression analysis #778

Generic name resolution in expression analysis #778

Conversation

tskeith commented Oct 9, 2019

klausler left a comment

Choose a reason for hiding this comment

tskeith Oct 9, 2019

Choose a reason for hiding this comment

psteinfeld left a comment

Choose a reason for hiding this comment

jeanPerier left a comment

Choose a reason for hiding this comment

jeanPerier Oct 10, 2019

Choose a reason for hiding this comment

tskeith Oct 10, 2019

Choose a reason for hiding this comment

jeanPerier Oct 10, 2019

Choose a reason for hiding this comment

tskeith Oct 10, 2019

Choose a reason for hiding this comment