<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Nov 24, 2015 at 3:25 PM, Uri Mann <span dir="ltr"><<a href="mailto:umann@symantec.com" target="_blank">umann@symantec.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Dave;<br>
<br>
Thanks for your help. I changed my code per your suggestion. I’m not sure if you’re the author of the code</blockquote><div><br></div><div>I'm the author of the change that broke your code, but not the original author or core maintainer of that specific API.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> or you’re just maintaining the docs, but there’s a small change which I added, to make the derived class compile:<br></blockquote><div><br></div><div>Thanks for the details</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
struct ProjectParser : public llvm::cl::basic_parser<std::string> {<br>
    ProjectParser(__in llvm::cl::opt<std::string, false, ProjectParser>& Option);<br>
    ProjectParser& operator=(const ProjectParser&) = delete;<br></blockquote><div><br></div><div>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)?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
    typedef std::string parser_data_type;<br>
    typedef llvm::cl::OptionValue<std::string> OptVal;<br>
<br>
    bool parse(__in llvm::cl::Option& option,<br>
               __in llvm::StringRef argName,<br>
               __in const std::string& argValue,<br>
               __in std::string& project);<br>
    // Needed to for CLANG 3.7.0<br>
    operator llvm::cl::parser<std::string>&(void) const;<br>
};<br>
<br>
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.<br></blockquote><div><br></div><div>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? </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Thanks again.<br>
-Uri<br>
<br>
<br>
From: David Blaikie [mailto:<a href="mailto:dblaikie@gmail.com">dblaikie@gmail.com</a>]<br>
Sent: Tuesday, November 24, 2015 9:40 AM<br>
To: Uri Mann<br>
Cc: <a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a><br>
Subject: Re: [cfe-dev] Help with Command-Line Validation<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
<br>
On Tue, Nov 24, 2015 at 8:47 AM, Uri Mann via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a>> wrote:<br>
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.<br>
struct ProjectParser : public llvm::cl::parser<std::string> {<br>
    bool parse(llvm::cl::Option& option,<br>
                          llvm::StringRef argName,<br>
                          const std::string& argValue,<br>
                          std::string& project);<br>
};<br>
 <br>
llvm::cl::opt<std::string, false, ProjectParser> Project;<br>
 <br>
This no longer compiles since the llvm::cl::parser<std::string> template was specialized and made ‘final’. The docs don’t address this issue.<br>
<br>
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)<br>
<br>
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.<br>
<br>
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)<br>
<br>
- Dave<br>
 <br>
 <br>
Any help will be appreciated. Thanks in advance.<br>
-Uri<br>
 <br>
<br>
_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br>
<br>
</div></div></blockquote></div><br></div></div>