private void ResolveGhostedCatchParameter(ActivationObject scope, ParameterDeclaration catchParameter)
{
// check to see if the name exists in the outer variable scope.
var ghostField = scope[catchParameter.Name];
if (ghostField == null)
{
// set up a ghost field to keep track of the relationship
ghostField = new JSVariableField(FieldType.GhostCatch, catchParameter.Name);
scope.AddField(ghostField);
}
else if (ghostField.FieldType == FieldType.GhostCatch)
{
// there is, but it's another ghost catch variable. That's fine; just use it.
// don't even flag it as ambiguous because if someone is later referencing the error variable
// used in a couple catch variables, we'll say something then because other browsers will have that
// variable undefined or from an outer scope.
}
else
{
// there is, and it's NOT another ghosted catch variable. Possible naming
// collision in IE -- if an error happens, it will clobber the existing field's value,
// although that MAY be the intention; we don't know for sure. But it IS a cross-
// browser behavior difference.
if (ghostField.OuterField != null)
{
// and to make matters worse, it's actually bound to an OUTER field
// in modern browsers, but will bind to this catch variable in older
// versions of IE! Definitely a cross-browser difference!
// throw a cross-browser issue error.
_errorSink.HandleError(JSError.AmbiguousCatchVar, catchParameter.GetSpan(_locationResolver), _locationResolver);
}
}
// link them so they all keep the same name going forward
// (since they are named the same in the sources)
catchParameter.VariableField.OuterField = ghostField;
}
internal CatchScope(Statement node, ActivationObject parent, ParameterDeclaration catchParameter, ErrorSink errorSink)
: base(node, parent, errorSink)
{
CatchParameter = catchParameter;
}
internal static string MakeParameterName(ParameterDeclaration curParam) {
return curParam.Name;
}
public override bool Walk(ParameterDeclaration node) { AddNode(node); return true; }
public override bool Walk(ParameterDeclaration node)
{
// nothing to do
return(true);
}
public override bool Walk(ParameterDeclaration node)
{
// nothing to do
return true;
}
private void ResolveGhostedCatchParameter(ActivationObject scope, ParameterDeclaration catchParameter)
{
// check to see if the name exists in the outer variable scope.
var ghostField = scope[catchParameter.Name];
if (ghostField == null)
{
// set up a ghost field to keep track of the relationship
ghostField = new JSVariableField(FieldType.GhostCatch, catchParameter.Name);
scope.AddField(ghostField);
}
else if (ghostField.FieldType == FieldType.GhostCatch)
{
// there is, but it's another ghost catch variable. That's fine; just use it.
// don't even flag it as ambiguous because if someone is later referencing the error variable
// used in a couple catch variables, we'll say something then because other browsers will have that
// variable undefined or from an outer scope.
}
else
{
// there is, and it's NOT another ghosted catch variable. Possible naming
// collision in IE -- if an error happens, it will clobber the existing field's value,
// although that MAY be the intention; we don't know for sure. But it IS a cross-
// browser behavior difference.
if (ghostField.OuterField != null)
{
// and to make matters worse, it's actually bound to an OUTER field
// in modern browsers, but will bind to this catch variable in older
// versions of IE! Definitely a cross-browser difference!
// throw a cross-browser issue error.
_errorSink.HandleError(JSError.AmbiguousCatchVar, catchParameter.GetSpan(_locationResolver), _locationResolver);
}
}
// link them so they all keep the same name going forward
// (since they are named the same in the sources)
catchParameter.VariableField.OuterField = ghostField;
}
internal CatchScope(Statement node, ActivationObject parent, ParameterDeclaration catchParameter, ErrorSink errorSink)
: base(node, parent, errorSink)
{
CatchParameter = catchParameter;
}
