Bug 326044

Comment 1 Jan Koehnlein 2010-10-04 04:49:15 EDT

*** Bug 236892 has been marked as a duplicate of this bug. ***

Comment 2 Sebastian Zarnekow 2010-12-15 11:45:15 EST

This didn't make it into M4. Preliminary scheduled for M5.

Comment 3 Jan Koehnlein 2011-01-10 08:37:52 EST

Implemented for Xtype (and thereby for Xbase).

I wouldn't like to do that for common terminals as it could infer some unexpected lexer ambiguities in client grammars, e.g. when they use '$' or some character above \u007f as a separators.

Comment 4 Jan Koehnlein 2011-01-11 09:01:24 EST

Created attachment 186491 [details]
Sample JavaIdentifierIDValueConverter

Reverted, as this change made the guillemots (french quotes) of Xtend2 valid characters of an identifier, thus breaking the syntax. 

This demonstrates that it's not such a good idea to have a tolerant lexer rule with a stricter value converter in a base language, as we cannot predict which kind of symbols inheriting languages are going to use. 

Clients who need all allowed special characters in their identifiers and can rule out that there's a lexical conflict can still have them by overriding the ID rule themselves, e.g. as

terminal ID:
	'^'?('a'..'z'|'A'..'Z'|'_'|'$'|'\u0080'..'\ufffd')
            ('a'..'z'|'A'..'Z'|'_'|'$'|'0'..'9'|'\u0080'..'\ufffd')*;

and binding an IDValueConverter that does the fine checking as the attached one.

Comment 5 Jan Koehnlein 2011-01-11 09:01:45 EST

See comment #4

Comment 6 Karsten Thoms 2017-09-19 17:41:22 EDT

Closing all bugs that were set to RESOLVED before Neon.0

Comment 7 Karsten Thoms 2017-09-19 17:52:30 EDT

Closing all bugs that were set to RESOLVED before Neon.0