<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">I use "clangd version 8.0.0 (tags/RELEASE_800/final)" from homebrew and run it without command line options through my IDE.<div class=""><br class=""></div><div class="">"-fno-constant-cfstrings" will do the trick. I used it formerly with clang and forgot it with clangd since I’m currently using gcc with this project. Sorry for this - my fault!</div><div class=""><br class=""></div><div class="">The next ten days I will be on travel and cannot verify your solution, but I’m sure you’re right. For me this issue is solved. Thanks a lot and sorry for bothering you and clangd-dev with it!</div><div class=""><br class=""></div><div class="">Back at home I will verify it and leave a note.</div><div class=""><br class=""></div><div class="">Cheers,</div><div class=""><br class=""></div><div class="">Andreas<br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On 4. Jul 2019, at 09:47, Sam McCall <<a href="mailto:sammccall@google.com" class="">sammccall@google.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">Digging into the implementation (Sema::BuildObjCLiteral), I see two things:<div class=""> - the class is found by name lookup, so introducing an alias should work</div><div class=""> - the behavior depends on another flag, -fno-constant-cfstrings</div><div class=""> - when this flag is passed, -fconstant-string-class is used, falling back to "NSConstantString"</div><div class=""> - when this flag is not passed, "NSString" is always used</div><div class=""><br class=""></div><div class="">So two possible workarounds:</div><div class=""> - add `@comptability_alias NSString NGStringLiteral;` to your header</div><div class=""> - pass -fno-constant-cfstrings -fconstant-string-class=NGStringLiteral</div><div class=""><br class=""></div><div class="">I don't have any deep understanding here, so I don't know *why* these interactions exist, or which option you should choose. I'd guess the latter, though.</div><div class="">And AFAIK this should always be the same between (equal versions of) clang and clangd, so let me know if you can verify differences.</div></div><br class=""><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Jul 4, 2019 at 9:28 AM Sam McCall <<a href="mailto:sammccall@google.com" class="">sammccall@google.com</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr" class="">FWIW, I get this error from clang too:<div class=""><br class=""></div><div class="">$ cat str.m</div><div class=""><br class=""></div><div class="">@interface NGStaticObject<br class="">{ Class isa; }<br class="">@end<br class="">@interface NGStringLiteral : NGStaticObject<br class="">{ char *c_string; unsigned int len; }<br class="">@end<br class="">NGStringLiteral *t = @"Hello world";<br class=""></div><div class=""><br class=""></div><div class="">$ clang-7 -fsyntax-only str.m -fconstant-string-class=NGStringLiteral</div><div class=""><br class=""></div><div class="">str.m:7:18: warning: incompatible pointer types initializing 'NGStringLiteral *' with an expression of type 'NSString *' [-Wincompatible-pointer-types]<br class=""></div><div class=""><br class=""></div><div class="">$ clang-7 --version</div><div class=""><br class=""></div><div class="">clang version 7.0.1-6 (tags/RELEASE_701/final)<br class="">Target: x86_64-pc-linux-gnu<br class="">Thread model: posix<br class="">InstalledDir: /usr/bin<br class=""></div><div class=""><br class=""></div><div class="">Similar results from tip-of-tree.</div><div class=""><br class=""></div><div class="">How are you running clang, and what's your clang --version?</div><div class=""><br class=""></div><div class="">This may well need a solution regardless, but it'd be good to know if it's really clangd-specific (which would be surprising).</div></div><br class=""><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Jul 4, 2019 at 7:54 AM Andreas Ostermeyer <<a href="mailto:ostermeyer@me.com" target="_blank" class="">ostermeyer@me.com</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="">Hi Sam,<div class=""><br class=""></div><div class="">thanks for rapid responding. Yes, you’re right. I’ve forgotten to provide some descriptive code.</div><div class=""><br class=""></div><div class="">I’ve issued the constant-string-class flag in both files: compile_flags.txt at first and than in compile_commands.json to no avail.</div><div class=""><br class=""></div><div class="">NGStringLiteral is declared exactly like NXConstantString and demanded in the LLVM documentation, i.e. Class, char*, and unsigned int. Like so:</div><div class=""><div class=""><br class=""></div><div class=""><font face="Courier" class="">@interface NGStaticObject</font></div><div class=""><font face="Courier" class="">{</font></div><div class=""><font face="Courier" class=""> Class isa; /* A pointer to the instance's class structure. */</font></div><div class=""><font face="Courier" class="">}</font></div><div class=""><font face="Courier" class="">...</font></div><div class=""><font face="Courier" class="">@end</font></div></div><div class=""><div class=""><font face="Courier" class=""><br class=""></font></div><div class=""><font face="Courier" class="">@interface NGStringLiteral : NGStaticObject</font></div><div class=""><font face="Courier" class="">{</font></div><div class=""><font face="Courier" class=""> char *c_string;</font></div><div class=""><font face="Courier" class=""> unsigned int len;</font></div><div class=""><font face="Courier" class="">}</font></div><div class=""><font face="Courier" class="">@end</font></div></div><div class=""><br class=""></div><div class="">The test code in question is:</div><div class=""><br class=""></div><div class=""><font face="Courier" class="">NGStringLiteral *test0 = @"Hello world”;<span class="gmail-m_5248522066097801276gmail-m_3278666265252383080Apple-tab-span" style="white-space:pre-wrap"> </span>// —> “Incompatible pointer types initializing 'NGStringLiteral *' with an expression of type 'NSString *’”</font></div><div class=""><br class=""></div><div class="">A first attempt to mitigate this was:</div><div class=""><br class=""></div><div class=""><font face="Courier" class="">typedef NGStringLiteral NSString;</font></div><div class=""><div class=""><font face="Courier" class="">NSString *test1 = @"That's me;)”;<span class="gmail-m_5248522066097801276gmail-m_3278666265252383080Apple-tab-span" style="white-space:pre-wrap"> </span>// —> “Incompatible pointer types initializing 'NSString *' (aka 'NGStringLiteral *') with an expression of type 'NSString *’”</font></div><div class=""><br class=""></div><div class="">Another attempt is subclassing NSString from NGStringLiteral. This quiets clangd, but now the compiler (gcc) complains “warning: initialization from distinct Objective-C type”. But this is another story.</div><div class=""><br class=""></div><div class="">All the above code would be irrelevant if clangd would regard the constant-string-class flag.</div><div class=""><br class=""></div><div class="">Cheers,</div><div class=""><br class=""></div><div class="">Andreas</div><div class=""><br class=""><blockquote type="cite" class=""><div class="">On 3. Jul 2019, at 21:08, Sam McCall <<a href="mailto:sammccall@google.com" target="_blank" class="">sammccall@google.com</a>> wrote:</div><br class="gmail-m_5248522066097801276gmail-m_3278666265252383080Apple-interchange-newline"><div class=""><div dir="auto" class=""><div class="">Hi Andreas,</div><div dir="auto" class=""><br class=""><div dir="auto" class="">Can you provide a minimal source file that exhibits the problem, and explain how you're specifying the -fconstant-string-class flag? (It should be in the compile_commands.json or compile_flags.txt file)</div><div dir="auto" class=""><br class=""></div><div dir="auto" class="">It sounds like what you're describing should work, but I think we need more detail to reproduce the issue.</div><div dir="auto" class=""><br class=""></div><div dir="auto" class=""> I cant really speak to the layering between objc the language and the Foundation etc libraries. I'm sympathetic to the frustration but realistically clangd won't diverge from clang here, so this would be an issue for experts on cfe-dev.</div><div dir="auto" class=""><br class=""></div><div dir="auto" class="">Cheers, Sam</div><br class=""><br class=""><div class="gmail_quote" dir="auto"><div dir="ltr" class="gmail_attr">On Wed, Jul 3, 2019, 7:57 PM Andreas Ostermeyer via clangd-dev <<a href="mailto:clangd-dev@lists.llvm.org" target="_blank" class="">clangd-dev@lists.llvm.org</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">clangd developers,<br class="">
<br class="">
currently I’m working on an own small footprint Objective-C Class library completely unrelated to Cocoa. I use clangd [version 8.0.0 (tags/RELEASE_800/final)] from homebrew as the language server in my IDE.<br class="">
<br class="">
Unfortunately I can’t clangd persuade to accept my own as a constant string class with the flag "-fconstant-string-class=NGStringLiteral". Ignoring the flag it complains: “Incompatible pointer types initializing 'NGStringLiteral *' with an expression of type 'NSString *’”.<br class="">
<br class="">
To quiet this I declared ’NSString’ as ’NGStringLiteral’ (“typedef NSString NGStringLiteral”). Now clangd warns: “Incompatible pointer types initializing 'NSString *' (aka 'NGStringLiteral *') with an expression of type 'NSString *’”!<br class="">
<br class="">
That’s annoying - like all the hard-wired Cocoa aka Apple stuff in clang software. Objective-C is an independent general purpose programming language. Not a Cocoa development tool and not an Apple software product. This should be true for clang, too.<br class="">
<br class="">
So, what can I do (or what can you do) to get rid of - at least - this?<br class="">
<br class="">
Thanks in advance.<br class="">
<br class="">
Best regards,<br class="">
<br class="">
Andreas Ostermeyer<br class="">
_______________________________________________<br class="">
clangd-dev mailing list<br class="">
<a href="mailto:clangd-dev@lists.llvm.org" rel="noreferrer" target="_blank" class="">clangd-dev@lists.llvm.org</a><br class="">
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/clangd-dev" rel="noreferrer noreferrer" target="_blank" class="">https://lists.llvm.org/cgi-bin/mailman/listinfo/clangd-dev</a><br class="">
</blockquote></div></div></div>
</div></blockquote></div><br class=""></div></div></blockquote></div>
</blockquote></div>
</div></blockquote></div><br class=""></div></body></html>