Bug 326626 - Semantic analysis does not find clock_gettime in C/C++ code
Summary: Semantic analysis does not find clock_gettime in C/C++ code
Status: RESOLVED FIXED
Alias: None
Product: kdevelop
Classification: Applications
Component: Language Support: CPP (old) (other bugs)
Version First Reported In: 4.5.0
Platform: Gentoo Packages Linux
: NOR normal
Target Milestone: ---
Assignee: kdevelop-bugs-null
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-10-25 11:58 UTC by Gerhard Gappmeier
Modified: 2016-01-23 20:36 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed/Implemented In:
Sentry Crash Report:


Attachments
Sample code to reproduce the issue. (20.45 KB, application/x-gzip)
2013-10-25 11:59 UTC, Gerhard Gappmeier
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Gerhard Gappmeier 2013-10-25 11:58:52 UTC
I attached the most simple program to reproduce the problem.
By using the "include <time.h>" the semantic analysis should be able to find the clock_gettime definition, but it doesn't.
I verified that it compiles without warnings with -Wall -pedantic. No issues, so the code is fine.
The attachment also contains a screenshot of the problem.

Reproducible: Always

Steps to Reproduce:
1. Unpack the attachment bugdemo.tar.gz
2. Open it in KDevelop
3. press Build button
This should compile without issues.

Actual Results:  
Line 5 with clock_gettime is underlined yellow and shows "Problem in Semantic Analysis: Declaration not found: clock_gettime"

Expected Results:  
No semantic errors, because the code is correct.
Comment 1 Gerhard Gappmeier 2013-10-25 11:59:35 UTC
Created attachment 83108 [details]
Sample code to reproduce the issue.
Comment 2 Gerhard Gappmeier 2013-10-25 12:01:21 UTC
Kdevplatform is version 4.11.2
Comment 3 Milian Wolff 2013-10-25 13:23:12 UTC
Probably due to nasty macro environment merging issues. Opening time.h in KDevelop and pressing F5 makes the declaration visible, but reparsing it via a test file again makes it go away...
Comment 4 Andrey Cygankov 2016-01-23 19:02:46 UTC
I tried to reproduce the bug - it no longer valid.
Comment 5 Milian Wolff 2016-01-23 19:54:33 UTC
Esp. not in the clang-based KDevelop 5, closing this now with my usual text for that:

Hello!

We are working on a new clang-based C/C++ language plugin for KDevelop 5 which
supersedes the old C++ plugin in KDevelop 4. See e.g.:
https://www.kdevelop.org/news/first-beta-release-kdevelop-500-available

Due to a lack of manpower, we cannot fix bugs in the old C++ plugin. We rather
want to supply a good Clang based C++ experience for KDevelop 5 than wasting
our time on the legacy C++ support for KDevelop 4.

With the new clang-based C/C++ language plugin, the bug presented here does not
occur. In my testing. For these reasons, I'll close this bug. Please stay tuned
for KDevelop 5.

If you think this bug is applicable to Clang/KDevelop 5, please reopen the
report and add new information on how to reproduce the bug there.

Sorry for the inconvenience, I hope you understand the reasoning above.

Cheers
Comment 6 Andrey Cygankov 2016-01-23 20:36:24 UTC
I am a participant GCI and I'm doing a task for testing bugs related to the c++ parser (https://codein.withgoogle.com/dashboard/task-instances/5823364513923072/). I have them tested for KDevelop 5 and note whether there was a bug in the new version.