- when compiling embedded cross compile target standard libraries, include AVR
- add 16-bit pointer as a conditional compilation condition and get the void pointer size right for gyb sources
- attempt to fix clang importer not importing __swift_intptr_t correctly on 16 bit platforms
- changed the unit test target to avr-none-none-elf to match the cmake build
[AVR] got the standard library compiling in a somewhat restricted form:
General
- updated the Embedded Runtime
- tweaked CTypes.swift to fix clang import on 16 bit platforms
Strings
- as discussed in https://forums.swift.org/t/stringguts-stringobject-internals-how-to-layout-on-16-bit-platforms/73130, I went for just using the same basic layout in 16 bit as 32 bit but with 16 bit pointers/ints... the conversation is ongoing, I think something more efficient is possible but at least this compiles and will probably work (inefficiently)
Unicode
- the huge arrays of unicode stuff in UnicodeStubs would not compile, so I skipped it for AVR for now.
Synchronization
- disabled building the Synchronization library on AVR for now. It's arguable if it adds value on this platform anyway.
This allows us to evolve e.g. token kinds and how attributes are modelled independently between SwiftSyntax and the compiler. It also makes it easier to e.g. add an attribute because you don’t need to create PRs for two repositories.
Make libSyntax depend on swift-syntax: the new home for all
of this infrastructure. This greatly simplifies the addition and
amending of syntax nodes as only the swift-syntax paired with a
swift checkout will need to be changed. This is in contrast to
the existing build flow where a paired PR to both repos must be
made to change anything here.
Note that a paired PR may still be required if the legacy parser
needs to be adjusted in response to syntax nodes changing, but I
anticipate this to be a much more infrequent event now that
the C++ end of libSyntax is deprecated.
LLDB requires python3, however, gyb is a python2 tool. Use the fact
that we have a newer CMake at our disposal and use the `Python2` package
in CMake to locate a viable python interpreter. This allows us to have
references to both versions of python simultaneously.
To represent a type with code completion.
type? '.'? <code-completion-token>
This is "parser only" node which is not exposed to SwiftSyntax.
Using this, defer to set the parsed type to code-completion callbacks.
This avoids us having to pattern match every source file which should
help speed up the CMake generation. A secondary optimization is
possible with CMake 3.14 which has the ability to remove the last
extension component without having to resort to regular expressions. It
also helps easily identify the GYB'ed sources.
This also fixes several issues where attribute arguments could not be
parsed as a TokenList since some of its arguments already had structure
and were not tokens
StdlibUnittest uses gyb to avoid duplicating many source-context
arguments. However, this means that any test that wishes to add new
expect helpers has to also be gybbed. Given that this structure hasn't
changed in years, and we should have a real language support
eventually, de-gyb it.
The existing libSyntax infrastructure uses external python
dictionaries to share logic between C++ and Swift implementations.
This patch teaches trivia kinds to adapt to this infrastructure
as well.
Make the quoted parameters more portable. This is needed in order to
support building swift on Windows. Simplify the declaration of the
flags and do a small formatting clean up. This ensures that the ninja
generation gets the command line invocation correct.
* Generate libSyntax API
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.
attribute or appear in a whitelist.
The initial whitelist is based on an audit I performed of our current
public SDKs. If there are CF types which appear only in our internal
SDKs, and somebody urgently needs to use them from Swift, they can
adopt the bridging attributes. The goal is to eventually eliminate
the whitelist and rely solely on bridging attributes anyway.
Sadly, CoreCooling was not included in my SDK audit and must be
explicitly annotated. :(
I've left the main database organized by framework, but I wanted
a quasi-lexicographically sorted version to permit efficient lookup.
We generate that copy automatically with gyb. I ended up having
to tweak handle_gyb_sources to allow it to drop the result in
CMAKE_CURRENT_BINARY_DIR instead of CMAKE_CURRENT_BINARY_DIR/{4,8}
if an architecture is not provided. I think this is abstractly
reasonable for generated includes, which have independent ability
to detect the target word size. But just between you and me,
I did it because I couldn't figure out how to add
"-I${CMAKE_CURRENT_BINARY_DIR/{4,8}" as a compile flag;
the obvious thing didn't work. Anyway, I'd appreciate it if
someone double-checked my cmake hackery here.
Swift SVN r24850
