improved regexp to also parse error messages with single quotes around header file name

[dennisppaul]

What kind of change does this PR introduce?

this change improves the behavior of function IncludesFinderWithRegExp in detector.go by changing the regexp to also extract a library header file name. even when it is surrounded by single quotes.

background: when working on a board definition that uses the desktop gcc compiler, we found that the error message emitted, which is used to deduce a library header file name, failed to produce the desired result with the current regular expression. the desktop gcc compiler emits the error message surrounding the header file name with single quotes like this:

g++:

... fatal error: 'Foobar.h' file not found
    2 | #include <Foobar.h>

while other compilers, currently used in arduino board definitions, omit the single quotes and therefore can be processed correctly:

avr-g++:

... fatal error: Foobar.h: No such file or directory
 #include <Foobar.h>

arm-none-eabi-g++:

... fatal error: Foobar.h: No such file or directory
    2 | #include <Foobar.h>

riscv32-esp-elf-g++:

... fatal error: Foobar.h: No such file or directory
    2 | #include <Foobar.h>

in order to address this issues we have changed the regular expression to the following:

var includeRegexp = regexp.MustCompile(`(?ms)[<"'](\S+)[">']`)

with this change error messages from all compilers are parsed correctly.

this issues has been encountered with desktop gcc compiler on macOS :

$ gcc --version
Apple clang version 16.0.0 (clang-1600.0.26.6)
Target: arm64-apple-darwin24.1.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin

Does this PR introduce a breaking change, and is titled accordingly?

as far as we know this PR does not introduce a breaking change. however, only four compilers have been tested.

PS the old regexp used to work on macOS until recently. apparently the error message emitted by desktop gcc on macOS has been changed, which broke the arduino header file name detection …

[CLAassistant]

All committers have signed the CLA.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 67.57%. Comparing base (84fc413) to head (c47f78b).
Report is 4 commits behind head on master.

Additional details and impacted files

@@           Coverage Diff           @@
##           master    #2782   +/-   ##
=======================================
  Coverage   67.57%   67.57%           
=======================================
  Files         238      238           
  Lines       22362    22373   +11     
=======================================
+ Hits        15111    15119    +8     
- Misses       6062     6064    +2     
- Partials     1189     1190    +1     

Flag	Coverage Δ
unit	67.57% <ø> (+<0.01%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[cmaglie]

Hi @dennisppaul, thanks for the detailed report.

g++:

... fatal error: 'Foobar.h' file not found
    2 | #include <Foobar.h>

while other compilers, currently used in arduino board definitions, omit the single quotes and therefore can be processed correctly:

Actually, the matching is done on the #include <...> part (the part of the source code that is quoted in the error message) and not in the error message itself, the missing quotes do not affect the result.

https://regex101.com/r/CYmT4J/1

in order to address this issues we have changed the regular expression to the following:

var includeRegexp = regexp.MustCompile(`(?ms)[<"'](\S+)[">']`)

This works but I'm concerned that it will be too broader, and it would match errors that just contains quoted strings like in this example https://regex101.com/r/2rhB6a/1 (look the latest case).

I would just relax the regex a bit to include the missing case, something like:

var includeRegexp = regexp.MustCompile(`(?ms)^\s*[0-9 |]*\s*#[ \t]*include\s*[<"](\S+)[">]`)

https://regex101.com/r/nWPv0h/1

Can you add a couple of test cases in detector_test.go too?

[dennisppaul]

i understand your concern and i do agree, the regexp is too broad. i tried yours, however, the patterns that work in regex101.com does not seem to work in a similar way in go ( interesting! ). i therefore suggest to use a pattern that is not as generic but still works in go as well:

var includeRegexp = regexp.MustCompile(`#include[ \t]*[<"](\S+)[">]`)

i also added a test:

func TestIncludesFinderWithRegExpPaddedIncludes5(t *testing.T) {
	output := "/some/path/sketch.ino:23:42: fatal error: 'Foobar.h' file not found" +
              "   23 | #include \"Foobar.h\"" +
              "      |          ^~~~~~~~~~"

	include := detector.IncludesFinderWithRegExp(output)

	require.Equal(t, "Foobar.h", include)
}