I’m working on extracting information from .swiftmodule files. Currently I can read all blocks and records but I’m having trouble identifying all DECLs in the DECLS_AND_TYPES_BLOCK. Below is a bcanalyzer dump of a swifmodule file created from this one line of code:
class Example {}
A couple questions:
• The DECL_OFFSETS record contains 6 indexes but I only count 5 DECLs (class, destructor, constructor, 2 param). Where is the 6th?
• According to documentation, the DECL_OFFSETS point to records in the DECLS_AND_TYPES_BLOCK blob but offset indexes show below (the “op” attributes) are larger than the blob length. Where do the indexes start from?
Sorry if this is the wrong place to ask and thanks for any help,
Aaron
What are you trying to do exactly ? Have you considered reading the decls with a tool using the C++ APIs (load a module and iterate over the decls) ?
I think that would be easier and more future-proof.
···
On Aug 22, 2017, at 11:57 AM, Coder via swift-dev <swift-dev@swift.org> wrote:
Hello,
I’m working on extracting information from .swiftmodule files. Currently I can read all blocks and records but I’m having trouble identifying all DECLs in the DECLS_AND_TYPES_BLOCK. Below is a bcanalyzer dump of a swifmodule file created from this one line of code:
class Example {}
A couple questions:
• The DECL_OFFSETS record contains 6 indexes but I only count 5 DECLs (class, destructor, constructor, 2 param). Where is the 6th?
• According to documentation, the DECL_OFFSETS point to records in the DECLS_AND_TYPES_BLOCK blob but offset indexes show below (the “op” attributes) are larger than the blob length. Where do the indexes start from?
Sorry if this is the wrong place to ask and thanks for any help,
Aaron
Yeah, it’s important to keep in mind we don’t have a stable module format right now, so anything developed Swift 4 will likely need to be revised again with the next version.
The C++ API is not stable either, but approach could be to dump the ‘generated interface’ using swift-ide-tool or similar, and parse the text. Also, it’s worth taking a look at swift-api-digester too.
Slava
···
On Aug 24, 2017, at 4:35 PM, Argyrios Kyrtzidis via swift-dev <swift-dev@swift.org> wrote:
Hi,
What are you trying to do exactly ? Have you considered reading the decls with a tool using the C++ APIs (load a module and iterate over the decls) ?
I think that would be easier and more future-proof.
On Aug 22, 2017, at 11:57 AM, Coder via swift-dev <swift-dev@swift.org> wrote:
Hello,
I’m working on extracting information from .swiftmodule files. Currently I can read all blocks and records but I’m having trouble identifying all DECLs in the DECLS_AND_TYPES_BLOCK. Below is a bcanalyzer dump of a swifmodule file created from this one line of code:
class Example {}
A couple questions:
• The DECL_OFFSETS record contains 6 indexes but I only count 5 DECLs (class, destructor, constructor, 2 param). Where is the 6th?
• According to documentation, the DECL_OFFSETS point to records in the DECLS_AND_TYPES_BLOCK blob but offset indexes show below (the “op” attributes) are larger than the blob length. Where do the indexes start from?
Sorry if this is the wrong place to ask and thanks for any help,
Aaron
I’m working on a swift target for haxe and want it to use the interfaces in swift modules. The haxe compiler is written in ocml and so far I’ve created an llvm bitcode parser in ocaml which can read all the blocks and records, then read through the DECLS_AND_TYPES_BLOCK and map DECLS to their parents.
My current guess is I’m not understanding how DECLs (like Int) that come from outside the module file work and maybe something to do with XREFs.
I do understand the module format will change and am fine with making changes later.
I’ll definitely take a look at those tools.
Thanks for the help,
Aaron
···
On Aug 24, 2017, at 5:56 PM, Slava Pestov <spestov@apple.com> wrote:
Yeah, it’s important to keep in mind we don’t have a stable module format right now, so anything developed Swift 4 will likely need to be revised again with the next version.
The C++ API is not stable either, but approach could be to dump the ‘generated interface’ using swift-ide-tool or similar, and parse the text. Also, it’s worth taking a look at swift-api-digester too.
Slava
On Aug 24, 2017, at 4:35 PM, Argyrios Kyrtzidis via swift-dev <swift-dev@swift.org> wrote:
Hi,
What are you trying to do exactly ? Have you considered reading the decls with a tool using the C++ APIs (load a module and iterate over the decls) ?
I think that would be easier and more future-proof.
On Aug 22, 2017, at 11:57 AM, Coder via swift-dev <swift-dev@swift.org> wrote:
Hello,
I’m working on extracting information from .swiftmodule files. Currently I can read all blocks and records but I’m having trouble identifying all DECLs in the DECLS_AND_TYPES_BLOCK. Below is a bcanalyzer dump of a swifmodule file created from this one line of code:
class Example {}
A couple questions:
• The DECL_OFFSETS record contains 6 indexes but I only count 5 DECLs (class, destructor, constructor, 2 param). Where is the 6th?
• According to documentation, the DECL_OFFSETS point to records in the DECLS_AND_TYPES_BLOCK blob but offset indexes show below (the “op” attributes) are larger than the blob length. Where do the indexes start from?
Sorry if this is the wrong place to ask and thanks for any help,
Aaron
I’m working on a swift target for haxe and want it to use the interfaces in swift modules. The haxe compiler is written in ocml and so far I’ve created an llvm bitcode parser in ocaml which can read all the blocks and records, then read through the DECLS_AND_TYPES_BLOCK and map DECLS to their parents.
My current guess is I’m not understanding how DECLs (like Int) that come from outside the module file work and maybe something to do with XREFs.
I do understand the module format will change and am fine with making changes later.
You say this, but... I really hate for you to spend a lot of time on something that is so low-level and that is so likely to be unstable. I think it would make a lot more sense to write a C API to the AST and talk to it over the OCaml FFI. Or if you really want to avoid the FFI, you could take our current ASTDumper output, which is currently pseudo-machine-readable, and make it actually machine-readable. The elegant approach there would be to take the entire dumper and remove its pervasive dependence on an output stream; instead, it would be rewritten to make calls on a SAX-like streaming interface, and there would just be a standard implementation that formatted things as XML / JSON / our weird s-expression format.
John.
···
On Aug 25, 2017, at 1:41 AM, Coder via swift-dev <swift-dev@swift.org> wrote:
I’ll definitely take a look at those tools.
Thanks for the help,
Aaron
On Aug 24, 2017, at 5:56 PM, Slava Pestov <spestov@apple.com> wrote:
Yeah, it’s important to keep in mind we don’t have a stable module format right now, so anything developed Swift 4 will likely need to be revised again with the next version.
The C++ API is not stable either, but approach could be to dump the ‘generated interface’ using swift-ide-tool or similar, and parse the text. Also, it’s worth taking a look at swift-api-digester too.
Slava
On Aug 24, 2017, at 4:35 PM, Argyrios Kyrtzidis via swift-dev <swift-dev@swift.org> wrote:
Hi,
What are you trying to do exactly ? Have you considered reading the decls with a tool using the C++ APIs (load a module and iterate over the decls) ?
I think that would be easier and more future-proof.
On Aug 22, 2017, at 11:57 AM, Coder via swift-dev <swift-dev@swift.org> wrote:
Hello,
I’m working on extracting information from .swiftmodule files. Currently I can read all blocks and records but I’m having trouble identifying all DECLs in the DECLS_AND_TYPES_BLOCK. Below is a bcanalyzer dump of a swifmodule file created from this one line of code:
class Example {}
A couple questions:
• The DECL_OFFSETS record contains 6 indexes but I only count 5 DECLs (class, destructor, constructor, 2 param). Where is the 6th?
• According to documentation, the DECL_OFFSETS point to records in the DECLS_AND_TYPES_BLOCK blob but offset indexes show below (the “op” attributes) are larger than the blob length. Where do the indexes start from?
Sorry if this is the wrong place to ask and thanks for any help,
Aaron
… I would love it if ASTDumper supported a Clang-like tree view in addition to (or instead of, if we also get JSON output?) the faux s-expression output. I know I’m supposed to like Lisp, but I personally find our dump output rather hard to read.
Slava
···
On Aug 24, 2017, at 10:56 PM, John McCall via swift-dev <swift-dev@swift.org> wrote:
Or if you really want to avoid the FFI, you could take our current ASTDumper output, which is currently pseudo-machine-readable, and make it actually machine-readable. The elegant approach there would be to take the entire dumper and remove its pervasive dependence on an output stream; instead, it would be rewritten to make calls on a SAX-like streaming interface, and there would just be a standard implementation that formatted things as XML / JSON / our weird s-expression format.
Yeah, it would be a great design goal that this output could be fed into various standard visualization tools.
John.
···
On Aug 25, 2017, at 2:34 AM, Slava Pestov <spestov@apple.com> wrote:
On Aug 24, 2017, at 10:56 PM, John McCall via swift-dev <swift-dev@swift.org <mailto:swift-dev@swift.org>> wrote:
Or if you really want to avoid the FFI, you could take our current ASTDumper output, which is currently pseudo-machine-readable, and make it actually machine-readable. The elegant approach there would be to take the entire dumper and remove its pervasive dependence on an output stream; instead, it would be rewritten to make calls on a SAX-like streaming interface, and there would just be a standard implementation that formatted things as XML / JSON / our weird s-expression format.
… I would love it if ASTDumper supported a Clang-like tree view in addition to (or instead of, if we also get JSON output?) the faux s-expression output. I know I’m supposed to like Lisp, but I personally find our dump output rather hard to read.
You say this, but... I really hate for you to spend a lot of time on something that is so low-level and that is so likely to be unstable. I think it would make a lot more sense to write a C API to the AST and talk to it over the OCaml FFI. Or if you really want to avoid the FFI, you could take our current ASTDumper output, which is currently pseudo-machine-readable, and make it actually machine-readable. The elegant approach there would be to take the entire dumper and remove its pervasive dependence on an output stream; instead, it would be rewritten to make calls on a SAX-like streaming interface, and there would just be a standard implementation that formatted things as XML / JSON / our weird s-expression format.
Yes, I would like to avoid FFI.
The second option could work well. I’ll look into it more. One benefit of not using ASTDumper is that haxe could generate swift without needing external tools.