Generate libSyntax API #10926
Generate libSyntax API #10926
Conversation
harlanhaskins
changed the title
|
@swift-ci please smoke test |
|
@swift-ci please smoke test |
harlanhaskins
force-pushed
the
json-born
branch
3 times, most recently
from
f586b70 to
14b88c7
Compare
|
@swift-ci please smoke test |
|
I have a question. Why mix JSON and gyb? gyb is already Python, and all the structures can be described in Python as well as in JSON. I think... |
|
They can, but it feels a little weird describing the entire AST structure directly in python...it feels more like the job of a declarative language. |
|
Think about the benefits. You can compile your grammar definitions and even write tests for it! Just thinking out loud… |
harlanhaskins
changed the title
|
@swift-ci please smoke test and merge |
|
@swift-ci please smoke test |
cmake/modules/AddSwift.cmake
Outdated
| @@ -1759,6 +1767,7 @@ function(add_swift_library name) | |||
| SDK ${sdk} | |||
| ARCHITECTURE ${arch} | |||
| DEPENDS ${SWIFTLIB_DEPENDS} | |||
| GYB_DEPENDS ${SWIFTLIB_GYB_DEPENDS} | |||
There was a problem hiding this comment.
Why is this needed? Why doesn't the normal depends just work?
There was a problem hiding this comment.
The normal DEPENDS won't regenerate gyb files if they're changed. This is actually no longer necessary for this PR, so I can remove it.
cmake/modules/AddSwift.cmake
Outdated
| @@ -574,6 +574,9 @@ endfunction() | |||
| # FILE_DEPENDS | |||
| # Additional files this library depends on. | |||
| # | |||
| # GYB_DEPENDS | |||
| # Additional files .gyb sorce files depend on. | |||
|
Also, generally we have not used gyb in the compiler itself. We have used it in the standard library. From what I remember adding gyb dependencies to the compiler is controversial. Can you bring this up for discussion on swift-dev? If we are going to add such a large dependency, we should make sure that no one has objections about it. My main feeling with gyb is if it is possible to not gyb we should. |
|
@swift-ci please smoke test |
|
Harlan and I talked about this offline. |
harlanhaskins
force-pushed
the
json-born
branch
2 times, most recently
from
7bdea02 to
a30ce39
Compare
|
@swift-ci please test |
|
Build failed |
This patch removes the hand-rolled libSyntax API and replaces it with an API that's entirely automatically generated. This means the API is guaranteed to be internally stylistically and functionally consistent.
|
@swift-ci please smoke test and merge |
|
@swift-ci please smoke test |
|
⛵ |
| @@ -0,0 +1,11 @@ | |||
| set(SWIFT_GYB_FLAGS | |||
| --line-directive "''") | |||
There was a problem hiding this comment.
I can't understand why you'd disable line directives like this; the result would be that any compilation errors point into the generated file instead of the original one, with the typical result that maintainers edit the wrong file.
There was a problem hiding this comment.
Ahhh yes sorry about that. I turned line directives off while initially writing the gyb templates because it made it harder to see what the template instantiation was doing. That said, they should have been re-enabled before merging. I’ll re-enable them in a patch.
There was a problem hiding this comment.
Now that I'm looking, these are for the C++ bindings. gyb's line directive code emits Swift-style line directives -- clang will just ignore them. The patch for this would need to teach gyb how and when to emit C-style line directives, which wouldn't be too difficult.
There was a problem hiding this comment.
Actually, those aren't swift-style line directives, which are broken for this purpose because they are only valid in certain syntactic positions. These are just comments that get post-processed by the line-directive tool. For error messages, it doesn't matter that clang would ignore them because the output of clang would get passed through the line-directive tool just like the output of Swift does. However, generating real #line directives should also allow you to debug in the .gyb source rather than in the generated .cpp
This patch replaces the hand-rolled implementation of libSyntax’s APIs with a set of Python definitions that drive a set of gyb templates.
The Node definitions are incomplete, and they will be filled out incrementally.