Hi Greg,
Thanks for digging into this.
Without having dug into it myself, I would like to suggest returning a
type mismatch error of some sort. IIRC, the DuplicateChildTagProblem is
for the following:
<js:initialView>
<local:MyInitialView id="view1" />
</js:initialView>
<js:initialView>
<local:MyInitialView id="view2" />
</js:initialView>
The child tag (js:initialView) is really in there twice.
I believe MXML is supposed to treat more than one child in a child tag as
an array. And thus, the equivalent AS code for:
<js:initialView>
<local:MyInitialView id="view1" />
<local:MyOtherInitialView id="view2" />
</js:initialView>
is:
initialView = [ new MyInitialView, new MyOtherInitialView];
If you code that in AS, you will get an error (I hope), and I think the
compiler should report the same error for this MXML scenario, since
initialView is of type IApplicationView or something like that.
And same for the second scenario:
<js:initialView>
<js:SimpleCSSValuesImpl />
</js:initialView>
Is the equivalent of:
var initialView:IApplicationView = new SimpleCSSValuesImpl().
My 2 cents,
-Alex
On 3/2/17, 9:09 PM, "Greg Dove" <gregd...@apache.org> wrote:
>I have been looking into FLEX-35273 [1].
>
>This is a compiler bug where it is possible to do things that don't make
>sense, like:
>
><js:initialView>
> <local:MyInitialView id="view1" />
> <local:MyInitialView id="view2" />
></js:initialView>
>
>or even this :
>
><js:initialView>
> <js:SimpleCSSValuesImpl />
></js:initialView>
>
>Neither of the above caused compile time errors.
>
>I have a fix for both the above scenarios.
>
>For the first one, I used MXMLDuplicateChildTagProblem which seems 'close
>enough'
>
>"Child tag '${childTag}' bound to namespace '${childNamespace}' is
>already specified for element '${element}'. It will be ignored.";
>
>This renders as :
>Child tag 'MyInitialView' bound to namespace '*' is already specified for
>element 'js:initialView'. It will be ignored.
> <local:MyInitialView id="view2" />
> ^
>
>in the first example above. The text does not feel entirely right, but
>seems close enough. "It will be ignored" sounds more like a warning (as
>opposed to an error/failure), which I think a) it should not be and b) it
>is not.
>
>For the second one, I could not find any relevant 'Problem' class (I may
>have missed one perhaps?) So I just made a new one. I don't really know
>what the rules are here.
>These Problems seem to include an error code so I am unclear what to do
>if I add a new one. i.e. it is not clear what new error code I should
>apply (or even if the error code is important for something).
>For now I just added an arbitrary errorCode = 1999 on
>MXMLBadChildTagPropertyAssignmentProblem.
>
>The new problem renders out to :
>In initializer for 'js:initialView', type
>org.apache.flex.core.SimpleCSSValuesImpl is not assignable to target type
>'org.apache.flex.core.IApplicationView'.
>
>Alex, you may be able to advise here.... are there any rules I need to
>follow for the CompilerProblem classes (in particular, when adding a new
>class).
>
>Assuming all is well above, I will commit this fix tomorrow. I was also
>trying to see if I could figure out how to get checkintests running, but
>I so far I did not. However the regular build tests are all fine with the
>changes I made for this.
>
>
>1. https://issues.apache.org/jira/browse/FLEX-35273
