Bug 279699 - C++11 lambdas: visibility/capture-lists not handled correctly
Summary: C++11 lambdas: visibility/capture-lists not handled correctly
Status: RESOLVED FIXED
Alias: None
Product: kdevelop
Classification: Unclassified
Component: Language Support: CPP (old) (show other bugs)
Version: git master
Platform: Unlisted Binaries Linux
: NOR minor (vote)
Target Milestone: ---
Assignee: kdevelop-bugs-null
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-08-08 22:09 UTC by Jörg Pfähler
Modified: 2018-03-25 22:36 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 Jörg Pfähler 2011-08-08 22:09:30 UTC
Version:           git master (using KDE 4.7.0) 
OS:                Linux

Consider the following code:

int i;
std::function<void (int)> f = [] (int i){i = 0;};

kdevelop now highlights the i outside of the lambda at the same time as the one inside the lambda (but not that one in the argument list). This is clearly wrong (or at least misleading) since the i in the argument list is the same as the one in the body, but not the same as the global one.

Another related bug/feature request is the following:

int i;
std::function<void ()> f = [&i] (){i = 0;};

I would except now, that the i in the capture list is highlighted the same way as the i in outside and inside the lambda.

Reproducible: Always

Steps to Reproduce:
-


Expected Results:  
-
Comment 1 Milian Wolff 2011-08-09 09:24:24 UTC
yep, needs proper DUChain support.

thanks for the report
Comment 2 Milian Wolff 2012-01-18 23:43:45 UTC
Git commit 05b647a4d555c2e406a08b6b9babacdc4b6ef105 by Milian Wolff.
Committed on 18/01/2012 at 22:17.
Pushed by mwolff into branch '4.3'.

c++11 support: first work towards proper DUChain integration of lambda expressions

- a lambda expression now properly gets a function type associated
- the lambda declarator now is represented by a function context
which gets imported into the body of the lambda expression

known problems:
- the surrounding context is still implicitly imported into the
body context
- the return-type is not properly computed in cases where no
explicit trailing return type is given but only a single
return statement in the body instead
- lambda captures are still not handled at all

M  +16   -0    languages/cpp/cppduchain/contextbuilder.cpp
M  +1    -0    languages/cpp/cppduchain/contextbuilder.h
M  +23   -0    languages/cpp/cppduchain/expressionvisitor.cpp
M  +1    -0    languages/cpp/cppduchain/expressionvisitor.h
M  +1    -0    languages/cpp/cppduchain/tests/test_duchain.h
M  +45   -0    languages/cpp/cppduchain/tests/test_duchain_cpp2011.cpp

http://commits.kde.org/kdevelop/05b647a4d555c2e406a08b6b9babacdc4b6ef105
Comment 3 Milian Wolff 2012-01-18 23:43:45 UTC
Git commit 40bd4b6057be525905a14f953900dc1b53eef900 by Milian Wolff.
Committed on 18/01/2012 at 23:09.
Pushed by mwolff into branch '4.3'.

c++11 support: properly report uses for lamba captures

M  +17   -0    languages/cpp/cppduchain/expressionvisitor.cpp
M  +1    -0    languages/cpp/cppduchain/expressionvisitor.h
M  +1    -0    languages/cpp/cppduchain/tests/test_duchain.h
M  +37   -1    languages/cpp/cppduchain/tests/test_duchain_cpp2011.cpp
M  +1    -1    languages/cpp/parser/ast.h
M  +4    -2    languages/cpp/parser/parser.cpp

http://commits.kde.org/kdevelop/40bd4b6057be525905a14f953900dc1b53eef900
Comment 4 Milian Wolff 2012-01-18 23:57:57 UTC
proper visibility/capture support looks tough, lets see when I can manage this. the current situation should be better already though I hope.
Comment 5 Kevin Funk 2018-03-25 22:36:56 UTC
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.