Qt Creator Code Model error on legal attribute
-
I could have posted this to Qt Tools Creator category, but I'm asking stuff in C++ Gurus so this seems just as good a place.
Creator 13.0, but has always happened on previous Creator versions, I am just getting around to reporting this now. gcc 13.2.
-std=gnu++1z
(C++ 17),-Wall -Wextra
. I cannot find a "switch-case-fallthrough" source code annotation which Creator does not think is an error and so red-underlines it in text editor.Note that I cannot use clang/clangd Code Model. I have switched that off in Creator and unloaded that plugin. So whatever Creator's "internal" Code Model is being used. This might be different if it were using clang, I have not/cannot test, but I would like it to work correctly without clang anyway.
Code:
switch (...) { case FIRST: ... [[fallthrough]] case SECOND: ... }
This is correct code per C++17, C++ attribute: fallthrough (since C++17). It compiles with all warnings on. Creator red-underlines this with tooltip
expected token ';' got '[
"``. Changing to[[gnu::fallthrough]]
or[[clang::fallthrough]]
does not help.Shouldn't Creator's internal code model at least accept
[[fallthrough]]
which I think is just C++ 17 without special extensions? Should I report this? How do you annotate yourcase
-fallthroughs? Maybe you use clang code model, does something work there? -
UPDATE/CORRECTION
I tried again with switching Use clangd on and off. Somehow it seems it didn't "take" right formerly. Now I do see different behaviour. I find that sometimes when I start Creator, it warns me I have don't have enough memory for clangd, I selected "Enable anyway", it still red-underlines
[[fallthrough]];
. Then I go to Preferences, switch off clangd and then switch it back on, that clears the complaint. It seems I have to switch off and back on every time to make it work. Sigh....With clangd switched on I can use any of the
[[fallthrough]];
annotations which get through gcc compiler and code editor does not red underline them.Q_FALLTHROUGH()
macro still requires a blank line without clangd, but works without blank line with clangd. Fair enough, @aha_1980 has warned me that it will be "problematic* with the internal code model rather than clangd.So all in all I can now use
[[fallthrough]];
in my code with clangd, that is apparently "standard" C++ 17 so I accept that. -
Shouldn't Creator's internal code model at least accept [[fallthrough]] which I think is just C++ 17 without special extensions?
No.
Should I report this?
It won't be fixed.
-
@aha_1980
Fair enough if you say so :)So at least without the clang code model is there any annotation I can put in my code allowing case-fallthrough which compiles without warning but does not cause Creator to mark it as erroneous? Are you saying there would be something if I used the clang code model? If the answer is "No" to both that seems pretty bad, no?
-
The internal code model does not understand much of post C++11 code, so such attributes may be problematic.
At least gcc seems to honor the
// fall through
comment, which is primary thought for plain C, but also works in C++. But be careful to write it correctly, its just a comment, no keyword.The clang code model should accept all attributes, but does not necessarily warn if
[[fallthrough]]
is missing. Why? I don't know.PS: "will not be fixed" means, you can provide patches and they may be accepted, but noone will actively work on it.
-
@aha_1980
All clear, thanks.The internal code model does not understand much of post C++11 code,
Ah! That explains a lot.
The clang code model should accept all attributes
But it doesn't accept the 4GB I have allocated to the VM as being enough for its ravenous habits. And Creator 13 disables it. Do you know just how much RAM it does want when I'm going to write a
Hello world
program?! Honestly if it can't do it when the compiler has enough space to run I give up -
Ah, I didn't know there is a hard 4 GB limit now.
Well for this case, you really have to ask the maintainers. But if they think, 4GB is not enough, they might have their statistics.
The rule of thumb is to have 1 GB RAM per CPU core, as parallel compiling might take this memory. All of my machines have this or more and I have to admit that Clangd works much better than the first Clang Code Model versions. It's not perfect yet, but most often usable :)
-
@JonB said in Qt Creator Code Model error on legal attribute:
This is correct code per C++17, C++ attribute: fallthrough (since C++17).
As per the link you have provided yourself:
May only be applied to a null statement to create a fallthrough statement ([[fallthrough]];).
The semicolon is required per the standard. It is annoying, but it is what it is...
-
there's always Q_FALLTHROUGH should work with old and new code model.
-
@SimonSchroeder
Hi Simon. My bad example, I did read about the trailing;
and I did always have it there in all cases. I have edited my earlier code to include that now.If you read the tooltip message I typed carefully it is clear the code model is actually expecting an end of statement
;
prior to the closing]
not after it.So that is not the issue. None of
[[fallthrough]];
,[[gnu::fallthrough]];
or[[clang::fallthrough]];
avoid the code editor red-underlining it with that error message. With gcc compiler the first two compile acceptably without warning, but the third one does not. Sadly/unexpectedly when I temporarily force Creator to use clangd despite memory warnings it makes no difference, all three get red-underlines with same message.The only thing which keeps Creator happy and compiles without warning is @aha_1980's
// fall through
comment (for which thanks).Could you please state what you use in C++ code for a
case
fall through?Now that I have tried this with clang code model this is not right. At minimum
[[fallthrough]];
is apparently standard C++ 17 so ISTM the editor should not incorrectly complain about. @aha_1980 said the internal code model is too old, but I don;t see why I should still get this with clangd code model. If I don't hear better here I shall be raising a bug report for this. -
@J-Hilk said in Qt Creator Code Model error on legal attribute:
there's always Q_FALLTHROUGH should work with old and new code model.
Nope.
Q_FALLTHROUGH();
gets through the compiler fine without warning about fall through but Creator editor red-underlines the followingcase
label. Replacing it with its gcc expansion,__attribute__((fallthrough))
, red-underlines that statement.Hmm, curiouser and curiouser.
Q_FALLTHROUGH();
sometimes works in editor and sometimes not: Two screenshots:In #1 you can see the red-underline, with tooltip about
expected token ';'
. By chance in #2 I happened to insert a blank line between theQ_FALLTHROUGH();
and the followingcase
label. Lo and behold, the red underlining/complain tooltip gets removed. This is bizarre.....So I am finding it pretty hard to know what works/does not work with C++ 17 and with/without clangd code model. Having code which includes a fall-through
case
statement is not that unusual, surely some of you have it? I am waiting/hoping to hear what you guys actually use in practice in your code, please...? -
UPDATE/CORRECTION
I tried again with switching Use clangd on and off. Somehow it seems it didn't "take" right formerly. Now I do see different behaviour. I find that sometimes when I start Creator, it warns me I have don't have enough memory for clangd, I selected "Enable anyway", it still red-underlines
[[fallthrough]];
. Then I go to Preferences, switch off clangd and then switch it back on, that clears the complaint. It seems I have to switch off and back on every time to make it work. Sigh....With clangd switched on I can use any of the
[[fallthrough]];
annotations which get through gcc compiler and code editor does not red underline them.Q_FALLTHROUGH()
macro still requires a blank line without clangd, but works without blank line with clangd. Fair enough, @aha_1980 has warned me that it will be "problematic* with the internal code model rather than clangd.So all in all I can now use
[[fallthrough]];
in my code with clangd, that is apparently "standard" C++ 17 so I accept that. -