search

Martinho0330 / javaparser

Automatically exported from code.google.com/p/javaparser
0 stars 0 forks source link

Wrong interpretation of Unicode number #58

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago 
What steps will reproduce the problem?
1. Create a compilation unit of this code:

switch(c) {
        case '\0':      break;
        case '\u000B':  break;
        case '\b':      break;
        case '\f':      break;
        case '\n':      break;
        case '\r':      break;
        case '\t':      break;
        case '\\':      break;
        case '\"':      break;
        case '\'':      break;
        case '\u2028':  break;
        case '\u2029':  break;
        case '>':       break;
}

2. Use a DumpVisitor to print the result

What is the expected output? What do you see instead?
The expected output is the following:
switch(c) {
        case '\0':      break;
        case '\u000B':  break;
        case '\b':      break;
        case '\f':      break;
        case '\n':      break;
        case '\r':      break;
        case '\t':      break;
        case '\\':      break;
        case '\"':      break;
        case '\'':      break;
        case '\u2028':  break;
        case '\u2029':  break;
        case '>':       break;
}

Actually, Java Parser returns the following code:
switch(c) {
   case '\0':     break;
   case '
':                break;
   case '\b':     break;
   case '\f':     break;
   case '\n':     break;
   case '\r':     break;
   case '\t':     break;
   case '\\':     break;
   case '\"':     break;
   case '\'':     break;
   case '?':      break;
   case '?':      break;
   case '>':      break;
}

What version of the product are you using? On what operating system?
1.0.8

Please provide any additional information below.
Unicode numbers such as \u2028 and \u2029 are interpreted by Java Parser, 
instead of being stored into the AST.

Original issue reported on code.google.com by andreama...@gmail.com on 4 Jul 2012 at 10:12

GoogleCodeExporter commented 9 years ago 
The bug is located into the CharLiteralExpr class.
The getValue() method should return the correct representation.

Original comment by andreama...@gmail.com on 4 Jul 2012 at 7:41

GoogleCodeExporter commented 9 years ago 
A similar problem arises when a string literal contains an Unicode character.

Original comment by andreama...@gmail.com on 5 Jul 2012 at 8:31