Generation of @declaredat tags does not handle directories starting with "u"

Issue #319 new
Jesper Mattsson created an issue

When the path to a .jrag contains a directory whose name starts with “u”, then it is in the @declaredat tag replaced with “u0075”. E.g. “util” → “u0075til”.

Comments (4)

  1. Jesper Öqvist

    Thank you for the bug report!

    The issue is probably caused by this attribute:

      public static String ASTNode.escapedFileName(String fileName) {
        return fileName
            .replace("\\\u0075", "\\\u00750075")
            .replace("\\", "\\\\")
            .replace("\"", "\\\"");
      }
    

    From commit 3fbb6a799ebbf5f5552a595323c2472b4ab8c5b2. See the previous unicode escape translation bug (#297).

    It looks like there is an extra “0075” at the end of the first replacement.

  2. Jesper Öqvist

    @Jesper Mattsson I think this is actually working as intended! The text "...\u..." will be interpreted as a unicode escape when the Java code is compiled (even though it is in a comment, see issue #297). This results in a compile error in most cases because the filename starting with u is usually not a valid unicode escape. The extra "0075" makes the text "...\u0075..." get interpreted as "...\u..." during compilation and JavaDoc processing.

    The paths in declaredat comments are based on the system file separator. On Linux systems we don’t get the same issue because “\u” is normally never part of a file path. If this issue is important for you we could probably replace backslashes by forward slashes in all file paths instead.

  3. Jesper Mattsson reporter

    @Jesper Öqvist I figured that was what you were doing, but since the preceding “\” is already escaped, it isn’t required. The compiler is perfectly capable of handling the string “\\u”, interpreting it as an escaped backslash followed by a literal “u”. The problem in #297 is that you didn’t escape the backslashes, there is no need to also escape the “u”. Also, what you generate now is “\\u0075” (i.e. an escaped backslash followed by the literal string “u0075”), not the correct but redundant “\\\u0075” (an escaped backspace followed by an escaped “u”).

    As long as you escape backslashes and non-printable characters, there is no need to do anything special with “u”. You can just delete the first replacement.

  4. Jesper Öqvist

    @Jesper Mattsson Note that .replace("\\\u0075", "\\\u00750075") will actually be compiled as .replace("\\u", "\\u0075")because the Java compiler translates the unicode escapes at compile time. However, it does seem like a nicer solution to just escape all slashes. I can’t really think of a reason not to.

  5. Log in to comment