ConsString.flattend should not cast to a String but call toString() instead

[jcompagner]

https://github.com/mozilla/rhino/blob/master/src/org/mozilla/javascript/ConsString.java#L78

everywhere in ConsString left, right are CharSequence objects

so it can be that from java when you append code the java method returns a StringBuilder object and that is fine for ConsString for a long time until it wants to flatten then it bombs out with a classcast because we assume all charsequences (left/right) are or a ConsString or a String, but there are more implementations of CharSequnce.

so that code i think should just be changed to:

final String str = next.toString();

to make it a string, if it is a string there is no effect that just returns itself so that is just as fast.

[rbri]

any chance to provide a test case (see org.mozilla.javascript.tests.ConsStringTest)

[jcompagner]

    public void testAppendStringBuilder() {
        ConsString current = new ConsString("a", new StringBuilder("b"));
        current = new ConsString(current, "c");
        current = new ConsString(current, "d");

        assertEquals("abcd", current.toString());

        current = new ConsString("x", new ConsString("a", "b"));
        assertEquals("xab", current.toString());

        current = new ConsString(new ConsString("a", "b"), new ConsString("c", "d"));
        assertEquals("abcd", current.toString());
    }

[rbri]

this was fixed with #1210 - do you use the latest code?

[jcompagner]

ah i was still using our source (and testing against that) and that was build from version 1.7.14 (and i noticed the cast so i didn't look really further because i still saw that same code.
But i guess making sure they are strings in the constructor is even better, because with a string builder you could potentially get weird results (you concat, then adjust the stringbuilder, before you flatten the ConsString)

Edit: and i see now that 1.7.14 is still the latest release so thats i guess why i didn't notice it..