[PATCH] Fix sample code in section "Writing a custom parser"

Chris Bieneman beanz at apple.com
Thu Oct 9 14:27:17 PDT 2014


+chandlerc

Not sure if I’m really qualified to approve, but this LGTM.

This is one feature of the existing cl::opt that we’re going to need to figure out how to handle in the new API, but that’s a whole other discussion.

-Chris

> On Oct 8, 2014, at 1:24 PM, Yung, Douglas <douglas_yung at playstation.sony.com> wrote:
> 
> Hi –
>  
> I recently was trying to add switch which used a custom parser by following the directions athttp://llvm.org/docs/CommandLine.html#custom-parser <http://llvm.org/docs/CommandLine.html#custom-parser>. However, the example is out-of-date, and I wanted to fix it so that others using it in the future will not get confused. This is an issue that has been around for quite a while as I found an email regarding it was sent out in January of 2012 (http://lists.cs.uiuc.edu/pipermail/llvmdev/2012-January/046919.html <http://lists.cs.uiuc.edu/pipermail/llvmdev/2012-January/046919.html>), but it was never fixed. My changes allow it to work with the latest version of trunk that I tested, revision 219325.
>  
> Files:
>   Docs/CommandLine.rst
>  
> ======8<======
> Index: docs/CommandLine.rst
> ===================================================================
> --- docs/CommandLine.rst        (revision 219288)
> +++ docs/CommandLine.rst        (working copy)
> @@ -1630,13 +1630,13 @@
>  
> .. code-block:: c++
>  
> -  struct FileSizeParser : public cl::basic_parser<unsigned> {
> +  struct FileSizeParser : public cl::parser<unsigned> {
>      // parse - Return true on error.
> -    bool parse(cl::Option &O, const char *ArgName, const std::string &ArgValue,
> +    bool parse(cl::Option &O, StringRef ArgName, const std::string &ArgValue,
>                 unsigned &Val);
>    };
>  
> -Our new class inherits from the ``cl::basic_parser`` template class to fill in
> +Our new class inherits from the ``cl::parser`` template class to fill in
> the default, boiler plate code for us.  We give it the data type that we parse
> into, the last argument to the ``parse`` method, so that clients of our custom
> parser know what object type to pass in to the parse method.  (Here we declare
> @@ -1652,7 +1652,7 @@
>  
> .. code-block:: c++
>  
> -  bool FileSizeParser::parse(cl::Option &O, const char *ArgName,
> +  bool FileSizeParser::parse(cl::Option &O, StringRef ArgName,
>                               const std::string &Arg, unsigned &Val) {
>      const char *ArgStart = Arg.c_str();
>      char *End;
> @@ -1698,7 +1698,7 @@
>    OPTIONS:
>      -help                 - display available options (-help-hidden for more)
>      ...
> -   -max-file-size=<size> - Maximum file size to accept
> +    -max-file-size=<size> - Maximum file size to accept
>  
> And we can test that our parse works correctly now (the test program just prints
> out the max-file-size argument value):
> ======8<======
>  
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu <mailto:llvm-commits at cs.uiuc.edu>
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits <http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20141009/d6a4e672/attachment.html>


More information about the llvm-commits mailing list