Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Inconsistent Errors With Regards to Name Validity #102

Closed
philip-alldredge opened this Issue Mar 22, 2018 · 3 comments

Comments

Projects
None yet
2 participants
@philip-alldredge
Copy link
Contributor

philip-alldredge commented Mar 22, 2018

There are a few cases where errors are produces with regards to conflicting names between an implementation and a type. However, the errors seem to be erroneous.

Linearizations

The following example produces an error: "x is already defined in component type contract."

package top
public
	abstract top
		annex agree {**
				linearization new_linearization
(x : real) over [ - 1.0 .. 1.0 ] within 0.01 : x;
**};
	end top;

	abstract implementation top.impl
		annex agree {**
			eq x : bool = true;
		**};
	end top.impl;
end top;

However, this does not produce an error:

package top
public
	abstract top
		annex agree {**
				linearization new_linearization
(x : real) over [ - 1.0 .. 1.0 ] within 0.01 : x;
	
				eq x : bool = true;

**};
	end top;

	abstract implementation top.impl
		annex agree {**
		**};
	end top.impl;
end top;

Record Fields

package top
public
	abstract top
		annex agree {**
			type new_record = struct { field : bool };
		**};
	end top;

	abstract implementation top.impl
		annex agree {**
			type new_impl_record = struct { field : bool };
		**};
	end top.impl;

end top;

Produces "field is already defined in type contract"

While the following does not:

package top
public
	abstract top
		annex agree {**
			type new_record = struct { field : bool };
			type new_impl_record = struct { field : bool };
		**};
	end top;

	abstract implementation top.impl
		annex agree {**
			
		**};
	end top.impl;

end top;

@kfhoech kfhoech self-assigned this Mar 26, 2018

@kfhoech kfhoech added bug AGREE labels Mar 26, 2018

@kfhoech

This comment has been minimized.

Copy link
Contributor

kfhoech commented Mar 26, 2018

Duplicated on develop branch hash bd1b83d.

The problem lies in the AgreeJavaValidator in the checkNameOverlap() method. At lines 1704..1709 names introduced only in node definitions are excluded. This check should exclude, at a minimum, the cases described above.

However, the root of the problem is that the check does not follow the scoping rules given in the AgreeScopeProvider. It would likely be better to refactor this check to use this scope provider instead to automatically keep the rules in synch.

Also the check does not presently consider names that are introduced in package annex libraries.

On second, thought, the Xtext infrastructure already checks for name duplication automatically. Does this check actually add anything? Or, is it merely superfluous and generates spurious errors?

@kfhoech

This comment has been minimized.

Copy link
Contributor

kfhoech commented Mar 27, 2018

After looking into this for a few hours, a proper solution is going to take significant effort.

The following appear to be dead ends:

  • Accessing the scope provider requires access to the EReferences and INodes which are tied to the parser. There's apparently no way back to from the constructed object model.

  • Xtext does make available access to IEObjectDescriptions and QualifiedNames through the ResourceDescriptionProvider. However, these contain name segments separating the package, type and implementation objects into separate spaces. Further, these do not contain the model hierarchy and once the links are followed to the object model find the relations between the types and implementations there is no way back without manually maintaining a maps.

  • OSATE manages the duplication checking by manually building the collection of names in scope through a process that (hopefully) duplicates the manner in which their scope provider works. But, there is no API for annex languages to access this information.

Looks like for now the most expedient way of dealing with this issue is to merely continue excluding names defined within node definitions and add those for linearizations and record fields.

@kfhoech

This comment has been minimized.

Copy link
Contributor

kfhoech commented Mar 27, 2018

Resolved by Pull Request 108.

@kfhoech kfhoech closed this Mar 27, 2018

@kfhoech kfhoech added the v2.3.3 label Jul 11, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.