Adjust the remaining instance of the `ExecuteNoWait` to use the
llvm::ArrayRef<StringRef> without an implicit conversion. This allows swiftc to
build on Windows once again.
LLVM r340675 added a new HermitCore OS type to triples, which broke the
Swift build because it is using -Werror,-Wswitch and the new value was not
handled in swift::getPlatformNameForTriple
It is more efficient than llvm::AppendingBinaryByteStream if a lot of
small data gets appended to it because it doesn't need to resize its
buffer on each write.
This now takes `ArrayRef<StringRef>` and `Optional<ArrayRef<StringRef>>`
parameters. Explicitly update the interfaces to match. This is particularly
important to repair the Windows build.
unistd.h is a Unix specific header. Ensure that we do not try to include it on
non-unix environments (i.e. Windows). This attempts to restore the Windows
build once again.
Until now, only ">=" was supported in #if swift() expressions, for example:
```#if swift(>=2.1)
```#endif
This means that if we want to evaluate code only when the language version is
less than a particular version we need to do the following:
```#if !swift(>=2.1)
```#endif
An alernative to make this more readable (the "!" can be easily missed in a code
review) is to introduce another supported unary operator, "<". The previous
example could be rewritten like this:
```#if swift(<2.1)
```#endif
This commit adds support for that unary operator, along with some tests.
This was removed upstream in https://reviews.llvm.org/D47789 since the only
place this flag was used was in the windows implementation where the behavior
triggered by this could be hidden in the implementation instead of being an
argument. As such, this code doesn't compile on master-next.
Since this has an acceptable default argument given the current stable, we can
just fix this on master and everything will work.
rdar://42862352
This replaces the use of a Clang utility function that was
inexplicably a non-static member function of CompilerInstance. It
would be nice to sink this all the way to LLVM and share the
implementation across both projects, but the Clang implementation does
a handful of things we don't need, and it's hard to justify including
them in an LLVM-level interface. (I stared at
llvm/Support/FileSystem.h for a long time before giving up.)
Anyway, Serialization and FrontendTool both get their atomic writes
now without depending on Clang, and without duplicating the
scaffolding around the Clang API. We should probably adopt this for
all our output files.
No functionality change.
Add an abstraction to retrieve a name suitable for display for a given
source location for use with diagnostics, debug locations, and magic
file literals.
Adds the -vfsoverlay frontend option that enables the user to pass
VFS overlay YAML files to Swift. These files define a (potentially
many-layered) virtual mapping on which we predicate a VFS.
Switch all input-based memory buffer reads in the Frontend to the new
FileSystem-based approach.
Most keys are string literals and if they are converted directly to
StringRef, the string length can be computed at compile time, increasing
performance.
For ScalarTraits, a buffer was always created on the heap to which the
scalar string value was written just to be copied to the output buffer
again. In case the value already exists in a memory buffer it is way
cheaper to avoid the heap allocation and copy it straight to the output
buffer.
LLVM r334399 (and related Clang changes) moved clang::VersionTuple to
llvm::VersionTuple. Update Swift to match.
Patch by Jason Molenda.
rdar://problem/41025046
Introduce another form of debugging dump for the evaluator, rendering the
complete dependency graph using GraphViz, including all dependencies and
values cached within the evaluator.
Meant as a replacement for the barely-started iterative type checker,
introduce a simpler "evaluator" that can evaluate individual requests
(essentially, function objects with some additional API), caching
results as appropriate and detecting cycles.
The implementation is small and would need to be replicated into the
default implementation. Move the definition into the common TaskQueue
implementation. This repairs the Windows build of the compiler.
When providing the -parseable-output flag to the swift compiler, it will provide json formatted messages about tasks that run.
I added some optional usage information in form of user time, system time and maxrss to the output. This can be used by other tools using the compiler to get some insights about time and memory usage.
Since the output does not longer match processes run (in batch mode), I also added a real_pid field so the client could reason about jobs that belong together if needed.
rdar://39798231
