improved regexp to also parse error messages with single quotes around header file name #2782
Conversation
…d header file name
|
|
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## master #2782 +/- ##
==========================================
+ Coverage 67.57% 67.63% +0.05%
==========================================
Files 238 238
Lines 22362 22392 +30
==========================================
+ Hits 15111 15144 +33
+ Misses 6062 6060 -2
+ Partials 1189 1188 -1
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
There was a problem hiding this comment.
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?
|
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: i also added a test: |
The problem was that in the new unit-test you forgot to add the newlines in the test string (see the fix in my latest pushed commit). I've reverted the regex with my last suggestion and the test PASS. |
What kind of change does this PR introduce?
this change improves the behavior of function
IncludesFinderWithRegExpindetector.goby 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++:while other compilers, currently used in arduino board definitions, omit the single quotes and therefore can be processed correctly:
avr-g++:arm-none-eabi-g++:riscv32-esp-elf-g++:in order to address this issues we have changed the regular expression to the following:
with this change error messages from all compilers are parsed correctly.
this issues has been encountered with desktop gcc compiler on macOS :
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 …