🐛 Emit absolute #line paths in generated Partials to fix Windows gcov misattribution

Some GCC/mingw-w64 builds corrupt gcov's --json-format line attribution for
#line-remapped source when given a relative path compiled from a sufficiently
long/deep working directory, silently misattributing coverage hits to the
wrong line (observed on Windows CI). Absolute #line paths sidestep the buggy
resolution step entirely; gcovr's own --root handling relativizes them back
to clean paths in reports, so there's no user-visible change to output.

Reverts the GCC 14 pin added to Windows CI as an earlier, now-disproven fix
attempt -- the real defect isn't compiler-version-specific.

Author: mkarlesky

.github/workflows/ci.yml

@@ -198,17 +198,6 @@ jobs:
         with:
           ruby: ${{ matrix.ruby }}
 
-      # Pin Windows CI to a stable GCC 14 release instead of the MSYS2/ridk-bundled
-      # toolchain's rolling ucrt64 gcc package (drifts forward automatically -- was
-      # observed at 16.1.0 and mis-attributing gcov coverage lines for #line-remapped
-      # Partials source with blank lines).
-      - name: Install Pinned GCC 14 Toolchain (winlibs)
-        shell: powershell
-        run: |
-          Invoke-WebRequest -Uri "https://github.com/brechtsanders/winlibs_mingw/releases/download/14.2.0posix-19.1.1-12.0.0-ucrt-r2/winlibs-x86_64-posix-seh-gcc-14.2.0-mingw-w64ucrt-12.0.0-r2.zip" -OutFile winlibs-gcc14.zip
-          Expand-Archive -Path winlibs-gcc14.zip -DestinationPath "$env:RUNNER_TEMP\winlibs-gcc14"
-          echo "$env:RUNNER_TEMP\winlibs-gcc14\mingw64\bin" >> $env:GITHUB_PATH
-
       # Install Gem Dependencies
       - name: Install Gem Dependencies
         # Ensure local installation to prevent system directory permission problems

lib/ceedling/generators/generator_partials.rb

@@ -149,7 +149,24 @@ def generate_source(io, includes, function_definitions, c_module)
       # Blank line before a function when preceded by a non-function item
       io << "\n" if anything_emitted && !last_was_func
       if func.line_num and func.source_filepath
-        io << "#line #{func.line_num} \"#{func.source_filepath}\"\n"
+        # #line is the only thing tying this generated file's code back to its
+        # original source location -- it's what makes debuggers, error messages, and
+        # (critically) gcov coverage attribution point at the real file/line instead
+        # of this generated stand-in. That mapping has to be unambiguous: a relative
+        # path forces every downstream consumer to first resolve it against whatever
+        # working directory *it* believes was in effect, and any mismatch or bug in
+        # that resolution silently corrupts the mapping instead of failing loudly.
+        # An absolute path removes that resolution step entirely.
+        #
+        # This isn't theoretical: some GCC/mingw-w64 builds corrupt gcov's
+        # --json-format line attribution for #line-remapped source when given a
+        # relative path compiled from a sufficiently long/deep working directory
+        # (observed on Windows CI -- correct source line misattributed to a line
+        # deep in trailing comments). Absolute paths here sidestep that resolution
+        # step and the bug with it. gcovr's own `--root` handling relativizes
+        # absolute paths back down to clean relative ones in reports, so this has no
+        # user-visible effect on report output.
+        io << "#line #{func.line_num} \"#{File.expand_path(func.source_filepath)}\"\n"
       end
       io << func.code_block << "\n\n"
       emitted_funcs[func.name] = true

spec/units/generators/generator_partials_spec.rb

@@ -602,16 +602,20 @@ def empty_module
       expect( buf.string.strip() ).to eq file_contents.strip()
     end
 
-    it "should generate a source file with functions and #line directives" do
+    it "should generate a source file with functions and #line directives using absolute source paths" do
+      # Absolute paths sidestep a GCC/mingw-w64 gcov --json-format line-attribution bug
+      # triggered by relative #line paths compiled from a sufficiently long/deep working
+      # directory (observed on Windows CI). gcovr's own --root handling relativizes these
+      # back to clean paths in reports, so this has no user-visible effect on output.
       file_contents = <<~CONTENTS
       // Ceeding generated file
 
-      #line 9 "../foo/bar/fubar.c"
+      #line 9 "#{File.expand_path('../foo/bar/fubar.c')}"
       void foobarbaz(int x, int y) {
         int z = x+y;
       }
 
-      #line 123 "src/code/ABC.c"
+      #line 123 "#{File.expand_path('src/code/ABC.c')}"
       int
       razzleDazzle(void* ptr)
       {