[swift-dev] swift module format

2017-08-22 Thread Coder via swift-dev
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




- bcanalyzer dump -



  
 blob data = 'tool'
 blob data = '3.1/Apple Swift 
version 3.1 (swiftlang-802.0.53 clang-802.0.42)'
 blob data = 'x86_64-apple-macosx10.9'

  

  
  
 blob data = 'Swift'
 blob data = 'SwiftOnoneSupport'
  
  
  
  
  
  
 record string = ''



 record string = ''



 record string = ''
















 
record string = ''


  
  
 blob data = unprintable, 30 bytes.
  
  




 record string = ''
 record string = ''
 record string = 'T'
 record string = ''
 blob data = unprintable, 40 bytes.
 blob data = unprintable, 44 bytes.
  

___
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev


Re: [swift-dev] swift module format

2017-08-24 Thread Coder via swift-dev
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  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 
>>  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  
>>> 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
>>> 
>>> 
>>> 
>>> 
>>> - bcanalyzer dump -
>>> 
>>> 
>>> 
>>> 
>>>   blob data = 'tool'
>>>   blob data = '3.1/Apple Swift 
>>> version 3.1 (swiftlang-802.0.53 clang-802.0.42)'
>>>   blob data = 'x86_64-apple-macosx10.9'
>>>  
>>>
>>>  
>>> 
>>> 
>>>   blob data = 'Swift'
>>>   blob data = 'SwiftOnoneSupport'
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>>  >> op8=1/> record string = ''
>>>  
>>>  
>>>  
>>>   record string = ''
>>>  
>>>  
>>>  
>>>  >> op7=0 op8=3 op9=0 op10=2/> record string = ''
>>>  
>>>  
>>>  
>>>  
>>>  
>>>  
>>>  
>>>  
>>>  
>>>  
>>>  
>>>  
>>>  
>>>  
>>>  
>>>  
>>>   
>>> record string = ''
>>>  
>>>  
>>> 
>>> 
>>>   blob data = unprintable, 30 bytes.
>>> 
>>> 
>>>  >> op5=74671/>
>>>  >> op5=74375 op6=74452/>
>>>  
>>>  
>>>   record string = ''
>>>   record string = ''
>>>   record string = 'T'
>>>   record string = ''
>>>   blob data = unprintable, 40 bytes.
>>>   blob data = unprintable, 44 bytes.
>>> 
>>> 
>>> ___
>>> swift-dev mailing list
>>> swift-dev@swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-dev
>> 
>> ___
>> swift-dev mailing list
>> swift-dev@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-dev
> 

___
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev


Re: [swift-dev] swift module format

2017-08-27 Thread Coder via swift-dev
> 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.

Thanks again, the info is very helpful.

Aaron
___
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev