Apex lexer/parser choking on square brackets?

Issue #1021 resolved
Jim Bennett created an issue

Both snippets of code are functionally identical; the only difference is that the first version uses the Double[] syntax instead of List<Double> (and likewise List<Double[]> instead of List<List<Double>> ):

    public static List<Double[]> closedRing(List<Double[]> coordArray)
    {
        List<Double[]> retVal = new List<Double[]>(coordArray);
        Double[] firstPt = coordArray[0];
        Double[] lastPt = coordArray[coordArray.size() - 1];
        Boolean isClosed = (firstPt[0] == lastPt[0]) && (firstPt[1] == lastPt[1]);
        if (!isClosed)
        {
            retVal.add(coordArray[0]);
        }
        return retVal;
    }

    public static List<List<Double>> closedRing(List<List<Double>> coordArray)
    {
        List<List<Double>> retVal = new List<List<Double>>(coordArray);
        List<Double> firstPt = coordArray[0];
        List<Double> lastPt = coordArray[coordArray.size() - 1];
        Boolean isClosed = (firstPt[0] == lastPt[0]) && (firstPt[1] == lastPt[1]);
        if (!isClosed)
        {
            retVal.add(coordArray[0]);
        }
        return retVal;
    }

Both variants will compile in Salesforce, pass the same unit test, and perform as designed.

In the Illuminated Cloud editor, the lines

        Double[] firstPt = coordArray[0];
        Double[] lastPt = coordArray[coordArray.size() - 1];

are marked with red squiggles, and the message "Illegal assignment from Double<Double>> to Double[]. This inspection reports illegal assignments and comparisons as a result of incompatible types." I'm pretty sure that error message is incorrect (given that it compiles, and that Double is not a collection type) and I suspect it's a side effect of the lexer/parser dealing with the square brackets on the coordArray accessor. Substituting

        Double[] firstPt = coordArray.get(0);
        Double[] lastPt = coordArray.get(coordArray.size() - 1);

also makes the red squiggles go away.

Comments (6)

  1. Scott Wells repo owner

    Thanks for filing, Jim and for the standalone reproduction. Looks like a bug with expression type inference that's used for the illegal assignment code inspection. I'll take a look for a near-term upcoming build.

  2. Log in to comment