Repository navigation
Do not treat -c as consuming the next compile argument - #60
Open
mateusz-olczyk wants to merge 1 commit into
Open
mateusz-olczyk wants to merge 1 commit into
mateusz-olczyk wants to merge 1 commit into
Conversation
`-c` takes no argument in gcc/clang; the extractors merely place the source right after it. Two places assumed otherwise: * reconstruct._source_from_compile_args took the first `-c <x>` as the translation unit's source. * canonicalize listed `-c` in _DRIVER_PAIR_FLAGS and dropped it together with the following token. Real projects can carry a redundant `-c` inside their flags (e.g. `CMAKE_C_FLAGS="... -c -std=c11 ..."`); gcc ignores the repetition. With such flags every TU of a CMake target was keyed by `-std=c11`, so all of them collapsed into a single bogus TU, and `-std=c11` itself was hidden from the flag comparison on both sides. The diff then compared a single TU per target instead of every source, so missing sources and per-file flag gaps went unreported. Now `-c` is dropped on its own, and the next token is only treated as the source (and dropped) when it is not a flag. Source detection skips a `-c` followed by a flag; the existing extension scan remains the fallback. Tests cover canonicalization of a stray `-c`, distinct TUs for two sources under such flags, convergence when both sides set the flag after the stray `-c`, and an error when Bazel is missing it. All three fail without the fix. docs/REFERENCE-cmake.md documents the behavior.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
-ctakes no argument in gcc/clang; the extractors merely place the source right after it. Two places assumed otherwise:-c <x>as the translation unit's source.-cin _DRIVER_PAIR_FLAGS and dropped it together with the following token.Real projects can carry a redundant
-cinside their flags (e.g.CMAKE_C_FLAGS="... -c -std=c11 ..."); gcc ignores the repetition. With such flags every TU of a CMake target was keyed by-std=c11, so all of them collapsed into a single bogus TU, and-std=c11itself was hidden from the flag comparison on both sides. The diff then compared a single TU per target instead of every source, so missing sources and per-file flag gaps went unreported.Now
-cis dropped on its own, and the next token is only treated as the source (and dropped) when it is not a flag. Source detection skips a-cfollowed by a flag; the existing extension scan remains the fallback.Tests cover canonicalization of a stray
-c, distinct TUs for two sources under such flags, convergence when both sides set the flag after the stray-c, and an error when Bazel is missing it. All three fail without the fix. docs/REFERENCE-cmake.md documents the behavior.