* [Diagnostics] Improve {{none}} fix-it verifier
* split two conditions
* define "none" constant
* support plural
* use Twine and add comment for replacement range
* check if {{none}} is at the end
* use noneMarkerStartLoc
* update second {{none}} error message
Co-Authored-By: Owen Voorhees <owenvoorhees@gmail.com>
* update test case for second {{none}}
* fix test case for new {{none}} check
* Use named struct
* set const
Co-authored-by: Owen Voorhees <owenvoorhees@gmail.com>
A header shouldn't contain a function body unless the function is
inline. Following gribozavr's suggestion, I'm using the easier solution
of omitting the semicolon from the function prototype.
(In response to review comments.)
In Windows stdout and stderr are not line buffered, so the output of
stderr can be intermixed with the stdout, which will break the test when
checking with CHECK-NEXT and similar. Additionally it seems that stderr
always contains at least one new line.
Redirecting stderr to a file removes the problems with the mixing, and
since the stderr is not checked for this test, should not change
anything.
In some cases (Android ARMv7) the SIL output wasn't following the output
of the source code, and the test failed. Use -emit-sorted-sil to use a
stable sorting for the SIL, and reorder the source to match the SIL
output.
The output is now the same order not depending on the value of
StripOwnershipAfterSerialization.
Clang 8 or 9 seems to have changed from EXE to exe. Allow both
capitalizations (which is not important in Windows) as a workaround.
Maybe in the future we can remove the uppercase option.
This flag, currently staged in as `-experimental-skip-non-inlinable-function-bodies`, will cause the typechecker to skip typechecking bodies of functions that will not be serialized in the resulting `.swiftmodule`. This patch also includes a SIL verifier that ensures that we don’t accidentally include a body that we should have skipped.
There is still some work left to make sure the emitted .swiftmodule is exactly the same as what’s emitted without the flag, which is what’s causing the benchmark noise above. I’ll be committing follow-up patches to address those, but for now I’m going to land the implementation behind a flag.
...fulfilling the promised audit from 0747d9a339. No intended
functionality change /other/ than the order of already-unsorted lists.
This affected a number of SIL tests that relied on deserialization
order matching the original source order; I have no idea why the old
hash logic would make that the case. If we think that's a valuable
property, we should serialize a list of functions in addition to the
iterable table. (Maybe just in SIB mode?)
The RUN line was redirecting stderr to stdout, but nothing in the test
was checking for the stderr output.
However, the last line of stderr was an empty newline, which was printed
(in my machine) in the middle of the dump from the AST, breaking the
test.
If we ever need to check the stderr, it should be redirected to a file,
and the file should be passed to FileCheck independently, to avoid
concurrent uses of the output buffer.
The clang importer has to deal with two virtual file systems, one coming
from clang, and one coming from swift. Currently, if both are set, we
emit a diagnostic that we'll pick the swift one.
This commit changes that, by merging the two virtual file systems. The
motivation for this change is the reproducer infrastructure in LLDB,
which adds a third virtual file system to the mix.
(cherry picked from commit 94ef5431ff)
This means that we no longer have the invariant that the extendedType always
contains the generic parameters. So we need to fix the assertions/test cases
for it.
This flag adds diagnostic names to the end of their messages, e.g. 'error: cannot convert value of type '[Any]' to specified type '[Int]' [cannot_convert_initializer_value]'. It's intended to be used for debugging purposes when working on the compiler.
The clang importer has to deal with two virtual file systems, one coming
from clang, and one coming from swift. Currently, if both are set, we
emit a diagnostic that we'll pick the swift one.
This commit changes that, by merging the two virtual file systems into a
single overlay file system, and using that. To make this possible, we
always initialize the file manager with an overlay file system. In the
clang importer, we then create a new overlay file system, starting with
the one coming from clang, and adding overlays from swift on top.
The motivation for this change is the reproducer infrastructure in LLDB,
which adds a third virtual file system to the mix.
As pointed out on a recent JIRA, crash traces don't mention what
version of Swift you were running. Usually that can be gleaned from
the path, but not always.
Windows absolute paths contain [A-Z]:. Filter out the explicit ' : '
separator that we were trying to check for to allow the test to pass on
Windows as well.
To display stack traces from child processes, the driver combines stdout
and stderror together on Unix. This makes the Basic implementation also
do that.
If the LLVM/clang is built with release mode and PACKAGE_VENDOR set, it
will not print the same string but rather the version number. Permit
either string.
This changes the Swift resource directory from looking like
lib/
swift/
macosx/
libswiftCore.dylib
libswiftDarwin.dylib
x86_64/
Swift.swiftmodule
Swift.swiftdoc
Darwin.swiftmodule
Darwin.swiftdoc
to
lib/
swift/
macosx/
libswiftCore.dylib
libswiftDarwin.dylib
Swift.swiftmodule/
x86_64.swiftmodule
x86_64.swiftdoc
Darwin.swiftmodule/
x86_64.swiftmodule
x86_64.swiftdoc
matching the layout we use for multi-architecture swiftmodules
everywhere else (particularly frameworks).
There's no change in this commit to how Linux swiftmodules are
packaged. There's been past interest in going the /opposite/ direction
for Linux, since there's not standard support for fat
(multi-architecture) .so libraries. Moving the .so search path /down/
to an architecture-specific directory on Linux would allow the same
resource directory to be used for both host-compiling and
cross-compiling.
rdar://problem/43545560
For context, String, Nil, and Bool already behave this way.
Note: Before it used to construct (call, ... (integer_literal)), and the
call would be made explicit / implicit based on if you did eg: Int(3) or
just 3. This however did not translate to the new world so this PR adds
a IsExplicitConversion bit to NumberLiteralExpr. Some side results of
all this are that some warnings changed a little and some instructions are
emitted in a different order.
