Bug 371741 - KDevelop doesn't report certain errors.
Summary: KDevelop doesn't report certain errors.
Status: RESOLVED WORKSFORME
Alias: None
Product: kdevelop
Classification: Applications
Component: Language Support: CPP (Clang-based) (show other bugs)
Version: 5.0.2
Platform: Arch Linux Linux
: NOR normal
Target Milestone: ---
Assignee: kdevelop-bugs-null
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-10-27 12:43 UTC by OlafLostViking
Modified: 2022-11-25 05:23 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description OlafLostViking 2016-10-27 12:43:57 UTC
== Short ==

KDevelop is not reporting a not-closed namespace in a header file. (No "expected { to match this }" in the "Problems" tab.)



== Long ==

KDevelop is not marking problems in a header file when a namepsace is not correctly closed. In smaller projects (I tried to build a minimal example) this is then easily seen in the main.cpp; in my case (see below) I have no idea at all if in any file down the tree this was ever shown. But in the end I never saw an error; only files not getting parsed/coloured.

While I do see that a preprocessor could insert that missing } in any other file, I, personally, would probably prefer to get a warning when the braces in a file are not matching. Isn't that default behaviour?



== My case==

It all started with the fact that some files in my project were missing the semantic colouring and weren't parsed anymore by the clang-parser.

For my further project internal tests I used a trivial (stand-alone, only std::lib, simple RAII flag saver) header file that didn't get parsed anymore in my project. I found out this only happens when the file is included in another class. Going down the tree I finally found the culprit: a totally unrelated header file which was used in a class that used a class that... etc that included this header (all files along this tree failed to parse/colour).

In this header file, a namespace was opened but not correctly closed. But KDevelop did not complain about that anywhere but simply did no longer parse the other files using this header as well as totally unrelated headers included by them. The "bad" file itself even looked fine - all nice colours). Compiling fails, of course, with one of the glorious C++ error messages saying that std::string does not exist inside of a standard library. That's how I finally started suspecting some namespace stuff.



== Minimal example ==

* Create "New from template" CMake project
* Add file test.hpp
* contents of test.hpp (+ header guards)
namespace FOO
{
class BAR {};
* #include test.hpp
* / data types are not recognised or no error at all (bigger project)
  / missing brace marked inside of the "innocent" cpp file
Comment 1 Sven Brauch 2016-10-28 14:28:23 UTC
Probably there is a flag for clang which enables this warning. We could just add that flag to our command line, if we knew which one it was.
Comment 2 Justin Zobel 2022-10-26 03:06:59 UTC
Thank you for reporting this bug in KDE software. As it has been a while since this issue was reported, can we please ask you to see if you can reproduce the issue with a recent software version?

If you can reproduce the issue, please change the status to "REPORTED" when replying. Thank you!
Comment 3 Bug Janitor Service 2022-11-10 05:12:47 UTC
Dear Bug Submitter,

This bug has been in NEEDSINFO status with no change for at least
15 days. Please provide the requested information as soon as
possible and set the bug status as REPORTED. Due to regular bug
tracker maintenance, if the bug is still in NEEDSINFO status with
no change in 30 days the bug will be closed as RESOLVED > WORKSFORME
due to lack of needed information.

For more information about our bug triaging procedures please read the
wiki located here:
https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

If you have already provided the requested information, please
mark the bug as REPORTED so that the KDE team knows that the bug is
ready to be confirmed.

Thank you for helping us make KDE software even better for everyone!
Comment 4 Bug Janitor Service 2022-11-25 05:23:00 UTC
This bug has been in NEEDSINFO status with no change for at least
30 days. The bug is now closed as RESOLVED > WORKSFORME
due to lack of needed information.

For more information about our bug triaging procedures please read the
wiki located here:
https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

Thank you for helping us make KDE software even better for everyone!