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

[Sam McCall via clangd-dev]

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/dee8fc60/attachment.html>