It was originally designed for faster trasmission of syntax trees from
C++ to SwiftSyntax, but superceded by the CLibParseActions. There's no
deserializer for it anymore, so let's just remove it.
Tying InputFile to this option meant that every input that was not one of the explictly-blessed kinds was modeled as a Swift file.
With the new InputFile that infers file kinds, we no longer need CompilerInvocation::setInputKind
This allows the syntax parser library and SwiftSyntax to successfully
parse code using this experimental feature without requiring an API
to pass compiler flags into the parser.
Most clients were only using it to populate the
main module with files, which is now done by
`getMainModule`. Instead, they can now just rely
on parsing happening lazily.
Lift the `DisablePoundIfEvaluation` parsing option
into `LangOptions` to subsume the need for the
`EvaluateConditionals` parameter, and sink the
computation of `CanDelayBodies` down into
`createSourceFileForMainModule`.
Enhances `swift-syntax-test` to output the parser diagnostics so we can verify that
if the incremental parse resulted in parser diagnostics, those diagnostics were also emitted during the full parse.
Now that we've moved to C++14, we no longer need the llvm::make_unique
implementation from STLExtras.h. This patch is a mechanical replacement
of (hopefully) all the llvm::make_unique instances in the swift repo.
This change fixes the ExponentialGrowthAppendingBinaryByteStream
tests on big endian machines.
Force ExponentialGrowthAppendingBinaryByteStreams to use little-
endian byte order. We always used little-endian byte order anyway
and it seems very unlikely we'll need the flexibility to make the
stream big-endian in the future. The benefit of this is that we
can use portable APIs while still allowing the compiler to remove
conditional byte swaps.
Also replace writeRaw with writeInteger and make it explicitly
little-endian to make the API cleaner and more portable.
The only client of the 'toSourceRange' method immediately constructs a
CharSourceRange from it, and ByteBasedSourceRange's EndLoc isn't the start of
the last token in the range (as SourceRange expects).
If we know the size of a type at compile time (like we do for all the
integer types), it is cheaper to assign the data buffer directly instead
of using a memcpy.
My previous change for this issue (033b884de6) did not fix all the
affected code. This gets the rest of them. Thanks for Jason Molenda
for helping with this. rdar://problem/41025365
This greatly improves the ergonomics of writing tests and outweighs the
ability to test which whitespaces get parsed since their parsing
overhead should be minimal.
