[clangd-dev] Flag constant-string-class in clangd

[Sam McCall via clangd-dev]

Digging into the implementation (Sema::BuildObjCLiteral), I see two things:
 - the class is found by name lookup, so introducing an alias should work
 - the behavior depends on another flag, -fno-constant-cfstrings
   - when this flag is passed, -fconstant-string-class is used, falling
back to "NSConstantString"
   - when this flag is not passed, "NSString" is always used

So two possible workarounds:
 - add `@comptability_alias NSString NGStringLiteral;` to your header
 - pass -fno-constant-cfstrings -fconstant-string-class=NGStringLiteral

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.
And AFAIK this should always be the same between (equal versions of) clang
and clangd, so let me know if you can verify differences.

On Thu, Jul 4, 2019 at 9:28 AM Sam McCall <sammccall at google.com> wrote:

> FWIW, I get this error from clang too:
>
> $ cat str.m
>
> @interface NGStaticObject
> { Class isa; }
> @end
> @interface NGStringLiteral : NGStaticObject
> { char *c_string; unsigned int len; }
> @end
> NGStringLiteral *t = @"Hello world";
>
> $ clang-7 -fsyntax-only str.m -fconstant-string-class=NGStringLiteral
>
> str.m:7:18: warning: incompatible pointer types initializing
> 'NGStringLiteral *' with an expression of type 'NSString *'
> [-Wincompatible-pointer-types]
>
> $ clang-7 --version
>
> clang version 7.0.1-6 (tags/RELEASE_701/final)
> Target: x86_64-pc-linux-gnu
> Thread model: posix
> InstalledDir: /usr/bin
>
> Similar results from tip-of-tree.
>
> How are you running clang, and what's your clang --version?
>
> This may well need a solution regardless, but it'd be good to know if it's
> really clangd-specific (which would be surprising).
>
> On Thu, Jul 4, 2019 at 7:54 AM Andreas Ostermeyer <ostermeyer at me.com>
> wrote:
>
>> Hi Sam,
>>
>> thanks for rapid responding. Yes, you’re right. I’ve forgotten to provide
>> some descriptive code.
>>
>> 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.
>>
>> NGStringLiteral is declared exactly like NXConstantString and demanded in
>> the LLVM documentation, i.e. Class, char*, and unsigned int. Like so:
>>
>> @interface NGStaticObject
>> {
>>   Class isa; /* A pointer to the instance's class structure.  */
>> }
>> ...
>> @end
>>
>> @interface NGStringLiteral : NGStaticObject
>> {
>>   char *c_string;
>>   unsigned int len;
>> }
>> @end
>>
>> The test code in question is:
>>
>> NGStringLiteral *test0 = @"Hello world”; // —> “Incompatible pointer
>> types initializing 'NGStringLiteral *' with an expression of type 'NSString
>> *’”
>>
>> A first attempt to mitigate this was:
>>
>> typedef NGStringLiteral NSString;
>> NSString *test1 = @"That's me;)”; // —> “Incompatible pointer types
>> initializing 'NSString *' (aka 'NGStringLiteral *') with an expression of
>> type 'NSString *’”
>>
>> 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.
>>
>> All the above code would be irrelevant if clangd would regard the
>> constant-string-class flag.
>>
>> Cheers,
>>
>> Andreas
>>
>> On 3. Jul 2019, at 21:08, Sam McCall <sammccall at google.com> wrote:
>>
>> Hi Andreas,
>>
>> 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)
>>
>> It sounds like what you're describing should work, but I think we need
>> more detail to reproduce the issue.
>>
>>  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.
>>
>> Cheers, Sam
>>
>>
>> On Wed, Jul 3, 2019, 7:57 PM Andreas Ostermeyer via clangd-dev <
>> clangd-dev at lists.llvm.org> wrote:
>>
>>> clangd developers,
>>>
>>> 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.
>>>
>>> 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 *’”.
>>>
>>> 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 *’”!
>>>
>>> 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.
>>>
>>> So, what can I do (or what can you do) to get rid of - at least - this?
>>>
>>> Thanks in advance.
>>>
>>> Best regards,
>>>
>>> Andreas Ostermeyer
>>> _______________________________________________
>>> clangd-dev mailing list
>>> clangd-dev at lists.llvm.org
>>> https://lists.llvm.org/cgi-bin/mailman/listinfo/clangd-dev
>>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/clangd-dev/attachments/20190704/72402061/attachment-0001.html>