[kdevelop] [Bug 292228] Reference not dropped when deducing template arguments
https://bugs.kde.org/show_bug.cgi?id=292228 Aaron Puchert changed: What|Removed |Added CC||aaronpuch...@alice-dsl.net --- Comment #5 from Aaron Puchert --- (In reply to Nicolás Alvarez from comment #4) > Well, I tried it in a current KDevelop with the new clang-based parser and > the code above shows both calls to foo as void foo( T x ). Is it dropping > references when doing type deduction? Probably (so I'll close the bug as > fixed), but I can't really tell, it's not showing any template parameters in > the tooltip anymore... Clang at least does the type deduction right. You can convince yourself on the command line by running it with "-fsyntax-only -Xclang -ast-dump". > Maybe showing template parameters in the tooltip is a feature that should be > brought back. Tough. The c-index that we use doesn't contain that information apparently. At least "c-index-test -index-file" on the example code spits out [startedTranslationUnit] [enteredMainFile]: [indexDeclaration]: kind: function-template | name: foo | USR: c:@FT@>1#Tfoo#t0.0#v# | lang: C++ | cursor: FunctionDecl=foo:1:27 | loc: 1:27 | semantic-container: [TU] | lexical-container: [TU] | isRedecl: 0 | isDef: 0 | isContainer: 0 | isImplicit: 0 [indexDeclaration]: kind: function | name: main | USR: c:@F@main# | lang: C | cursor: FunctionDecl=main:3:5 (Definition) | loc: 3:5 | semantic-container: [TU] | lexical-container: [TU] | isRedecl: 0 | isDef: 1 | isContainer: 1 | isImplicit: 0 [indexEntityReference]: kind: function-template | name: foo | USR: c:@FT@>1#Tfoo#t0.0#v# | lang: C++ | cursor: DeclRefExpr=foo:1:27 | loc: 6:4 | :: kind: function | name: main | USR: c:@F@main# | lang: C | container: [main:3:5] | refkind: direct | role: ref call [indexEntityReference]: kind: function-template | name: foo | USR: c:@FT@>1#Tfoo#t0.0#v# | lang: C++ | cursor: DeclRefExpr=foo:1:27 | loc: 7:4 | :: kind: function | name: main | USR: c:@F@main# | lang: C | container: [main:3:5] | refkind: direct | role: ref call As you can see the calls at 6:4 and 7:4 just contain a reference to the function template foo:1:27 (the numbers are line:column). One would think that the magic string tells us something alas another line foo(1.0); produces the same magic string: [indexEntityReference]: kind: function-template | name: foo | USR: c:@FT@>1#Tfoo#t0.0#v# | lang: C++ | cursor: DeclRefExpr=foo:1:27 | loc: 8:4 | :: kind: function | name: main | USR: c:@F@main# | lang: C | container: [main:3:5] | refkind: direct | role: ref call -- You are receiving this mail because: You are watching all bug changes.
[clazy] [Bug 432078] Crash when building with 'ENABLE_CLAZY'
https://bugs.kde.org/show_bug.cgi?id=432078 Aaron Puchert changed: What|Removed |Added CC||aaronpuch...@alice-dsl.net See Also||https://bugzilla.opensuse.o ||rg/show_bug.cgi?id=1181326 -- You are receiving this mail because: You are watching all bug changes.
[kdevelop] [Bug 426335] kdevelop symantic analysis opencl only partially working
https://bugs.kde.org/show_bug.cgi?id=426335 --- Comment #4 from Aaron Puchert --- (In reply to Aaron Puchert from comment #3) > Or we use -fdeclare-opencl-builtins. (https://reviews.llvm.org/D60763) Maybe not for now though, the flag is still considered experimental (you have to prefix it with -Xclang). It worked for me, but maybe it's not production-ready. There was a proposal to include the builtin header by default, but it got stalled because of this apparently. (https://reviews.llvm.org/D78979) -- You are receiving this mail because: You are watching all bug changes.
[kdevelop] [Bug 426335] kdevelop symantic analysis opencl only partially working
https://bugs.kde.org/show_bug.cgi?id=426335 Aaron Puchert changed: What|Removed |Added CC||aaronpuch...@alice-dsl.net --- Comment #3 from Aaron Puchert --- Or we use -fdeclare-opencl-builtins. (https://reviews.llvm.org/D60763) Supposedly the header takes very long to parse and this flag uses builtin declarations instead. Apparently one still has to include opencl-c-base.h though. -- You are receiving this mail because: You are watching all bug changes.
[kdevelop] [Bug 385768] segfault on parsing project: in clang::Decl::setInvalidDecl(bool) () from /usr/lib64/llvm/5/lib64/../lib64/libclangAST.so.5
https://bugs.kde.org/show_bug.cgi?id=385768 Aaron Puchert changed: What|Removed |Added CC||aaronpuch...@alice-dsl.net Status|CONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #9 from Aaron Puchert --- The bug has been fixed, and the fix will be in Clang 11. -- You are receiving this mail because: You are watching all bug changes.
[kdevelop] [Bug 421704] `#include ` with parser set to c++2a causes a crash
https://bugs.kde.org/show_bug.cgi?id=421704 Aaron Puchert changed: What|Removed |Added See Also||https://bugs.llvm.org/show_ ||bug.cgi?id=46790 --- Comment #8 from Aaron Puchert --- Just FYI, this has been reported again as https://bugs.llvm.org/show_bug.cgi?id=46790 which was fixed in https://github.com/llvm/llvm-project/commit/73c12bd8ff1a9cd8375a357ea06f171e127ec1b8. The fix will be in Clang 11. -- You are receiving this mail because: You are watching all bug changes.
[kdevelop] [Bug 417971] Kdevelop crashes during autocomplete
https://bugs.kde.org/show_bug.cgi?id=417971 Aaron Puchert changed: What|Removed |Added Resolution|WORKSFORME |UPSTREAM -- You are receiving this mail because: You are watching all bug changes.
[kdevelop] [Bug 422716] using gcc10 as compiler while including crashes kdevelop
https://bugs.kde.org/show_bug.cgi?id=422716 Aaron Puchert changed: What|Removed |Added See Also||https://bugs.llvm.org/show_ ||bug.cgi?id=46355 Status|REPORTED|RESOLVED Resolution|--- |DUPLICATE CC||aaronpuch...@alice-dsl.net --- Comment #3 from Aaron Puchert --- (In reply to Radu Benea from comment #0) > The reporter indicates this bug may be a duplicate of or related to bug > 421704. There may be more issues in Clang related to concepts and AST serialization, but I don't think it makes sense to track them separately for KDevelop. So I'll close this as duplicate. (In reply to Matt Whitlock from comment #2) > The following is a minimal reproducer of the crash... Thanks again, such minimal reproducers are extremely valuable for debugging the issue. *** This bug has been marked as a duplicate of bug 421704 *** -- You are receiving this mail because: You are watching all bug changes.
[kdevelop] [Bug 421704] `#include ` with parser set to c++2a causes a crash
https://bugs.kde.org/show_bug.cgi?id=421704 Aaron Puchert changed: What|Removed |Added CC||kitanat...@gmail.com --- Comment #7 from Aaron Puchert --- *** Bug 422716 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are watching all bug changes.
[kdevelop] [Bug 421704] `#include ` with parser set to c++2a causes a crash
https://bugs.kde.org/show_bug.cgi?id=421704 Aaron Puchert changed: What|Removed |Added Status|NEEDSINFO |RESOLVED See Also||https://bugs.llvm.org/show_ ||bug.cgi?id=46355 --- Comment #5 from Aaron Puchert --- (In reply to Matt Whitlock from comment #4) > For a minimal reproducer, see Bug 422716 Comment 2. Thanks, that's what I've been looking for. I've used this in my upstream bug report https://bugs.llvm.org/show_bug.cgi?id=46355, I hope you don't mind. -- You are receiving this mail because: You are watching all bug changes.
[kdevelop] [Bug 417971] Kdevelop crashes during autocomplete
https://bugs.kde.org/show_bug.cgi?id=417971 Aaron Puchert changed: What|Removed |Added Resolution|--- |WAITINGFORINFO Status|CONFIRMED |NEEDSINFO --- Comment #8 from Aaron Puchert --- It would be good to know if the original issue has the same root case as the example from comment 2, if not we might need to open another bug upstream. -- You are receiving this mail because: You are watching all bug changes.
[kdevelop] [Bug 421704] `#include ` with parser set to c++2a causes a crash
https://bugs.kde.org/show_bug.cgi?id=421704
Aaron Puchert changed:
What|Removed |Added
CC||aaronpuch...@alice-dsl.net
--- Comment #3 from Aaron Puchert ---
(In reply to Sven Brauch from comment #2)
> This is almost certainly a bug in libclang and needs to be reported there.
Agreed. This seems to be the deserialization of a stored AST, likely from a
preamble. For a reproducer, you can try working with PCHs
(http://clang.llvm.org/docs/PCHInternals.html). Since you're using the standard
library, you'll want to work without -cc1.
With test.hpp: "#include " and test.cpp empty, run
clang -fsyntax-only -std=c++2a test.hpp -Xclang -emit-pch >test.hpp.pch
clang -c -std=c++2a -include-pch test.hpp.pch test.cpp -o test.s
I can't reproduce this here, but I haven't installed the update to GCC 10 yet,
which also comes with a new libstdc++ that you're likely using here.
Concepts are pretty new, so I'm not surprised it's still a bit rough around the
edges. Looking at the code, we're here
(https://github.com/llvm/llvm-project/blob/llvmorg-10.0.0/clang/lib/Serialization/ASTReaderDecl.cpp#L2885-L2891):
if (TX->hasTypeConstraint() != TY->hasTypeConstraint())
return false;
if (TX->hasTypeConstraint()) {
const TypeConstraint *TXTC = TX->getTypeConstraint();
const TypeConstraint *TYTC = TY->getTypeConstraint();
if (TXTC->getNamedConcept() != TYTC->getNamedConcept()) // <---
return false;
with either TXTC or TYTC being nullptr. This is a bit strange, since
TX->hasTypeConstraint() and TY->hasTypeConstraint() are both true. But both
functions check different flags
(https://github.com/llvm/llvm-project/blob/llvmorg-10.0.0/clang/include/clang/AST/DeclTemplate.h#L1343-L1359):
const TypeConstraint *getTypeConstraint() const {
return TypeConstraintInitialized ? getTrailingObjects() :
nullptr;
}
bool hasTypeConstraint() const {
return HasTypeConstraint;
}
My recommendation (since we're talking about pretty recent code) would be to
try a current master build and see if you can reproduce the issue there. There
is bit of a chance that it is already fixed.
Since you're on Tumbleweed, you can also try 10.0.1-rc1
(https://build.opensuse.org/project/show/home:aaronpuchert:branches:devel:tools:compiler),
but sometimes people forget to port back bug fixes.
--
You are receiving this mail because:
You are watching all bug changes.
[kdevelop] [Bug 417971] Kdevelop crashes during autocomplete
https://bugs.kde.org/show_bug.cgi?id=417971 --- Comment #7 from Aaron Puchert --- Andrei, does your code also involve captures of variable-length arrays, or is it something else? I can see from your stack trace that an lambda init expression is nullptr (since #11 is at https://github.com/llvm/llvm-project/blob/llvmorg-9.0.1/clang/tools/libclang/CIndex.cpp#L3152 and the call to #10 has S=0x0), and I haven't seen that happen except for VLA type captures. One way to find out if you have VLAs is to compile with -Wvla. -- You are receiving this mail because: You are watching all bug changes.
[kdevelop] [Bug 417971] Kdevelop crashes during autocomplete
https://bugs.kde.org/show_bug.cgi?id=417971 Aaron Puchert changed: What|Removed |Added Status|REPORTED|CONFIRMED CC||aaronpuch...@alice-dsl.net See Also||https://bugs.llvm.org/show_ ||bug.cgi?id=46147 Ever confirmed|0 |1 --- Comment #6 from Aaron Puchert --- This can be reproduced without KDevelop. Create a file test.cpp with the example from comment 2 as content, then run "c-index-test -cursor-at=test.cpp:1:34 test.cpp", where c-index-test is a tool coming with Clang. This crashes for me as well. So I filed a bug report with Clang: https://bugs.llvm.org/show_bug.cgi?id=46147. -- You are receiving this mail because: You are watching all bug changes.
[kdevelop] [Bug 417679] kdevelop-pg-qt fails to build on s390x in Ubuntu 20.04 Focal
https://bugs.kde.org/show_bug.cgi?id=417679 Aaron Puchert changed: What|Removed |Added Ever confirmed|0 |1 CC||aaronpuch...@alice-dsl.net Status|REPORTED|CONFIRMED --- Comment #1 from Aaron Puchert --- Looks valid to me. The template is only declared in kdev-pg/kdev-pg-code-gen.h, while the definition is in kdev-pg/kdev-pg-code-gen.cpp. When the template is referenced from kdev-pg/kdev-pg-ast-gen.cpp, the definition isn't available, so the compiler can't instantiate the template. The solution would be to move the template to the header file or instantiate all necessary variants explicitly [1]. By the way, Clang can warn about situations like that with -Wundefined-func-template. [1] https://en.cppreference.com/w/cpp/language/function_template#Explicit_instantiation -- You are receiving this mail because: You are watching all bug changes.
[kdevelop] [Bug 413898] New: Why has KDevelop Find{LLVM, Clang}.cmake instead of using their CMake modules?
https://bugs.kde.org/show_bug.cgi?id=413898
Bug ID: 413898
Summary: Why has KDevelop Find{LLVM,Clang}.cmake instead of
using their CMake modules?
Product: kdevelop
Version: git master
Platform: Other
OS: Linux
Status: REPORTED
Severity: normal
Priority: NOR
Component: general
Assignee: kdevelop-bugs-n...@kde.org
Reporter: aaronpuch...@alice-dsl.net
Target Milestone: ---
Upstream LLVM/Clang provide CMake modules that provide all libraries as targets
to link against, these are by default installed into
/cmake/{llvm,clang}/. They can also be used from a local LLVM/Clang
build by setting LLVM_DIR=/lib/cmake/llvm and
Clang_DIR=/lib/cmake/clang.
Why don't we use that instead of maintaining our own Find{LLVM,Clang}.cmake?
--
You are receiving this mail because:
You are watching all bug changes.
[kdevelop] [Bug 409041] KDevelop shows wrong data type in tooltip
https://bugs.kde.org/show_bug.cgi?id=409041
Aaron Puchert changed:
What|Removed |Added
Ever confirmed|0 |1
CC||aaronpuch...@alice-dsl.net
Status|REPORTED|CONFIRMED
--- Comment #2 from Aaron Puchert ---
I can reproduce this. When I hover over either of the bitmask members, it also
highlights the bitmask in u.bitmask. The tool tips show no "Container:",
probably because these are unnamed structs/unions. When I give them names,
everything is fine. So I assume something is wrong with our handling of unnamed
structs, probably because they seem to be represented by empty strings.
For example, `typedef struct {} tp;` is
|-RecordDecl 0x101d5e8 <:1:9, col:17> col:9 struct definition
`-TypedefDecl 0x107a5f8 col:19 tp 'struct tp':'tp'
`-ElaboratedType 0x107a5a0 'struct tp' sugar
`-RecordType 0x101d660 'tp'
`-Record 0x101d5e8 ''
while `typedef struct X {} tp;` is
|-RecordDecl 0x109b5e8 <:1:9, col:19> col:16 struct X definition
`-TypedefDecl 0x10f85b8 col:21 tp 'struct X':'struct X'
`-ElaboratedType 0x10f8560 'struct X' sugar
`-RecordType 0x109b660 'struct X'
`-Record 0x109b5e8 'X'
--
You are receiving this mail because:
You are watching all bug changes.
[kdevelop] [Bug 387391] Random responses from the C/C++ language support when using symbolic links to CMake sub-projects.
https://bugs.kde.org/show_bug.cgi?id=387391 Aaron Puchert <aaronpuch...@alice-dsl.net> changed: What|Removed |Added CC||aaronpuch...@alice-dsl.net --- Comment #24 from Aaron Puchert <aaronpuch...@alice-dsl.net> --- I think this is a hard problem. We're running into a fundamental issue with symlinks here. KDevelop uses paths to identify files. Comparing paths is already hard enough because of "..", and that is used quite heavily. (Try compiling any file with gcc or clang with option -v, and you're probably going to find ".." in the default include paths.) But it gets really problematic with symlinks. (See http://harmful.cat-v.org/software/symlinks for someone ranting about symlinks.) Right now, the flags passed to the parser depend on the path. (Specifically, files outside the project tree are parsed without project-specific flags, like certain include directories you've set.) Even that is a compromise, because a file could be compiled with different flags for different targets. But for an IDE that compromise is Ok, I guess. However, when using symlinks, the same file could have different paths, and thus different flags. I guess this is what happens here: the file is at the same time inside and outside the source tree, so sometimes you get the include directories, sometimes you don't. But what do we expect? Should the flags be associated with a path, or some kind of canonical path, or an inode number? Should symlinks be resolved for that path? It seems you want a file to be treated as if it were inside the project, although it technically isn't. What if someone opens the file via the symlink-free path outside of the project? Should it still be parsed as part of the project? This seems like a difficult question that needs to be answered before we can think about writing a patch. Maybe I'm not clever enough, but it doesn't seem obvious to me how to get this working with symlinks without breaking other things. By the way, small nitpick: symlinks don't point to inodes, as you wrote in #c9, but to (relative or absolute) paths. -- You are receiving this mail because: You are watching all bug changes.
[kdevelop] [Bug 386388] kdevelop crash when opening a project containing javascript files [GccLikeCompiler::includes]
https://bugs.kde.org/show_bug.cgi?id=386388 --- Comment #13 from Aaron Puchert <aaronpuch...@alice-dsl.net> --- The crash came with some Q_UNREACHABLE()s I added, and only after 5.1 was released. The only problem (if any) on 5.1 is that the C++ compiler's include directories are passed to the QmlJS parser, but that didn't seem to lead to any problems. There should be no crash though. -- You are receiving this mail because: You are watching all bug changes.
[kdevelop] [Bug 386388] kdevelop crash when opening a project containing javascript files [GccLikeCompiler::includes]
https://bugs.kde.org/show_bug.cgi?id=386388 --- Comment #11 from Aaron Puchert <aaronpuch...@alice-dsl.net> --- I think this has been fixed, but I can't close the bug. Maybe someone with the appropriate permissions could do that. -- You are receiving this mail because: You are watching all bug changes.
[kdevelop] [Bug 386388] kdevelop crash when opening a project containing javascript files [GccLikeCompiler::includes]
https://bugs.kde.org/show_bug.cgi?id=386388 --- Comment #8 from Aaron Puchert <aaronpuch...@alice-dsl.net> --- The issue should now be fixed in master. Please check that it works for you. -- You are receiving this mail because: You are watching all bug changes.
[kdevelop] [Bug 386388] kdevelop crash when opening a project containing javascript files [GccLikeCompiler::includes]
https://bugs.kde.org/show_bug.cgi?id=386388 --- Comment #7 from Aaron Puchert <aaronpuch...@alice-dsl.net> --- Possible fixes: https://phabricator.kde.org/D8653, https://phabricator.kde.org/D8654. I tested both on the attached project, and there is no more crash with either one. Neither is particularly beautiful, but that's because the DefinesAndIncludesManager is mostly designed around C++ with other languages as afterthought. There is probably a better solution, but that needs more time. -- You are receiving this mail because: You are watching all bug changes.
[kdevelop] [Bug 386388] kdevelop crash when opening a project containing javascript files [GccLikeCompiler::includes]
https://bugs.kde.org/show_bug.cgi?id=386388 --- Comment #6 from Aaron Puchert <aaronpuch...@alice-dsl.net> --- Another solution would be to ignore files of type `Utils::Other` in CompilerProvider::includes/defines. The entire design is a bit problematic, because the QmlJS plugin asks the DefinesAndIncludesManager for include directories, but that manager is somehow tied to the idea of using the configured compiler (GCC/Clang/MSVC) to provide additional includes and defines. However, the configured compiler is obviously only used for C/C++ and similar languages, not QmlJS. Before this change, the standard include directories for GCC/Clang (/usr/include and so on) were used to parse QmlJS files, which I guess is not intended. (Or is it?) -- You are receiving this mail because: You are watching all bug changes.
[kdevelop] [Bug 386388] kdevelop crash when opening a project containing javascript files [GccLikeCompiler::includes]
https://bugs.kde.org/show_bug.cgi?id=386388 Aaron Puchert <aaronpuch...@alice-dsl.net> changed: What|Removed |Added CC||aaronpuch...@alice-dsl.net --- Comment #5 from Aaron Puchert <aaronpuch...@alice-dsl.net> --- I think we need to restrict to project-specific and user-defined includes in the constructor QmlJsParseJob::QmlJsParseJob. So replace IDefinesAndIncludesManager::manager()->includes(...) by IDefinesAndIncludesManager::manager()->includes(..., IDefinesAndIncludesManager::ProjectSpecific | IDefinesAndIncludesManager::UserDefined) The compiler-specific includes only make sense if we actually have a compiler backend that can provide them. (Right now ICompiler is implemented by NoCompiler, GccLikeCompiler, and MsvcCompiler - so no compiler for QML JS here.) -- You are receiving this mail because: You are watching all bug changes.
