Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Ajava-based WPI mangles string literals with escapes #5489

Closed
kelloggm opened this issue Jan 3, 2023 · 1 comment · Fixed by #5516
Closed

Ajava-based WPI mangles string literals with escapes #5489

kelloggm opened this issue Jan 3, 2023 · 1 comment · Fixed by #5516
Assignees

Comments

@kelloggm
Copy link
Contributor

kelloggm commented Jan 3, 2023

There is a test case on this branch: https:/kelloggm/checker-framework/tree/ajava-bad-pattern

The problem occurs for any input Java file that contains an escape character. The test case, for example, is the following:

public class ComplexPatternEscape {

  private static final String DOT_DELIMITED_IDS = "";

  // From https:/randoop/randoop/blob/ffed1540721212adc55da179f1ae3b3df582d0d5/agent/replacecall/src/main/java/randoop/instrument/ReplacementFileReader.java#L58
  private static final String SIGNATURE_STRING =
      DOT_DELIMITED_IDS + "(?:\\.<init>)?" + "\\([^)]*\\)";
}

The generated ajava file for e.g., the Value Checker, is the following:

@org.checkerframework.framework.qual.AnnotatedFor("org.checkerframework.common.value.ValueChecker")
public class ComplexPatternEscape {

    private static final @org.checkerframework.common.value.qual.StringVal({ "" }) String DOT_DELIMITED_IDS = "";

    // From https:/randoop/randoop/blob/ffed1540721212adc55da179f1ae3b3df582d0d5/agent/replacecall/src/main/java/randoop/instrument/ReplacementFileReader.java#L58
    private static final @org.checkerframework.common.value.qual.StringVal({ "(?:\\.<init>)?\\([^)]*\\)" }) String SIGNATURE_STRING = DOT_DELIMITED_IDS + "(?:\.<init>)?\([^)]*\)";
}

Note that the string literal itself in the generated .ajava file does not match the corresponding source file: it is missing one backslash. This causes the ajava file not to be parseable: that's an invalid string. Interestingly, the @StringVal annotation has the correct string, which is surprising. I'm not sure why that's happening.

It is not straightforward to work around this problem by modifying the generated ajava file, because escaping all string literals would also destroy the correct @StringVal annotation's argument.

I'm not sure if the problem is in JavaParser or in our internal representation of ajava files, and I'd appreciate some help in figuring it out. @smillst, any ideas what might be causing this?

@mernst
Copy link
Member

mernst commented Jan 5, 2023

This may also be responsible for a warning at https:/mernst/checker-framework/tree/wpi-plumeutil-onlyone .

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants