dstep segfaults: Unhandled type kind cast(CXTypeKind)119 #98

ff2000 · 2016-10-23T08:44:31Z

I want to create D-bindings for https://launchpad.net/libtickit. Unfortunately it segfaults:

Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x00000000005a11c8 in dstep.translator.Type.translateType(dstep.translator.Context.Context, clang.c.Index.CXTypeKind, bool) ()
[Current thread is 1 (Thread 0x7f05a5744700 (LWP 31788))]
(gdb) bt
#0  0x00000000005a11c8 in dstep.translator.Type.translateType(dstep.translator.Context.Context, clang.c.Index.CXTypeKind, bool) ()
#1  0x000000000059eab5 in dstep.translator.Type.translateType(dstep.translator.Context.Context, clang.Cursor.Cursor, clang.Type.Type, bool, bool) ()
#2  0x00000000005a0502 in dstep.translator.Type.translatePointer(dstep.translator.Context.Context, clang.Cursor.Cursor, clang.Type.Type, bool, bool) ()
#3  0x000000000059e06b in dstep.translator.Type.translateType(dstep.translator.Context.Context, clang.Cursor.Cursor, clang.Type.Type, bool, bool) ()
#4  0x000000000059d4e9 in dstep.translator.Type.translateType(dstep.translator.Context.Context, clang.Cursor.Cursor, bool, bool) ()
#5  0x000000000059c0fc in dstep.translator.Translator.translateFunction(dstep.translator.Output.Output, dstep.translator.Context.Context, clang.Cursor.FunctionCursor, immutable(char)[], bool).__fo
reachbody7(ref clang.Cursor.ParamCursor) ()
#6  0x000000000055cd71 in clang.Visitor.ParamVisitor.opApply(int(ref clang.Cursor.ParamCursor) delegate).__foreachbody2(ref clang.Cursor.Cursor, ref clang.Cursor.Cursor) ()
#7  0x000000000055c41c in clang.Visitor.Visitor.visitorFunction(clang.c.Index.CXCursor, clang.c.Index.CXCursor, void*) ()
#8  0x00007f05b40fe210 in clang::cxcursor::CursorVisitor::Visit(CXCursor, bool) () from /usr/lib64/libclang.so.39
#9  0x00007f05b410174f in clang::cxcursor::CursorVisitor::VisitFunctionDecl(clang::FunctionDecl*) () from /usr/lib64/libclang.so.39
#10 0x00007f05b40ffb76 in clang::declvisitor::Base<clang::declvisitor::make_ptr, clang::cxcursor::CursorVisitor, bool>::Visit(clang::Decl*) () from /usr/lib64/libclang.so.39
#11 0x00007f05b40fe9a0 in clang::cxcursor::CursorVisitor::VisitChildren(CXCursor) () from /usr/lib64/libclang.so.39
#12 0x00007f05b4109e41 in clang_visitChildren () from /usr/lib64/libclang.so.39
#13 0x000000000055cceb in clang.Visitor.ParamVisitor.opApply(int(ref clang.Cursor.ParamCursor) delegate) ()
#14 0x000000000059b921 in dstep.translator.Translator.translateFunction(dstep.translator.Output.Output, dstep.translator.Context.Context, clang.Cursor.FunctionCursor, immutable(char)[], bool) ()
#15 0x0000000000599962 in dstep.translator.Translator.Translator.translateFunctionDecl(dstep.translator.Output.Output, clang.Cursor.Cursor, clang.Cursor.Cursor) ()
#16 0x0000000000598bbd in dstep.translator.Translator.Translator.translate(dstep.translator.Output.Output, clang.Cursor.Cursor, clang.Cursor.Cursor) ()
#17 0x00000000005986aa in dstep.translator.Translator.Translator.translateInGlobalScope(dstep.translator.Output.Output, clang.Cursor.Cursor, clang.Cursor.Cursor) ()
#18 0x0000000000598578 in dstep.translator.Translator.Translator.translateCursors().__foreachbody1(ref clang.Cursor.Cursor, ref clang.Cursor.Cursor) ()
#19 0x000000000055c9d8 in clang.Visitor.InOrderVisitor.opApply(int(ref clang.Cursor.Cursor, ref clang.Cursor.Cursor) delegate).__foreachbody3(ref clang.Cursor.Cursor, ref clang.Cursor.Cursor) ()
#20 0x000000000055c41c in clang.Visitor.Visitor.visitorFunction(clang.c.Index.CXCursor, clang.c.Index.CXCursor, void*) ()
#21 0x00007f05b40fe210 in clang::cxcursor::CursorVisitor::Visit(CXCursor, bool) () from /usr/lib64/libclang.so.39
#22 0x00007f05b4100460 in clang::cxcursor::CursorVisitor::handleDeclForVisitation(clang::Decl const*) () from /usr/lib64/libclang.so.39
#23 0x00007f05b4100514 in clang::cxcursor::CursorVisitor::VisitDeclContext(clang::DeclContext*) () from /usr/lib64/libclang.so.39
#24 0x00007f05b40fed92 in clang::cxcursor::CursorVisitor::VisitChildren(CXCursor) () from /usr/lib64/libclang.so.39
#25 0x00007f05b4109e41 in clang_visitChildren () from /usr/lib64/libclang.so.39
#26 0x000000000055c6d9 in clang.Visitor.InOrderVisitor.opApply(int(ref clang.Cursor.Cursor, ref clang.Cursor.Cursor) delegate) ()
#27 0x000000000059808e in dstep.translator.Translator.Translator.translateCursors() ()
#28 0x00000000005985a3 in dstep.translator.Translator.Translator.translateToString() ()
#29 0x0000000000597f02 in dstep.translator.Translator.Translator.translate() ()
#30 0x000000000055f0fe in dstep.driver.Application.ParseFile.startConversion() ()
#31 0x000000000055ebac in dstep.driver.Application.Application.startParsingFile(const(dstep.Configuration.Configuration), immutable(char)[], immutable(char)[]) ()
#32 0x000000000055f688 in std.parallelism.Task!(dstep.driver.Application.Application.startParsingFile(const(dstep.Configuration.Configuration), immutable(char)[], immutable(char)[]), dstep.Configu
ration.Configuration, immutable(char)[], immutable(char)[]).Task.impl(void*) ()
#33 0x00007f05b3c25dbb in std.parallelism.AbstractTask.job() () from /usr/lib64/libphobos2.so.0.71
#34 0x00007f05b3c25f78 in std.parallelism.TaskPool.doJob(std.parallelism.AbstractTask*) () from /usr/lib64/libphobos2.so.0.71
#35 0x00007f05b3c2602f in std.parallelism.TaskPool.doSingleTask() () from /usr/lib64/libphobos2.so.0.71
#36 0x00007f05b3d018f4 in core.thread.Thread.run() () from /usr/lib64/libphobos2.so.0.71
#37 0x00007f05b3d00aaf in thread_entryPoint () from /usr/lib64/libphobos2.so.0.71
#38 0x00007f05b36b4444 in start_thread (arg=0x7f05a5744700) at pthread_create.c:333
#39 0x00007f05b2cf192d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109

Using a debug-build I get the following assertion:

dstep: an unknown error occurred: core.exception.AssertError@/home/franz/src/dstep/dstep/translator/Type.d(501): Unhandled type kind cast(CXTypeKind)119
----------------
??:? _d_assert_msg [0x7c59e0b6]
/home/franz/src/dstep/dstep/translator/Type.d:501 immutable(char)[] dstep.translator.Type.translateType(dstep.translator.Context.Context, clang.c.Index.CXTypeKind, bool) [0x5a657c]
/home/franz/src/dstep/dstep/translator/Type.d:94 immutable(char)[] dstep.translator.Type.translateType(dstep.translator.Context.Context, clang.Cursor.Cursor, clang.Type.Type, bool, bool) [0x5a51de
]
/home/franz/src/dstep/dstep/translator/Type.d:363 immutable(char)[] dstep.translator.Type.translatePointer(dstep.translator.Context.Context, clang.Cursor.Cursor, clang.Type.Type, bool, bool) [0x5a
5dd9]
/home/franz/src/dstep/dstep/translator/Type.d:57 immutable(char)[] dstep.translator.Type.translateType(dstep.translator.Context.Context, clang.Cursor.Cursor, clang.Type.Type, bool, bool) [0x5a4fff
]
/home/franz/src/dstep/dstep/translator/Type.d:24 immutable(char)[] dstep.translator.Type.translateType(dstep.translator.Context.Context, clang.Cursor.Cursor, bool, bool) [0x5a4d63]
/home/franz/src/dstep/dstep/translator/Translator.d:348 int dstep.translator.Translator.translateFunction(dstep.translator.Output.Output, dstep.translator.Context.Context, clang.Cursor.FunctionCur
sor, immutable(char)[], bool).__foreachbody7(ref clang.Cursor.ParamCursor) [0x5a4308]
/home/franz/src/dstep/clang/Visitor.d:255 _D5clang7Visitor12ParamVisitor7opApplyMFDFKS5clang6Cursor11ParamCursorZiZ14__foreachbody2MFKS5clang6Cursor6CursorKS5clang6Cursor6CursorZi [0x572e54]
/home/franz/src/dstep/clang/Visitor.d:66 extern (C) clang.c.Index.CXChildVisitResult clang.Visitor.Visitor.visitorFunction(clang.c.Index.CXCursor, clang.c.Index.CXCursor, void*) [0x572450]
??:? [0x7c99d20f]
core.exception.AssertError@/home/franz/src/dstep/dstep/translator/Type.d(501): Unhandled type kind cast(CXTypeKind)119
----------------
??:? _d_assert_msg [0x7c59e0b6]
/home/franz/src/dstep/dstep/translator/Type.d:501 immutable(char)[] dstep.translator.Type.translateType(dstep.translator.Context.Context, clang.c.Index.CXTypeKind, bool) [0x5a657c]
/home/franz/src/dstep/dstep/translator/Type.d:94 immutable(char)[] dstep.translator.Type.translateType(dstep.translator.Context.Context, clang.Cursor.Cursor, clang.Type.Type, bool, bool) [0x5a51de
]
/home/franz/src/dstep/dstep/translator/Type.d:363 immutable(char)[] dstep.translator.Type.translatePointer(dstep.translator.Context.Context, clang.Cursor.Cursor, clang.Type.Type, bool, bool) [0x5a
5dd9]
/home/franz/src/dstep/dstep/translator/Type.d:57 immutable(char)[] dstep.translator.Type.translateType(dstep.translator.Context.Context, clang.Cursor.Cursor, clang.Type.Type, bool, bool) [0x5a4fff
]
/home/franz/src/dstep/dstep/translator/Type.d:24 immutable(char)[] dstep.translator.Type.translateType(dstep.translator.Context.Context, clang.Cursor.Cursor, bool, bool) [0x5a4d63]
/home/franz/src/dstep/dstep/translator/Translator.d:348 int dstep.translator.Translator.translateFunction(dstep.translator.Output.Output, dstep.translator.Context.Context, clang.Cursor.FunctionCur
sor, immutable(char)[], bool).__foreachbody7(ref clang.Cursor.ParamCursor) [0x5a4308]
/home/franz/src/dstep/clang/Visitor.d:255 _D5clang7Visitor12ParamVisitor7opApplyMFDFKS5clang6Cursor11ParamCursorZiZ14__foreachbody2MFKS5clang6Cursor6CursorKS5clang6Cursor6CursorZi [0x572e54]
/home/franz/src/dstep/clang/Visitor.d:66 extern (C) clang.c.Index.CXChildVisitResult clang.Visitor.Visitor.visitorFunction(clang.c.Index.CXCursor, clang.c.Index.CXCursor, void*) [0x572450]
??:? [0x7c99d20f]

The text was updated successfully, but these errors were encountered:

ciechowoj · 2016-10-23T08:47:03Z

Impressive SEGFAULT : ). Can you provide the dstep invocation?

ff2000 · 2016-10-23T08:51:21Z

:) Here you are:
~/src/dstep/bin/dstep -I/usr/lib64/gcc/x86_64-pc-linux-gnu/4.9.3/include/ ~/src/libtickit/include/tickit.h -o /tmp/tickit.d
Nothing special I think.

ciechowoj · 2016-10-23T09:02:08Z

Could you try this invocation:

~/src/dstep/bin/dstep 
-I<dstep_home>/resources/
-I/usr/lib64/gcc/x86_64-pc-linux-gnu/4.9.3/include/ 
~/src/libtickit/include/tickit.h -o /tmp/tickit.d

?

Replace <dstep_home> with full path to dstep (expansion of ~/src/dstep/).

ciechowoj · 2016-10-23T09:05:35Z

Are you sure you are using the most recent version of dstep (sorry, but I needed to ask this : )). I'm unable to reproduce the error on my system (Linux Mint)... What system are you using?

ff2000 · 2016-10-23T09:25:33Z

Adding dstep_home/resources to includes didn't help. I also switched from gcc-includes to those of llvm (using v3.9.0) - same result.
I am running Gentoo, dmd-2.071.1. Tried to build dstep with 2.067 but that seems to not be supported. dstep is directly from git. libtickit also is most recent bzr.
Btw.: I have the same issue with libvterm (from the same author as libtickit), vterm.h segfaults - but interestingly vterm_keycodes.h works. (Just in case you are intersted...)

ciechowoj · 2016-10-23T09:32:32Z

I am running Gentoo, dmd-2.071.1. Tried to build dstep with 2.067 but that seems to not be supported. dstep is directly from git. libtickit also is most recent bzr.
Btw.: I have the same issue with libvterm (from the same author as libtickit), vterm.h segfaults - but interestingly vterm_keycodes.h works. (Just in case you are intersted...)

Any information can be helpful. I'll see what I can do.

ff2000 · 2016-10-23T09:45:56Z

I updated to dmd-2.071.2 - same result.
Then I tried dmd-2.069.2, as it was mentioned as exact required dmd version (no "at least" and "compatible" here), which resulted in the same compilation error as 2.067 did:

$ dub build --arch=x86_64 --build=release --compiler=dmd-2.069                                          
Running pre-generate commands for dstep...
Performing "release" build using dmd-2.069 for x86_64.
dstep 0.2.2+commit.122.g3363bc5: building configuration "default"...
/home/franz/src/dstep/clang/Diagnostic.d(134,18): Error: basic type expected, not (
/home/franz/src/dstep/clang/Diagnostic.d(134,18): Error: function declaration without return type. (Note that constructors are always named 'this')
/home/franz/src/dstep/clang/Diagnostic.d(134,25): Error: semicolon expected to close alias declaration
/home/franz/src/dstep/clang/Diagnostic.d(134,25): Error: found '=>' instead of statement
dmd-2.069 failed with exit code 1.

Can this be fixed or should the README get updated to require a more recent dmd-version?

ciechowoj · 2016-10-23T09:50:49Z

It should work fine with v2.071.1 (at least it works in my case).

Can this be fixed or should the README get updated to require a more recent dmd-version?

Probably it should be fixed. However I''m not sure, but I suppose @jacob-carlborg will know.

I'll try to install Gentoo on virtual-box and I'll see if I can reproduce the bug then.

ff2000 · 2016-10-23T10:09:30Z

Gentoo is entirely built from source, so probably too much trouble for you simply to reproduce that bug (and due to the fact Gentoo is highly customized you might not be able to reproduce the issue then...)
I installed dmd prebuilt binary downloaded from dlang.org. And this also has that issue, so it most likely isn't related to the way dmd was built on Gentoo. As dstep worked just fine for everything else I threw at it this might be something really unique to my system... I will play around today and see if I can find out what's the issue here...

ciechowoj · 2016-10-23T11:23:46Z

You may be right about that gentoo installation... Anyway, could you run dstep --clang-version and show the output of the command?

ff2000 · 2016-10-23T11:43:17Z

One step closer :)
libvterm had issues when I cloned it from launchpad which was missing one commit from leonerds own hosted libvterm-repo [1]:

revno: 686
committer: Paul "LeoNerd" Evans <leonerd@leonerd.org.uk>
branch nick: libvterm
timestamp: Fri 2016-10-07 10:36:59 +0100
message:
  Pull VTermScreenCell.attrs out to its own named type
diff:
=== modified file 'include/vterm.h'
--- include/vterm.h     2015-10-03 19:24:36 +0000
+++ include/vterm.h     2016-10-07 09:36:59 +0000
@@ -234,10 +234,6 @@
 // ------------

 typedef struct {
-#define VTERM_MAX_CHARS_PER_CELL 6
-  uint32_t chars[VTERM_MAX_CHARS_PER_CELL];
-  char     width;
-  struct {
     unsigned int bold      : 1;
     unsigned int underline : 2;
     unsigned int italic    : 1;
@@ -247,7 +243,13 @@
     unsigned int font      : 4; /* 0 to 9 */
     unsigned int dwl       : 1; /* On a DECDWL or DECDHL line */
     unsigned int dhl       : 2; /* On a DECDHL line (1=top 2=bottom) */
-  } attrs;
+} VTermScreenCellAttrs;
+
+typedef struct {
+#define VTERM_MAX_CHARS_PER_CELL 6
+  uint32_t chars[VTERM_MAX_CHARS_PER_CELL];
+  char     width;
+  VTermScreenCellAttrs attrs;
   VTermColor fg, bg;
 } VTermScreenCell;

And magically dstep doesn't crash for me anymore on vterm.h!
So it might be that somehow my setup doesn't allow parsing of nested/unnamed structs. I did not find anything related in tickit.h, but termkey.h (which comes from libtermkey [2] which - you guessed it - is a related and necessary project also done by leonerd ;)) had a struct with a nested union. Pulling that out made termkey.h port successfully to D! But tickit.h still is failing. Grrr!!! I really would like to know what's different here because you seem to be able to convert everything just fine.
I now will start digging through the included headers, probably I can find other nested structs there (though AFACS there only were system (libc) headers left which I really do not want to change).

./bin/dstep --clang-version
clang version 3.9.0 (tags/RELEASE_390/final)

And a related question: Is it possible to get the exact line where dstep is crashing? It would really help alot here.

[1] http://bazaar.leonerd.org.uk/c/libvterm/
[2] http://bazaar.leonerd.org.uk/c/libtermkey/

jacob-carlborg · 2016-10-23T12:28:21Z

And a related question: Is it possible to get the exact line where dstep is crashing? It would really help alot here.

Didn't you have that in the debug build?

dstep: an unknown error occurred: core.exception.AssertError@/home/franz/src/dstep/dstep/translator/Type.d(501): Unhandled type kind cast(CXTypeKind)119

jacob-carlborg · 2016-10-23T12:31:05Z

Can this be fixed or should the README get updated to require a more recent dmd-version?

I don't really know which is the minimum supported version of DMD now, ciechowoj has done most of the recent development. Travis CI is configured to run 2.070.0. I'll give it a try to see which is the minimum version it will compile with. I'll update the readme file accordingly.

ciechowoj · 2016-10-23T13:36:17Z

Ok, with libclang 3.9.0 it is failing on my setup as well. There must be some difference between libclang 3.7 and libclang 3.9.

jacob-carlborg · 2016-10-23T13:41:17Z

It might be a new CXTypeKind that DStep currently doesn't know about.

ciechowoj · 2016-10-23T13:41:31Z

The line that triggers segfault is:

void tickit_term_await_started_tv(TickitTerm *tt, const struct timeval *timeout);

ciechowoj · 2016-10-23T13:41:53Z

in tickit.h

Probably there is something wrong with const struct timeval *timeout.

ciechowoj · 2016-10-23T14:32:25Z

It might be a new CXTypeKind that DStep currently doesn't know about.

You are right they introduced a new type kind CXType_Elaborated. I do not see how to fix it without checking the version of libclang...

jacob-carlborg · 2016-10-23T14:33:59Z

Keep up to date with libclang? I don't mind checking the version of libclang, but I would rather use static linking and only support the latest version.

ciechowoj · 2016-10-23T14:37:32Z

I don't mind checking the version of libclang,

So, I'll try to do this way.

but I would rather use static linking and only support the latest version.

Yeah, that would be nice, but as we were talking before about it, it isn't that trivial and would require a significant amount of work.

@ff2000 as a temporary fix you could try to use an older version of libclang (3.7 seems to work)...

jacob-carlborg · 2016-10-23T14:40:23Z

Yeah, that would be nice, but as we were talking before about it, it isn't that trivial and would require a significant amount of work.

Really? I tried to link with all static libraries in lib in the distribution of Clang and it works (with the additional linking of stdc++ and ncurses).

ciechowoj · 2016-10-23T14:41:39Z

And what about windows and MacOS ?

jacob-carlborg · 2016-10-23T14:42:45Z

That was on macOS (that's my main platform). I haven't tried on Linux or Windows, would it be any different?

ciechowoj · 2016-10-23T14:46:58Z

I'm worried that the standard distribution of LLVM doesn't provide precompiled static libraries.

Anyway, do you have an idea how to integrate it with build system? The only idea I can think of at the moment is to add a custom build step that downloads the LLVM binaries and links against them.

It there is no appropriate binaries we would need to build LLVM from sources, with and configure it correctly beforehand to get static libraries.

jacob-carlborg · 2016-10-23T14:57:13Z

I'm worried that the standard distribution of LLVM doesn't provide precompiled static libraries.

You mean for Windows? Or LLVM from a Linux dist repo? Hmm, the Windows exe does not ship with static libraries 😞.

Anyway, do you have an idea how to integrate it with build system? The only idea I can think of at the moment is to add a custom build step that downloads the LLVM binaries and links against them.

I haven't though of this yet, but we already download the LLVM binaries when running the tests.

It there is no appropriate binaries we would need to build LLVM from sources.

That would be a bit annoying but doable, at least on Posix.

ciechowoj · 2016-10-23T14:59:59Z

You mean for Windows? Or LLVM from a Linux dist repo? Hmm, the Windows exe does not ship with static libraries 😞.

That would be a bit annoying but doable, at least on Posix.

That what I meant saying "not that trivial" : )

ciechowoj · 2016-10-23T15:27:59Z

Hmm, what about distributing the .dll/.so with dstep? If I remember correctly windows will use .dll that is in the local directory? If not we could load the functions dynamically.

jacob-carlborg · 2016-10-23T15:32:30Z

Yeah, that could be an alternative. But then the user might move the executable without moving the dll. Isn't it possible to embed a dll into an executable?

ciechowoj · 2016-10-23T15:43:19Z

Isn't it possible to embed a dll into an executable?

I seems to be possible, at least here is one way to do this http://www.drdobbs.com/packing-dlls-in-your-exe/184416443 .

But then the user might move the executable without moving the dll.

The dstep binary is a bit coupled to its directory due to files in "resource" sub-directory anyway.

jacob-carlborg · 2016-10-23T15:49:11Z

The dstep binary is a bit coupled to its directory due to files in "resource" sub-directory anyway.

No, those files are embedded in the executable.

jacob-carlborg · 2016-10-23T15:53:22Z

I seems to be possible, at least here is one way to do this http://www.drdobbs.com/packing-dlls-in-your-exe/184416443 .

"The embedded DLLs get extracted out of the application the first time a function from the DLL is called". I had hoped it does not need to be extracted.

jacob-carlborg · 2016-10-23T15:55:31Z

@ff2000 I've updated the readme file to indicate the minimum required version of the compiler.

ciechowoj · 2016-10-23T15:57:45Z

"The embedded DLLs get extracted out of the application the first time a function from the DLL is called". I had hoped it does not need to be extracted.

I believe there is a way to do it without extraction.

jacob-carlborg · 2016-10-23T15:58:17Z

That would be cool.

ff2000 · 2016-10-23T16:13:22Z

Wow, seems there happened quite a lot while I was AFK :D
And also the github system ate the mail I sent, so here you are:

And a related question: Is it possible to get the exact line where dstep is crashing? It would really help alot here.

Didn't you have that in the debug build?

Sry for being unclear... I was talking about the line (and a little bit of context?) in the C header that I want to convert into D.
The mentioned output only shows information about the dstep-file the crash occured in.
In general a little bit more verbose output (-v didn't really give anything besides include dirs handling) would be awesome.

Downgrading system-llvm currently is no option as I need the most recent version.

Concerning bundling .dll/.so:
I think it is a bad idea, at least putting them into dstep git repo. Those are binary files, you can't "diff" them, so every update of the dll includes the full binary. Over time this blows up the repo. It would be better to put them into another repo, e.g. "dstep-deps", which also could be easily checked out during build time.
IMHO the better solution would be to download the most recent compatible binary llvm package. ycmd [1] does the same thing, but offers a compile time switch to use system llvm.
Another option would be to create binary packages for dstep, which IMHO makes sense only for releases or beta testing.

[1] https://github.com/Valloric/ycmd

jacob-carlborg · 2016-10-23T16:21:04Z

Sry for being unclear... I was talking about the line (and a little bit of context?) in the C header that I want to convert into D.

Hmm, not sure how easy that would be.

Downgrading system-llvm currently is no option as I need the most recent version.

Is that required in general for your system or for this specific translation? If an older version would work for this specific translation you could download the pre-compiled binaries here [1]. Should be enough to place libclang.so in the same directory as the dstep executable.

Concerning bundling .dll/.so:
I think it is a bad idea, at least putting them into dstep git repo

No one talked about bundling them in the repository. I talked about static linking and embed the DLL inside the executable.

Another option would be to create binary packages for dstep, which IMHO makes sense only for releases or beta testing

Not sure what you mean with binary packages be there are already pre-compiled binaries available [2].

[1] http://llvm.org/releases/download.html#3.7.0
[2] https://github.com/jacob-carlborg/dstep/releases/tag/v0.2.1

ff2000 · 2016-10-23T16:40:46Z

@jacob-carlborg thx for clarification. I didn't get your intention. I thought you plan something like this:
https://github.com/gecko0307/atrium
Look at the lib/lib64 dirs...

And I will download llvm-3.7 now. I was talking about downgrading the system-llvm, using llvm-3.7 upstream binary only for dstep should be no problem!

ciechowoj · 2016-10-23T18:22:50Z

Here https://github.com/ciechowoj/dstep/tree/issue98 is a branch with fix for the problem, I cannot create pull request because it doesn't link against anything but libclang3.9 : ( .

jacob-carlborg · 2016-10-23T18:30:33Z

Hmm, I see. Looks like we might be forced to bump the minimum requirements. I need to give this some thought.

jacob-carlborg · 2016-10-25T16:49:33Z

@ciechowoj was this caused by a elaborated type specifier? Isn't that a C++ feature?
@ff2000 can we get a sample of the code that fails?

ff2000 · 2016-10-25T18:19:30Z

On Sun, 23 Oct 2016 05:28:22 -0700, jacob-carlborg notifications@github.com wrote:

And a related question: Is it possible to get the exact line where dstep is crashing? It would really help alot here.

Didn't you have that in the debug build?

Sry for being unclear... I was talking about the line (and a little bit of context?) in the C header that I want to convert into D.
The mentioned output only shows information about the dstep-file the crash occured in.
In general a little bit more verbose output (-v didn't really give anything besides include dirs handling) would be awesome.

dstep: an unknown error occurred: core.exception.AssertError@/home/franz/src/dstep/dstep/translator/Type.d(501): Unhandled type kind cast(CXTypeKind)119

ciechowoj · 2016-10-25T18:55:04Z

@ciechowoj was this caused by a elaborated type specifier?

Yes.

Isn't that a C++ feature?

Yes and no.

From the libclang manual:

CXType_Elaborated:

Represents a type that was referred to using an elaborated type keyword.
E.g., struct S, or via a qualified name, e.g., N::M::type, or both.

It seems they added an indirection for types from tag namespace, when you use struct keyword (or enum, union...), it is 'wrapped' in CXType_Elaborated.

They added a new function:

CINDEX_LINKAGE CXType clang_Type_getNamedType   (   CXType  T   )

Retrieve the type named by the qualified-id.
If a non-elaborated type is passed in, an invalid type is returned.

To get underlying type from elaborated type. This feature is unavailable in earlier versions of libclang.

jacob-carlborg · 2016-10-25T18:59:22Z

Aha, I see.

ff2000 · 2016-11-13T20:20:08Z

Sorry for taking so long. I went ahead and tried the fix from @ciechowoj which didn't work for me. Compilation of dstep succeeded, running dstep didn't show an error, but importing tickit errored out:

tickit.d(352): Error: undefined identifier 'timeval'
tickit.d(369): Error: undefined identifier 'timeval'
tickit.d(527): Error: undefined identifier 'TickitRenderBufferSpanInfo_', did you mean struct 'TickitRenderBufferSpanInfo'?

I also tried to make dub pick up the llvm I downloaded, which was a complete disaster... dub --help is no help. man dub also doesn't tell me anything (because it doesn't exist). I tried DFLAGS which only passes flags for compilation but not the linker, for which LIB should help, which it didn't. I was already in the same situation about a year ago and at some point (after spending hours with dub) simply ditched D and went with C++, which has working build systems (which are build systems and not package managers). I know this is OT for dstep, but I really would like to get ahead with D and actually start writing programs and not only test apps, for which dstep would really help a lot!

ciechowoj · 2016-11-13T21:34:18Z

Sorry for taking so long. I went ahead and tried the fix from @ciechowoj which didn't work for me.
Compilation of dstep succeeded, running dstep didn't show an error, but importing tickit errored out:

Hmm, does dstep --clang-version return the version 3.9 ?

I also tried to make dub pick up the llvm I downloaded, which was a complete disaster... dub --help is no help.

I'm not sure what you are trying to achieve here. Make dstep to use LLVM 3.9?

ff2000 · 2016-11-14T09:14:01Z

@ciechowoj Sorry, it was late yesterday. I mixed two issues and didn't make it clear.

The error I posted was with your branch that fixes dstep with llvm-3.9. I went ahead and ran git clean -ff and magically the third error (TickitRenderBufferSpanInfo_) went away, the one with timeval stayed. I searched and simply imported core.sys.posix.sys.time, which fixed the issue. No idea if you can fix that, unfortunately core.stdc.time only imports parts of posix.sys.time :/
As dstep master doesn't work with llvm-3.9 (which is my distro-version) I downloaded official binaries for llvm-3.7. I can't find a way to make dub pick up that local copy for linking (#include works with DFLAGS), so I can't use dstep master.
Hope that was clear. For the moment I have a workaround (editing the auto-generated file), which finally enables me to start with the project :)

ciechowoj · 2016-11-14T10:17:38Z

@ciechowoj Sorry, it was late yesterday. I mixed two issues and didn't make it clear.

The error I posted was with your branch that fixes dstep with llvm-3.9. I went ahead and ran git clean -ff and magically the third error (TickitRenderBufferSpanInfo_) went away, the one with timeval stayed. I searched and simply imported core.sys.posix.sys.time, which fixed the issue. No idea if you can fix that, unfortunately core.stdc.time only imports parts of posix.sys.time :/

No problem, the late time haven't served me as well: I've misunderstood the first part of your post. I thought that those errors are clang errors from dstep, despite the fact you clearly said that the dstep tests had passes and the problem is with the usage of the result code (and that .d extension).

Truth said I haven't checked if the resulting .d code compiles, I only tested if dstep runs fine...

No idea if you can fix that, unfortunately core.stdc.time only imports parts of posix.sys.time :/

The translation of includes to imports is kind of broken in dstep now (I suspect that is the problem here), I have an idea how to fix this, but I do not have time to work on this at the moment...

I can't find a way to make dub pick up that local copy for linking (#include works with DFLAGS), so I can't use dstep master.

I'm not sure if it will work for you but you may try to change the paths in dub.json to your local paths.

"lflags-posix": ["-lclang", "-rpath", ".", "-rpath", "/usr/lib/llvm-3.7/lib", "-L.", "-L/usr/lib64/llvm", "-L/usr/lib/llvm-3.7/lib"],

Hope that was clear. For the moment I have a workaround (editing the auto-generated file), which finally enables me to start with the project :)

Nice to here that : )

jacob-carlborg · 2016-11-15T17:32:49Z

@ff2000

The error I posted was with your branch that fixes dstep with llvm-3.9. I went ahead and ran git clean -ff and magically the third error (TickitRenderBufferSpanInfo_) went away, the one with timeval stayed. I searched and simply imported core.sys.posix.sys.time, which fixed the issue. No idea if you can fix that, unfortunately core.stdc.time only imports parts of posix.sys.time :/

Currently DStep doesn't guarantee that it will generate modules that will import all other necessary modules. Converting the C include model to the D module system is very difficult thing to get 100% correct. Generated modules may require some minor manual tweaks, especially when it comes to adding import statements.

As dstep master doesn't work with llvm-3.9 (which is my distro-version) I downloaded official binaries for llvm-3.7. I can't find a way to make dub pick up that local copy for linking (#include works with DFLAGS), so I can't use dstep master.

If you put libclang.so in the same directory as DStep it should pick up that automatically. Although I'm not entirely sure if the DStep directory or the system directory has the highest priority.

jacob-carlborg · 2017-06-28T19:57:56Z

@ciechowoj I plan to bump the minimum requirement of libclang to 3.9. Did you have a fix for this bug?

ciechowoj · 2017-06-30T20:19:35Z

Maybe I rebase on Sunday.

jacob-carlborg · 2017-07-01T08:24:30Z

That would be great.

Fix #98: dstep segfaults: Unhandled type kind cast(CXTypeKind)119

mihails-strasuns mentioned this issue Feb 3, 2017

Arch Linux package and repository information in readme is incorrect. #120

Open

ciechowoj mentioned this issue Feb 7, 2017

LLVM 3.7 seems to be mandated… #122

Closed

This was referenced May 20, 2017

assert for struct with unions in master #132

Closed

Error on Fedora Rawhide #135

Closed

jacob-carlborg closed this as completed in dd66bb4 Jul 9, 2017

jacob-carlborg added a commit that referenced this issue Jul 9, 2017

Merge pull request #156 from ciechowoj/issue98

f0450af

Fix #98: dstep segfaults: Unhandled type kind cast(CXTypeKind)119

dstep segfaults: Unhandled type kind cast(CXTypeKind)119 #98

dstep segfaults: Unhandled type kind cast(CXTypeKind)119 #98

Comments

ff2000 commented Oct 23, 2016

ciechowoj commented Oct 23, 2016

ff2000 commented Oct 23, 2016

ciechowoj commented Oct 23, 2016 • edited Loading

ciechowoj commented Oct 23, 2016

ff2000 commented Oct 23, 2016

ciechowoj commented Oct 23, 2016

ff2000 commented Oct 23, 2016

ciechowoj commented Oct 23, 2016

ff2000 commented Oct 23, 2016

ciechowoj commented Oct 23, 2016

ff2000 commented Oct 23, 2016

jacob-carlborg commented Oct 23, 2016

jacob-carlborg commented Oct 23, 2016

ciechowoj commented Oct 23, 2016 • edited Loading

jacob-carlborg commented Oct 23, 2016

ciechowoj commented Oct 23, 2016

ciechowoj commented Oct 23, 2016 • edited Loading

ciechowoj commented Oct 23, 2016

jacob-carlborg commented Oct 23, 2016

ciechowoj commented Oct 23, 2016 • edited Loading

jacob-carlborg commented Oct 23, 2016

ciechowoj commented Oct 23, 2016

jacob-carlborg commented Oct 23, 2016

ciechowoj commented Oct 23, 2016 • edited Loading

jacob-carlborg commented Oct 23, 2016

ciechowoj commented Oct 23, 2016

ciechowoj commented Oct 23, 2016

jacob-carlborg commented Oct 23, 2016

ciechowoj commented Oct 23, 2016

jacob-carlborg commented Oct 23, 2016 • edited Loading

jacob-carlborg commented Oct 23, 2016

jacob-carlborg commented Oct 23, 2016

ciechowoj commented Oct 23, 2016

jacob-carlborg commented Oct 23, 2016

ff2000 commented Oct 23, 2016

jacob-carlborg commented Oct 23, 2016 • edited Loading

ff2000 commented Oct 23, 2016

ciechowoj commented Oct 23, 2016

jacob-carlborg commented Oct 23, 2016

jacob-carlborg commented Oct 25, 2016

ff2000 commented Oct 25, 2016

ciechowoj commented Oct 25, 2016

jacob-carlborg commented Oct 25, 2016

ff2000 commented Nov 13, 2016

ciechowoj commented Nov 13, 2016 • edited Loading

ff2000 commented Nov 14, 2016

ciechowoj commented Nov 14, 2016

jacob-carlborg commented Nov 15, 2016

jacob-carlborg commented Jun 28, 2017 • edited Loading

ciechowoj commented Jun 30, 2017

jacob-carlborg commented Jul 1, 2017

ciechowoj commented Oct 23, 2016 •

edited

Loading

ciechowoj commented Oct 23, 2016 •

edited

Loading

ciechowoj commented Oct 23, 2016 •

edited

Loading

ciechowoj commented Oct 23, 2016 •

edited

Loading

ciechowoj commented Oct 23, 2016 •

edited

Loading

jacob-carlborg commented Oct 23, 2016 •

edited

Loading

jacob-carlborg commented Oct 23, 2016 •

edited

Loading

ciechowoj commented Nov 13, 2016 •

edited

Loading

jacob-carlborg commented Jun 28, 2017 •

edited

Loading