infer

The Java tests were compiled with while CI pinned JDK 11. In this case, the bytecode -- and therefore the traces recorded in the files -- depended on the exact binary in use. A contributor running a modern JDK could not regenerate the expected output with without introducing spurious diffs, and >= 9 also warns that leaves the bootstrap class path unset. Move the whole Java pipeline to JDK 21, the current widely deployed LTS and most common choice for new Java projects: bump from 11 to 21 in the and workflows, replace with , which pins the platform API as well as the language level and so produces identical bytecode on any JDK >= 21 (verified: 21 and 23 give byte-identical test output with ), note the new minimum JDK in . The expected output changes in exactly two places: : string concatenation now compiles to rather than /, and >= 21 emits where older versions emitted . No issue is gained or lost. : costs of inner-class constructors and of enum `$VALUES` array is built. All other Java, Kotlin and build-system test directories are unchanged.

Using Infer version on . Tested on MacOS 15.6.1 and could not replicate the issue, so seems to be OS dependent. Could however replicate it on a docker container running Ubuntu. When running infer on a project whose path contains '++' the following error is thrown (this is the full output): This only shows up with two '+' or more. Here is a minimal example to reproduce the error:

Summary Fixes #1941. In , the classes output directory (which defaults to the project root, i.e. the current working directory) is interpolated verbatim into a regex used to parse the output of : Filesystem paths are not regexes. When the path contains a regex metacharacter, fails to compile the expression. The reported failure mode: checking a project out in a directory named (or any path containing ) makes raise , which propagates as an uncaught internal error: Change Quote the path with before embedding it in the regex, so it matches the directory name literally. This is the pattern already used elsewhere in this codebase (, , ). For normal paths without metacharacters the generated regex is unchanged. Verification Root cause confirmed against the real code on : the interpolated path is a user-controlled filesystem path, and the crash site matches the backtrace in the issue exactly. Confirmed the fix is a no-op for plain paths and makes metacharacters literal via . The only other regexes in this function do not interpolate paths; no other occurrence of a path embedded into a regex was found in (the one remaining case, , is by design a user-supplied regex). Test plan inside a directory whose path contains (e.g. ) no longer crashes during Java capture.