|
I can't yet test it, but I believe this does not really fix this issue. If I understand correctly, you get a warning that you are doing something that might cause yourself problems, which is great for mostly everbody(but mostly everybody doesn't have this issue anyways). In our case I now that what I'm doing causes me this ambiguity, I know how to handle it and I know as well that there is now way for me to avoid this ambiguity since I cannot rename the variable. Hence, I will probably deactivate this warning for me, since I will get hundreds of new warnings that don't tell me anything new.
The real problem itself is not detected by this marker, that is, you need to use fully-qualified class-names if you want to reference the class instead of the variable. Same applies to getters/setters as well, btw. so what would be the reight Error Highlight?
Type Point have to be full qualified because of field Point? This would probably be the most descriptive and helpful error-message, correctness is being lost somewhere on the line between syntax and semantics. The output of mxmlc is very misleading but nevertheless in some way correct.
To me this looks like a incosistency of your as3-parser with the mxmlc-parser in the name-resolver. If you fix the bug there this will show up as "Could not resolve type reference ..."-error anyways. This would be a correct error message and be in line with mxmlc as well. Hey guys,
In looking at this, I see two fixes here. FDT should have the warning be an error by default. There is also a missing error in this statement: Point = new Point; I'm going to close this ticket because it's been split up into two, more specific, bugs in the parser. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
That shows up if the variable name is same as visible Class name or Function name.
The Error is set on Warning per default.