Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Reland "[Support]Look up in top-level subcommand as a fallback when l…
…ooking options for a custom subcommand (#71981) Fixed build bot errors. - Use `StackOption<std::string>` type for the top level option. This way, a per test-case option is unregistered when destructor of `StackOption` cleans up state for subsequent test cases. - Repro the crash with no test sharding `/usr/bin/python3 /path/to/llvm-project/build/./bin/llvm-lit -vv --no-gtest-sharding -j128 /path/to/llvm-project/llvm/test/Unit`. The crash is gone with the fix (same no-sharding repro) **Original commit message:** **Context:** - In https://lists.llvm.org/pipermail/llvm-dev/2016-June/101804.html and commit 07670b3, `cl::SubCommand` is introduced. - Options that don't specify subcommand goes into a special 'top level' subcommand. **Motivating Use Case:** - The motivating use case is to refactor `llvm-profdata` to use `cl::SubCommand` to organize subcommands. See #71328. A valid use case that's not supported before this patch is shown below ``` // show-option{1,2} are associated with 'show' subcommand. // top-level-option3 is in top-level subcomand (e.g., `profile-isfs` in SampleProfReader.cpp) llvm-profdata show --show-option1 --show-option2 --top-level-option3 ``` - Before this patch, option handler look-up will fail with the following error message "Unknown command line argument --top-level-option3". - After this patch, option handler look-up will look up in sub-command options first, and use top-level subcommand as a fallback, so 'top-level-option3' is parsed correctly.
- Loading branch information