Consider removing the space in Swift AST dump's "decl" attribute?


(Minsheng Liu) #1

Hi,

I notice that currently the dumped AST contains a parsing-unfriendly “decl”
attribute like this:

decl=fib.(file).func decl.b@fib.swift:4:9

The “func decl” contains a space but has nothing like a quote around it.
The whole AST output is delimited by spaces. I think this might create some
difficulty for someone who intends to parse the AST into another language
(like me). Is there any special purpose for adding a space like this,
rather than using something like “func_decl”? If not, should we change the
behavior to make it more parsing-friendly?

Minsheng


(Dmitri Gribenko) #2

Dumped AST is not meant to be machine parseable. The format is
subject to change (and it does frequently change). Please don't parse
it, your tools will break with new compiler releases.

Dmitri

···

On Sun, May 8, 2016 at 8:22 PM, Minsheng Liu via swift-dev <swift-dev@swift.org> wrote:

Hi,

I notice that currently the dumped AST contains a parsing-unfriendly “decl”
attribute like this:

decl=fib.(file).func decl.b@fib.swift:4:9

--
main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if
(j){printf("%d\n",i);}}} /*Dmitri Gribenko <gribozavr@gmail.com>*/


(Minsheng Liu) #3

Thanks for your information. However, what I intend to work on is a
Swift-to-JS translator, which I guess probably need to stick with the
upstream anyway. I think that make the output a bit more parsing-friendly
will not harm, will it?

Moreover, if you do not suggest parse the dumped AST, is there any
recommended way to reuse the compiler’s front-end?

Thank you,
Minsheng

Dmitri Gribenko <gribozavr@gmail.com>于2016年5月9日周一 上午9:10写道:

···

On Sun, May 8, 2016 at 8:22 PM, Minsheng Liu via swift-dev > <swift-dev@swift.org> wrote:
> Hi,
>
> I notice that currently the dumped AST contains a parsing-unfriendly
“decl”
> attribute like this:
>> decl=fib.(file).func decl.b@fib.swift:4:9

Dumped AST is not meant to be machine parseable. The format is
subject to change (and it does frequently change). Please don't parse
it, your tools will break with new compiler releases.

Dmitri

--
main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if
(j){printf("%d\n",i);}}} /*Dmitri Gribenko <gribozavr@gmail.com>*/


(Joe Groff) #4

It would be better to use an interface designed for programmatic consumption, either coding against Swift's libSwiftAST.a directly, or through our libIDE or SourceKit, than to use our debug dumping outputs.

-Joe

···

On May 9, 2016, at 10:00 AM, Minsheng Liu via swift-dev <swift-dev@swift.org> wrote:

Thanks for your information. However, what I intend to work on is a Swift-to-JS translator, which I guess probably need to stick with the upstream anyway. I think that make the output a bit more parsing-friendly will not harm, will it?
Moreover, if you do not suggest parse the dumped AST, is there any recommended way to reuse the compiler’s front-end?


(Dmitri Gribenko) #5

Thanks for your information. However, what I intend to work on is a
Swift-to-JS translator, which I guess probably need to stick with the
upstream anyway. I think that make the output a bit more parsing-friendly
will not harm, will it?

It will. Even if the format was parsing-friendly, it wouldn't be a
stable format. Making it parsing-friendly would be sort of making a
promise that we can't keep.

Moreover, if you do not suggest parse the dumped AST, is there any
recommended way to reuse the compiler’s front-end?

Using compiler APIs directly as Joe said is the best way. There are a
lot of AST details that are not represented in the textual dump.

Dmitri

···

On Mon, May 9, 2016 at 10:00 AM, Minsheng Liu <lambda@liu.ms> wrote:

--
main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if
(j){printf("%d\n",i);}}} /*Dmitri Gribenko <gribozavr@gmail.com>*/