[Patch] Detect invalid MapCSS search expressions

[GerdP]

What steps will reproduce the problem?

1. Create dataset with a highway and a building.
2. Open search dialog in expert mode and type search expression

   *[building] aaa *[highway]
   

3. Note that the input field is marked red. Change aaa to e.g. # or + or - or € (Euro symbol)

What is the expected result?

The input field should always be red and pressing "Start search" should show a popup with
"Search expression is not valid"

What happens instead?

The search field is not marked red, the search finds the building when - or # or € is used,
but not with +.

Please provide any additional information below. Attach a screenshot if possible.

Found this because it also doens't complain when the operators ⊆,⊈,⊇,⊉ are used which were introduced for #10391 with r15102. See also ticket:10391#comment:70

URL:https://josm.openstreetmap.de/svn/trunk
Repository:UUID: 0c6e7542-c601-0410-84e7-c038aed88b3b
Last:Changed Date: 2019-04-28 04:36:41 +0200 (Sun, 28 Apr 2019)
Build-Date:2019-04-28 02:37:58
Revision:15031
Relative:URL: ^/trunk

Identification: JOSM/1.5 (15031 en) Windows 10 64-Bit
OS Build number: Windows 10 Home 1803 (17134)
Memory Usage: 602 MB / 1820 MB (304 MB allocated, but free)
Java version: 1.8.0_201-b09, Oracle Corporation, Java HotSpot(TM) 64-Bit Server VM
Screen: \Display0 1920x1080
Maximum Screen Size: 1920x1080
VM arguments: [-XX:StartFlightRecording=name=MyRecording2,settings=d:\dbg\gerd.jfc, -XX:FlightRecorderOptions=defaultrecording=true,dumponexit=true,dumponexitpath=e:\ld\perf_20190523_074719.jfr]
Dataset consistency test: No problems found

Plugins:
+ OpeningHoursEditor (34977)
+ apache-commons (34908)
+ buildings_tools (34982)
+ continuosDownload (82)
+ ejml (34908)
+ geotools (34908)
+ jaxb (34908)
+ jts (34908)
+ o5m (34908)
+ opendata (34997)
+ pbf (34908)
+ poly (34991)
+ reverter (34999)
+ undelete (34977)
+ utilsplugin2 (34977)

Validator rules:
+ c:\josm\core\data\validator\geometry.mapcss

Last errors/warnings:
- W: No configuration settings found.  Using hardcoded default values for all pools.

[GerdP]

I think the special case with + is caused by the (undocumented) "Sibling" selector. This was introdued with r6927 but seems to be unused by core validator since r10084. No idea if this operator is still in use? Anyway, it is not the root cause for this ticket.

[GerdP]

use trick to trigger parser exception

[GerdP]

Not sure where to fix this. Maybe in method SearchCompiler.compileMapCSS()?
This method calls MapCSSParser.selectors() and that method returns the selector "*[building]". I think we should detect
that there are more tokens in the input stream not yet processed by the parser and when this is the case the search expression is not valid.
Attached patch implements a trick to force a ParseException by adding a declarition to the search string and later checking if this was parsed correctly.

[Don-vip]

I feel this trick should not be needed and the parser should be able to return the list of unprocessed parts, that you can then check for emptiness.

[GerdP]

Please review. I think I found a good solution with 17746-v2.patch.

[Don-vip]

much better :)

[GerdP]

In 15113/josm:

fix #17746: Detect invalid MapCSS search expressions