Re: [cfe-users] clang-tidy bug?
On Wed, Oct 30, 2019 at 9:23 PM David Blaikie wrote:
>
> Two separate issues here
>
> 1) the fixit hint, as one of a set of alternatives, isn't likely to be
> removed/changed - the (albeit quirky) convention of using extra () to
> indicate an intentional assignment in a condition has been around for a
> while. So if you use the extra parens without writing an assignment, the
> compiler's going to suggest you resolve this "conflict" with the style -
> either you didn't intend the extra (), or you intended to use assignment.
> Those are the two alternative suggestions being made.
>
> 2) automatically applying one fixit hint of several ambiguous ones seems like
> a bug to me - Aaron - do you know anything about this? Is this
> accurate/intended/etc?
I also think that's a bug. It looks like it's coming from
Sema::DiagnoseEqualityWithExtraParens(). It looks like it presents
both fixits, which strikes me as a bad thing to do when automatically
applying fixits.
~Aaron
>
> On Tue, Oct 29, 2019 at 10:13 AM Robert Ankeney wrote:
>>
>> This was just a example of what I ran into when I used run-clang-tidy.py
>> across a compilation database with a -export-fixes=fix.yaml and then ra
>> clang-apply-replacements. Mainly I object to the suggestion+fixit to switch
>> to an assignment. Most coding standards would disallow assignments
>> in if conditionals. If anything, I would think a suggestion of "if (true ==
>> isValid)" would be more appropriate.
>>
>> Thanks for the feedback!
>> Robert
>>
>> On Mon, Oct 28, 2019 at 2:17 PM David Blaikie wrote:
>>>
>>> clang-tidy in the command line you gave didn't seem to modify the file for
>>> me, did it modify the file for you?
>>>
>>> Are you objecting to the suggestion, or that it was automatically applied?
>>> I would think it'd be a bug to apply any fixit/hint if there are multiple
>>> possible suggestions.
>>>
>>> But the existence of the suggestion (without the application of it) to the
>>> user seems right to me. The use of extra () to suppress the
>>> assignment-in-conditional warning (-Wparentheses) has been around for quite
>>> a while, so it's possible that the user intended assignment rather than
>>> comparison when they added the extra parentheses.
>>>
>>> - Dave
>>>
>>> On Sun, Oct 27, 2019 at 11:32 AM Robert Ankeney via cfe-users
>>> wrote:
For the following code (wrong.cpp):
bool check(bool isValid)
{
bool retVal = false;
if (( isValid == true ))
{
retVal = true;
}
return retVal;
}
when I run:
clang-tidy -checks=modernize-use-default-member-init wrong.cpp
I get:
4 warnings and 1 error generated.
Error while processing /llvm/match/ctBad/wrong.cpp.
/llvm/match/ctBad/wrong.cpp:5:19: error: equality comparison with
extraneous parentheses [clang-diagnostic-parentheses-equality]
if (( isValid == true ))
~ ^~ ~
=
/llvm/match/ctBad/wrong.cpp:5:19: note: remove extraneous parentheses
around the comparison to silence this warning
/llvm/match/ctBad/wrong.cpp:5:19: note: use '=' to turn this equality
comparison into an assignment
Note it turns the if into:
if ( isValid = true )
Seems like a very bad idea. Removing the redundant parentheses seems fine,
but changing the comparison to an assignment does not. Is this a bug?
Thanks,
Robert
___
cfe-users mailing list
cfe-users@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users
___
cfe-users mailing list
cfe-users@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users
Re: [cfe-users] clang-tidy bug?
On Thu, Oct 31, 2019 at 1:31 PM David Blaikie wrote:
>
>
>
> On Thu, Oct 31, 2019 at 8:45 AM Aaron Ballman wrote:
>>
>> On Wed, Oct 30, 2019 at 9:23 PM David Blaikie wrote:
>> >
>> > Two separate issues here
>> >
>> > 1) the fixit hint, as one of a set of alternatives, isn't likely to be
>> > removed/changed - the (albeit quirky) convention of using extra () to
>> > indicate an intentional assignment in a condition has been around for a
>> > while. So if you use the extra parens without writing an assignment, the
>> > compiler's going to suggest you resolve this "conflict" with the style -
>> > either you didn't intend the extra (), or you intended to use assignment.
>> > Those are the two alternative suggestions being made.
>> >
>> > 2) automatically applying one fixit hint of several ambiguous ones seems
>> > like a bug to me - Aaron - do you know anything about this? Is this
>> > accurate/intended/etc?
>>
>> I also think that's a bug. It looks like it's coming from
>> Sema::DiagnoseEqualityWithExtraParens(). It looks like it presents
>> both fixits, which strikes me as a bad thing to do when automatically
>> applying fixits.
>
>
> These fixits should be attached to notes, though, right? & Clang produces all
> sorts of fixits on notes that are not semantics-preserving, I think? ("oh, I
> think you meant to write this other thing")
Yes, they're both attached to notes but the notes point to the same
location as the error.
> My understanding is that the fixits are correct (in the clang diagnostic
> experience - "here's a warning, here are some ideas of what you might've
> intended that would address the warning") - but it seems incorrect to
> automatically apply especially ambiguous suggesitons like this. How would
> clang-tidy choose between the two alternatives?
I don't think it has a way to select between alternatives; I don't
think that was a use case we had envisioned for automatically applying
fix-its.
~Aaron
>
>>
>>
>> ~Aaron
>>
>> >
>> > On Tue, Oct 29, 2019 at 10:13 AM Robert Ankeney wrote:
>> >>
>> >> This was just a example of what I ran into when I used run-clang-tidy.py
>> >> across a compilation database with a -export-fixes=fix.yaml and then ra
>> >> clang-apply-replacements. Mainly I object to the suggestion+fixit to
>> >> switch to an assignment. Most coding standards would disallow assignments
>> >> in if conditionals. If anything, I would think a suggestion of "if (true
>> >> == isValid)" would be more appropriate.
>> >>
>> >> Thanks for the feedback!
>> >> Robert
>> >>
>> >> On Mon, Oct 28, 2019 at 2:17 PM David Blaikie wrote:
>> >>>
>> >>> clang-tidy in the command line you gave didn't seem to modify the file
>> >>> for me, did it modify the file for you?
>> >>>
>> >>> Are you objecting to the suggestion, or that it was automatically
>> >>> applied? I would think it'd be a bug to apply any fixit/hint if there
>> >>> are multiple possible suggestions.
>> >>>
>> >>> But the existence of the suggestion (without the application of it) to
>> >>> the user seems right to me. The use of extra () to suppress the
>> >>> assignment-in-conditional warning (-Wparentheses) has been around for
>> >>> quite a while, so it's possible that the user intended assignment rather
>> >>> than comparison when they added the extra parentheses.
>> >>>
>> >>> - Dave
>> >>>
>> >>> On Sun, Oct 27, 2019 at 11:32 AM Robert Ankeney via cfe-users
>> >>> wrote:
>>
>> For the following code (wrong.cpp):
>>
>> bool check(bool isValid)
>> {
>> bool retVal = false;
>>
>> if (( isValid == true ))
>> {
>> retVal = true;
>> }
>>
>> return retVal;
>> }
>>
>> when I run:
>> clang-tidy -checks=modernize-use-default-member-init wrong.cpp
>>
>> I get:
>> 4 warnings and 1 error generated.
>> Error while processing /llvm/match/ctBad/wrong.cpp.
>> /llvm/match/ctBad/wrong.cpp:5:19: error: equality comparison with
>> extraneous parentheses [clang-diagnostic-parentheses-equality]
>> if (( isValid == true ))
>> ~ ^~ ~
>> =
>> /llvm/match/ctBad/wrong.cpp:5:19: note: remove extraneous parentheses
>> around the comparison to silence this warning
>> /llvm/match/ctBad/wrong.cpp:5:19: note: use '=' to turn this equality
>> comparison into an assignment
>>
>> Note it turns the if into:
>> if ( isValid = true )
>>
>> Seems like a very bad idea. Removing the redundant parentheses seems
>> fine, but changing the comparison to an assignment does not. Is this a
>> bug?
>>
>> Thanks,
>> Robert
>>
>> ___
>> cfe-users mailing list
>> cfe-users@lists.llvm.org
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users
___
cfe-us
Re: [cfe-users] clang-tidy bug?
On Thu, Oct 31, 2019 at 2:28 PM David Blaikie wrote:
>
>
>
> On Thu, Oct 31, 2019 at 11:19 AM Aaron Ballman wrote:
>>
>> On Thu, Oct 31, 2019 at 1:31 PM David Blaikie wrote:
>> >
>> >
>> >
>> > On Thu, Oct 31, 2019 at 8:45 AM Aaron Ballman
>> > wrote:
>> >>
>> >> On Wed, Oct 30, 2019 at 9:23 PM David Blaikie wrote:
>> >> >
>> >> > Two separate issues here
>> >> >
>> >> > 1) the fixit hint, as one of a set of alternatives, isn't likely to be
>> >> > removed/changed - the (albeit quirky) convention of using extra () to
>> >> > indicate an intentional assignment in a condition has been around for a
>> >> > while. So if you use the extra parens without writing an assignment,
>> >> > the compiler's going to suggest you resolve this "conflict" with the
>> >> > style - either you didn't intend the extra (), or you intended to use
>> >> > assignment. Those are the two alternative suggestions being made.
>> >> >
>> >> > 2) automatically applying one fixit hint of several ambiguous ones
>> >> > seems like a bug to me - Aaron - do you know anything about this? Is
>> >> > this accurate/intended/etc?
>> >>
>> >> I also think that's a bug. It looks like it's coming from
>> >> Sema::DiagnoseEqualityWithExtraParens(). It looks like it presents
>> >> both fixits, which strikes me as a bad thing to do when automatically
>> >> applying fixits.
>> >
>> >
>> > These fixits should be attached to notes, though, right? & Clang produces
>> > all sorts of fixits on notes that are not semantics-preserving, I think?
>> > ("oh, I think you meant to write this other thing")
>>
>> Yes, they're both attached to notes but the notes point to the same
>> location as the error.
>>
>> > My understanding is that the fixits are correct (in the clang diagnostic
>> > experience - "here's a warning, here are some ideas of what you might've
>> > intended that would address the warning") - but it seems incorrect to
>> > automatically apply especially ambiguous suggesitons like this. How would
>> > clang-tidy choose between the two alternatives?
>>
>> I don't think it has a way to select between alternatives; I don't
>> think that was a use case we had envisioned for automatically applying
>> fix-its.
>
>
> I wasn't thinking a way to select - but I'd expect an automated tool to, when
> presented with an ambiguity, decide that not doing anything was the best
> course of action (same as if the warning had no notes).
I agree. I've CCed Alex in case he has opinions as well.
~Aaron
>
>>
>>
>> ~Aaron
>>
>> >
>> >>
>> >>
>> >> ~Aaron
>> >>
>> >> >
>> >> > On Tue, Oct 29, 2019 at 10:13 AM Robert Ankeney
>> >> > wrote:
>> >> >>
>> >> >> This was just a example of what I ran into when I used
>> >> >> run-clang-tidy.py across a compilation database with a
>> >> >> -export-fixes=fix.yaml and then ra
>> >> >> clang-apply-replacements. Mainly I object to the suggestion+fixit to
>> >> >> switch to an assignment. Most coding standards would disallow
>> >> >> assignments
>> >> >> in if conditionals. If anything, I would think a suggestion of "if
>> >> >> (true == isValid)" would be more appropriate.
>> >> >>
>> >> >> Thanks for the feedback!
>> >> >> Robert
>> >> >>
>> >> >> On Mon, Oct 28, 2019 at 2:17 PM David Blaikie
>> >> >> wrote:
>> >> >>>
>> >> >>> clang-tidy in the command line you gave didn't seem to modify the
>> >> >>> file for me, did it modify the file for you?
>> >> >>>
>> >> >>> Are you objecting to the suggestion, or that it was automatically
>> >> >>> applied? I would think it'd be a bug to apply any fixit/hint if there
>> >> >>> are multiple possible suggestions.
>> >> >>>
>> >> >>> But the existence of the suggestion (without the application of it)
>> >> >>> to the user seems right to me. The use of extra () to suppress the
>> >> >>> assignment-in-conditional warning (-Wparentheses) has been around for
>> >> >>> quite a while, so it's possible that the user intended assignment
>> >> >>> rather than comparison when they added the extra parentheses.
>> >> >>>
>> >> >>> - Dave
>> >> >>>
>> >> >>> On Sun, Oct 27, 2019 at 11:32 AM Robert Ankeney via cfe-users
>> >> >>> wrote:
>> >>
>> >> For the following code (wrong.cpp):
>> >>
>> >> bool check(bool isValid)
>> >> {
>> >> bool retVal = false;
>> >>
>> >> if (( isValid == true ))
>> >> {
>> >> retVal = true;
>> >> }
>> >>
>> >> return retVal;
>> >> }
>> >>
>> >> when I run:
>> >> clang-tidy -checks=modernize-use-default-member-init wrong.cpp
>> >>
>> >> I get:
>> >> 4 warnings and 1 error generated.
>> >> Error while processing /llvm/match/ctBad/wrong.cpp.
>> >> /llvm/match/ctBad/wrong.cpp:5:19: error: equality comparison with
>> >> extraneous parentheses [clang-diagnostic-parentheses-equality]
>> >> if (( isValid == true ))
>> >> ~ ^~ ~
>> >> =
>> >> /
Re: [cfe-users] Compiling for Linux (with Visual Studio and Clang)
On Sat, Aug 8, 2020 at 4:13 AM Eric Christopher wrote: > > I don't know anyone that is cross compiling from windows to linux using > visual studio and clang right now. It doesn't mean it can't work, just that > it's not easy to point you at an example unfortunately. > > +Robinson, Paul as someone that might know others that are. > +Aaron Ballman also. > > You can also try asking on either irc or discord and see if anyone there can > help. Unfortunately, I don't have any experience in this area and I don't know anyone who's tried that. It seems like it should be plausible, but you may be breaking new ground. ~Aaron > > -eric > > On Sat, Aug 8, 2020 at 12:00 AM John Emmas via cfe-users > wrote: >> >> On 04/08/2020 14:46, John Emmas wrote: >> > I read somewhere that the clang devs and Microsoft were collaborating >> > to make Visual Studio compatible with clang. >> > >> > So what's the situation if I want to compile some C++ code for Linux? >> > [...] Is there a Linux version of Visual Studio available now? Or >> > does it work by cross-compiling from VS (in Windows) somehow? >> > >> >> Sorry guys... do I need to direct this question to the developers >> mailing list - rather than users? >> ___ >> cfe-users mailing list >> cfe-users@lists.llvm.org >> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users ___ cfe-users mailing list cfe-users@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users
Re: [cfe-users] (bug?) ParsedAttr::getNumArgs() always return zero
On Thu, Dec 2, 2021 at 12:48 PM David Blaikie wrote: > > I'm /guessing/ this API doesn't respond with attributes clang doesn't > recognize (CC'd Aaron Ballman who would likely know the details better than I > do). Does the API correctly respond with a non-zero number of attributes for > any clang-supported attribute (listed here: > https://clang.llvm.org/docs/AttributeReference.html ) I think this is https://bugs.llvm.org/show_bug.cgi?id=46446, which has more details about the issues and plausible ways forward. ~Aaron > > On Thu, Dec 2, 2021 at 5:23 AM Владимир Фролов via cfe-users > wrote: >> >> Dear colleguaes, it seems i have met the bug for processing of C++11 custom >> language attributes. >> >> 1) I took example from >> https://github.com/llvm/llvm-project/blob/main/clang/examples/Attribute/Attribute.cpp >> 2) And make a short sample which reproduce the bug >> https://github.com/FROL256/clang_parse_ast_example >> >> The problem in that getNumArgs() is always zero, nevermind how many >> arguments we actually have in the attribute. >> I have tested this with clang 12. I think i could test it under clang 14 if >> build sample as a part of llvm. >> But probably i just did some-thing wrong ... ? >> >> Anyway it would be nice to have this issue working with clang 12 because >> usually i work with prebuild packages of clang and libtooling on Linux Mint. >> Could you please look prepared sample and suggest sms if possible ... >> thanks! ) >> -- >> Best Regards, >> Frolov V.A. >> >> ___ >> cfe-users mailing list >> cfe-users@lists.llvm.org >> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users ___ cfe-users mailing list cfe-users@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users
