Response file expansion limits the amount of expansion to prevent
potential infinite recursion. However, the current logic assumes that
any argument beginning with @ is a response file, which is not true for
e.g. -Xlinker -rpath -Xlinker @executable_path/../lib on Darwin.
Having too many of these non-response file arguments beginning with @
prevents actual response files from being expanded. Instead, limit based
on the number of successful response file expansions, which should still
prevent infinite recursion but also avoid false positives.
Details
Details
- Reviewers
rnk hans - Commits
- rG1826095a5faa: Reapply [Support] Fix recursive response file expansion guard
rL358466: Reapply [Support] Fix recursive response file expansion guard
rGc8df4fb9c386: [Support] Fix recursive response file expansion guard
rL358452: [Support] Fix recursive response file expansion guard
Diff Detail
Diff Detail
- Repository
- rG LLVM Github Monorepo
- Build Status
Buildable 30465 Build 30464: arc lint + arc unit
Event Timeline
Comment Actions
Looks good to me.
llvm/lib/Support/CommandLine.cpp | ||
---|---|---|
1041 | How about getting rid of the negation in the if statement and instead doing: if (ExpandResponseFile(..) { ++ExpandedRspFiles; } else { // We couldn't read this file ... } | |
llvm/unittests/Support/CommandLineTest.cpp | ||
773 | would push_back work instead? seems simpler |
How about getting rid of the negation in the if statement and instead doing: