Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » TMF (Xtext) » IllegalArgumentException from converter initialization since 2.8.4 (bug 469805)
IllegalArgumentException from converter initialization since 2.8.4 (bug 469805) [message #1708014] Fri, 11 September 2015 13:06 Go to next message
Stephan Herrmann is currently offline Stephan HerrmannFriend
Messages: 1853
Registered: July 2009
Senior Member
Since upgrading to Xtext 2.8.4 one of my DSLs throws at runtime:
org.eclipse.xtext.conversion.impl.AbstractDeclarativeValueConverterService  - Only terminal rules are supported by lexer based converters but got INT which is an instance of ParserRule
java.lang.IllegalArgumentException: Only terminal rules are supported by lexer based converters but got INT which is an instance of ParserRule


I can see that this exception was introduced via https://bugs.eclipse.org/469805 and from reading the bug it seems like a valuable hint, yet I'm unsure what situation exactly should be avoided.

I do have an "anomaly" in my grammar (instead of importing Terminals.xtext):
// don't convert to EInt:
terminal MYINT: '-'? ('0'..'9')+;
// restore original semantics:
INT returns ecore::EInt : MYINT;

owed to the fact that I need integer constants in different contexts: in one rule MYINT is one of several alternatives subsumed by returning EString, whereas in other rules I'm using INT to return EInt.

I have in place a value converter, which overrides assertTokens() so that rule names "INT" and "MYINT" are both accepted (i.e., the same lexer token can be accepted via both rules).

While this was working OK so far, I'd like to understand what dangers the new exception wants to draw my attention to? The bug says "if some AbstractLexerBasedConverter is configures for a datatype rule, currently it fails with weird errors during rule name computation.", which condition I haven't yet observed.

thanks,
Stephan

Re: IllegalArgumentException from converter initialization since 2.8.4 (bug 469805) [message #1708140 is a reply to message #1708014] Mon, 14 September 2015 08:12 Go to previous messageGo to next message
Sebastian Zarnekow is currently offline Sebastian ZarnekowFriend
Messages: 3118
Registered: July 2009
Senior Member
Hi Stephan,

you registered an AbstractLexerBasedConverter for a data type rule,
which is a parser rule. That cannot work thus the exception that is now
raised earlier than later. You may want to implement your own converter
for INT or use the EFactory based default.

Best,
Sebastian
--
Looking for professional support for Xtext, Xtend or Eclipse Modeling?
Find help at http://xtext.itemis.com or xtext(@)itemis.com
Blog: zarnekow.blogspot.com
Twitter: @szarnekow
Google+: https://www.google.com/+SebastianZarnekow
Re: IllegalArgumentException from converter initialization since 2.8.4 (bug 469805) [message #1708211 is a reply to message #1708140] Mon, 14 September 2015 16:17 Go to previous message
Stephan Herrmann is currently offline Stephan HerrmannFriend
Messages: 1853
Registered: July 2009
Senior Member
Hi Sebastian,

Quote:
you registered an AbstractLexerBasedConverter for a data type rule, which is a parser rule. That cannot work ...


"Unfortunately", it works in my tool (seems to). Which simply means, I don't know how to detect if any changes that I would make now are really an improvement.

Quote:
...the exception that is now raised earlier than later ...


Can I force this exception somehow so that I'm able to test the issue?

Quote:
You may want to implement your own converter for INT


Well, I kind-of have that, except that it's one converter for both interpretations of integer tokens:

	public static class MyTerminalConverters extends DefaultTerminalConverters {
		@ValueConverter(rule = "MYINT")
		public IValueConverter<Integer> getMYINTConverter() {
			return new DualINTValueConverter();
		}
		@ValueConverter(rule = "INT")
		public IValueConverter<Integer> getINTConverter() {
			return new DualINTValueConverter();
		}
	}
	// an INT converter that copes with rules "MYINT" as well as "INT": at the lexical level we cannot distinguish!
	static class DualINTValueConverter extends INTValueConverter {
		@Override
		protected void assertTokens(Integer value, TokenSource tokenSource, String escapedString) {
			// copied from AbstractLexerBasedConverter
			if (tokenSource == null)
				return;
			Token token = tokenSource.nextToken();
			if (!escapedString.equals(token.getText())) {
				throw createTokenContentMismatchException(value, escapedString, token);
			}
			// modified: accept for MYINT and INT:
			String tokenRuleName = getRuleName(token);
			if (!"INT".equals(tokenRuleName) && !"MYINT".equals(tokenRuleName)) {
				throw createTokenTypeMismatchException(value, escapedString, token);
			}
			// --
			Integer reparsedValue = toValue(token.getText(), null);
			if (value != reparsedValue && !value.equals(reparsedValue)) {
				throw createTokenContentMismatchException(value, escapedString, token);
			}
		}
	}


I'm aware that this dual interpretation of the same lexical kind is a bit hackish. I'm just curious what bad can happen downstream, so I can test and protect against it.

thanks,
Stephan
Previous Topic:Nested Struct with Qualified Name
Next Topic:Does xtext support native rcp4?
Goto Forum:
  


Current Time: Thu Apr 25 05:28:26 GMT 2024

Powered by FUDForum. Page generated in 0.02766 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top