Fix record-in-record bug.

In code with nested class or record declarations, generic arguments used to
establish the concrete type of the containing class should be inherited by the
contained class.

Currently, an attempt to create a variable of a nested type fails with a cryptic
message like:
>>> recordrecord1.chpl:4: error: unresolved call 'R2(y=int, outer=R(int))' [functionResolution.cpp:1599]
because constructors for outer-level types are turned into free functions, but
apparently those for nested types are not.

This patch adjust calls to nested-class constructors, so they appear to be
method calls.  (Eventually, this change will be applied to outer-level
constructors as well.)

With this patch in place, the test cases in users/ferguson/nested work as
expected.

TODO: String comparison with "outer" is somewhat fragile, so this should be
replaced by a flag on the field and/or arg.

*DETAILS

+++ b/compiler/passes/buildDefaultFunctions.cpp
In build_record_copy_function(AggregateType* ct), added a clause to handle the
"outer" arg specially, by inserting the method token at the beginning of the
argument list.  This means that a constructor call containing an argument called
"outer" will be converted into a method call.
In build_record_init_function(AggregateType* ct), we ignore the partial
(generic) type of the outer class or record, and use a field query instead to
obtain the concrete type of the outer class or record during resolution.
When the method token appears in a formal argument list, we pass it positionally
(because resolution cannot deal with a named argument of type _MT).

+++ b/compiler/passes/scopeResolve.cpp
Flag as generic the "outer" arg added by move_constructor_to_outer(FnSymbol*
fn, AggregateType* outerType).

+++ b/compiler/resolution/functionResolution.cpp
In generateConcreteConstructorCall(Type* type), add special handling for calls
to consrtuctors of nested record types.  These constructors must be invoked as
method calls.  Thus, if a generic field named "outer" appears in the argument
list, the method token is added to the head of the argument list.
In fixupRuntimeTypeArguments(CallExpr* call), skip the method token if it is
present.
In flattenAndResolveArgs(CallExpr* call), skip the method token if it is
present.
In resolvePrimInit(CallExpr* call), do not create a call to _defaultOf(type
_MT).  dtAny cannot match dtMethodToken, so there is currently no way to express
_defaultOf(type _MT) in module code.  The added code just short-circuits the
resolution of (init _MT), whose value is therefore internally fixed at "_mt".

+++ b/test/users/ferguson/nested/classrecord1.good
+++ b/test/users/ferguson/nested/recordrecord1.good
The expected value of these two tests was incorrectly given as 7.  The correct
value is zero, because only the generic type arguments are inherited from the
parent class, not runtime values.

--- a/test/users/ferguson/nested/classrecord1.future
--- a/test/users/ferguson/nested/classrecord2.future
--- a/test/users/ferguson/nested/classrecord3.future
--- a/test/users/ferguson/nested/recordrecord1.future
--- a/test/users/ferguson/nested/recordrecord2.future
--- a/test/users/ferguson/nested/recordrecord3.future
These futures were removed, because the corresponding test cases now work correctly.
In build_record_init_function, avoid creation of a temp to hold the method token.

The method token should always be used as a literal.  Without this special test, we get
verification failures on tests in users/ferguson/nested.
Merge pull request #196 from hildeth/fixRecordInRecordBug

Fix record in record bug



This patch provides a workaround for the "record-in-record bug" demonstrated by 6 futures in the users/ferguson/nested directory. The tests were failing due to a mismatch between internally-generated constructor calls and the signature of the constructor for a nested record type. Constructors for top-level record types are "free" functions, while those for nested record types are methods.

The fix was to special-case calls to nested record constructors and make them look like method calls. This resolves the problem, and causes those test cases to exhibit the expected behavior. The corresponding .future files were removed.

This patch is considered a workaround because the signature of the nested record's constructor was left inconsistent with the constructor signature for top-level record declarations. On the other hand, the long-term intention is to convert all constructors back to methods, so using the nested constructors as-is could be considered to be strictly correct.