Skip to content
This repository has been archived by the owner. It is now read-only.

Inconsistent Errors With Regards to Name Validity #102

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

Inconsistent Errors With Regards to Name Validity #102

philip-alldredge opened this issue Mar 22, 2018 · 3 comments
Assignees

Comments

@philip-alldredge
Copy link
Contributor

@philip-alldredge 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
Copy link
Contributor

@kfhoech 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?

Loading

@kfhoech
Copy link
Contributor

@kfhoech 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.

Loading

@kfhoech
Copy link
Contributor

@kfhoech kfhoech commented Mar 27, 2018

Resolved by Pull Request 108.

Loading

@kfhoech kfhoech closed this Mar 27, 2018
@kfhoech kfhoech added the v2.3.3 label Jul 11, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants