This was causing local refactorings (which are line+column-based) to fail due to
the provided location being considered invalid, even though the available
refactorings request (which uses offset directly) reported them as available.
This silences the instances of the warning from Visual Studio about not all
codepaths returning a value. This makes the output more readable and less
likely to lose useful warnings. NFC.
`env` is a default'ed parameter. In some cases it may be passed a `nullptr`,
which is not a valid parameter to `llvm::toStringRefArray`. Guard against this
case. This allows the swift compiler to work again on Windows!
* [InterfaceGen] Remove #ifs from default args
This patch removes all #if configs form the bodies of default arguments,
which can contain multiline closures, while preserving the bodies of the
clauses that are active.
This code is generalized and should "just work" for inlinable function
bodies, which will come in a later patch.
* Address review comments
* Fix and test CharSourceRange.overlaps
* Fix CharSourceRange::print to respect half-open ranges
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.
