[cfe-dev] Help with Command-Line Validation

[David Blaikie via cfe-dev]

On Tue, Nov 24, 2015 at 3:25 PM, Uri Mann <umann at symantec.com> wrote:

> Hi Dave;
>
> Thanks for your help. I changed my code per your suggestion. I’m not sure
> if you’re the author of the code


I'm the author of the change that broke your code, but not the original
author or core maintainer of that specific API.


> or you’re just maintaining the docs, but there’s a small change which I
> added, to make the derived class compile:
>

Thanks for the details


> struct ProjectParser : public llvm::cl::basic_parser<std::string> {
>     ProjectParser(__in llvm::cl::opt<std::string, false, ProjectParser>&
> Option);
>     ProjectParser& operator=(const ProjectParser&) = delete;
>

Why the need for these ctors/assignment operator? The original class
derived from parser<string> wouldn't've had anything other than a default
ctor (& maybe a default/implicit copy assignment operator)?


>
>     typedef std::string parser_data_type;
>     typedef llvm::cl::OptionValue<std::string> OptVal;
>
>     bool parse(__in llvm::cl::Option& option,
>                __in llvm::StringRef argName,
>                __in const std::string& argValue,
>                __in std::string& project);
>     // Needed to for CLANG 3.7.0
>     operator llvm::cl::parser<std::string>&(void) const;
> };
>
> I had to add the conversion operator since template<class ParserClass,
> class ValDT> void printOptionDiff() methods expects
> llvm::cl::parser<std::string>. In my case the conversion operator never
> gets called. If the above method is called, it may try to access members
> which do not exists.
>

Hmm, that's curious - I'll have to look into that. Might be able to fix
it... should be able to remove that requirement. Hmm, do you have the error
message from that?


>
> Thanks again.
> -Uri
>
>
> From: David Blaikie [mailto:dblaikie at gmail.com]
> Sent: Tuesday, November 24, 2015 9:40 AM
> To: Uri Mann
> Cc: cfe-dev at lists.llvm.org
> Subject: Re: [cfe-dev] Help with Command-Line Validation
>
>
>
> On Tue, Nov 24, 2015 at 8:47 AM, Uri Mann via cfe-dev <
> cfe-dev at lists.llvm.org> wrote:
> I’m updating from CLANG 3.5.0 to 3.7.0. In the 3.5.0 version I have a
> std::string option with validation.
> struct ProjectParser : public llvm::cl::parser<std::string> {
>     bool parse(llvm::cl::Option& option,
>                           llvm::StringRef argName,
>                           const std::string& argValue,
>                           std::string& project);
> };
>
> llvm::cl::opt<std::string, false, ProjectParser> Project;
>
> This no longer compiles since the llvm::cl::parser<std::string> template
> was specialized and made ‘final’. The docs don’t address this issue.
>
> Sorry about that - I've an open bug telling me I need to update the docs
> here. I made the change to make parser final (bunch of API design reasons
> and that extension point wasn't needed inside LLVM/Clang - though I didn't
> realize we documented it as an extension point for external users)
>
> I'm not quite sure why we documented this as a useful extension point for
> external users yet have no examples of using that inside the LLVM project -
> I imagine we do something else inside LLVM instead.
>
> Off the cuff, I would suggest you derived from basic_parser and add the
> two member typedefs that parser<T> was providing for you. (but I'm still
> curious what LLVM does if it doesn't do the derivation from parser<T> and
> whether we should understand/encourage that instead)
>
> - Dave
>
>
> Any help will be appreciated. Thanks in advance.
> -Uri
>
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20151124/70ea2fbd/attachment.html>