The object returned by a failing command invocation is a bytes object,
which cannot be concatenated with a string directly. Decode it and split
it to make the missing symbol list clearer.
This change forces you to write ``@reparented` relationships
on an extension of a protocol, rather than on the protocol
itself.
The ProtocolConformance needs to be associated with some
GenericContext and IRGen expects it to be an ExtensionDecl.
That environment defines under what conditions the conformance
exists. We also need to define witnesses for the new parent's
requirements in an extension anyway, so it's a natural fit.
The previous workaround for this was kind of awful, as it'd
require searching all the protocol's extensions and "guess"
which extension they want to represent the conformance. While
we could try to synthesize an extension, there's two
challenges there:
1. Due to SuppressedAssociatedTypes, it's not so simple to
synthesize an unconstrained ExtensionDecl.
2. We currently rely on same-type requirements to pin the
associated types to particular witnesses of those requirements
in the extension. So it's not purely unconstrained! For example,
```
extension Seq: @reparented BorrowSeq where Iter == MyIter {}
```
The constraints that are disallowed (but not yet diagnosed)
are conditional conformance requirements, as the default
conformance for a reparenting cannot depend on those.
Thus, it's better that programmers to specify the extension.
This mode was effectively removed from `rth`
in ba04d49 because it was unused. I do need this
to exclude the before_after scenario, which is
linking a newer app with an older library.
This solves deprecation warnings in build-script:
```
DeprecationWarning: 'pipes' is deprecated and slated for removal in Python 3.13
```
This change assumes that the minimum version
of Python3 is 3.3, which has `shlex.quote`.
Since our build bots currently use 3.6 as their
Python version, we can't yet use `shlex.join`
to further simplify some of the code using
quote.
The `__future__` we relied on is now, where the 3 specific things are
all included [since Python 3.0](https://docs.python.org/3/library/__future__.html):
* absolute_import
* print_function
* unicode_literals
* division
These import statements are no-ops and are no longer necessary.
Here we fix a few portability issues affecting running the validation tests on OpenBSD. The remaining failures will be dealt with separately.
1. In the `rth` tool, ensure `-z origin` is specified to the linker when
using `$ORIGIN`, as required on this platform.
2. Explicitly set the rpath in the `dsohandle-multi-module` execution
test, since the test uses built dynamic libraries during the test.
3. Erase the environment variable instead of using `env -u`, the latter
of which is not portable.
The tests need to change the working directory when executing on Windows
as RPATH is not supported on the platform. The current working
directory gets precedence over `PATH` for library lookup. This allows
the last of the Evolution tests pass on Windows.
Windows does not support the concept of RPATH. As a result, we must
change the working directory for the test. This extends the support
for the tests to work with PE/COFF on Windows. Use the newly minted
`self.triple` property to drive the host detection. This means that
the test coverage on Windows is able to test most of the resilience
functionality.
The resilience test helper builds up invocations of the tooling. In
order to do this, we need to know what host we are building for. Plumb
the value for `-triple` from the test harness into the utility. This
will be used subsequently to enable additional testing for Windows.
This adds a new mode where we always build the app with the new library,
and run it with the old and new library. This is used to test backward
deployment of code that uses weak-linked symbols.
To ensure that we properly crash if we reference an undefined symbol that
is not weak linked, also pass a linker flag to bind symbols eagerly.
A resilient change should not *remove* previously-public symbols.
Note that currently, the test_superclass_properties test does not
meet this critierion, because we always emit keypath property
descriptors, even when the property is an override. Fixing this
is a larger change that I'll address in a follow-on PR, so for now
I'm just going to disable the symbol check for this one test only.
Part of <rdar://problem/40432647>.
At least test_rth.swift is checking the name of the executable
during the test, so renaming every executable to __executable in
Android will never work.
Also, during the rth tool execution, all the results from before
and after are pushed for every test. Since Android copies the
passed files without relative paths, the library files will
overwrite each other, making the test fail.
Depends on #19949 (more or less)
Most of this is just "remember to specify the inputs and outputs on
the command line, so remote-run can see them". A bit is "prefix
environment variables with '%env-'". And the last few are "yeah,
this was never going to work in a remote environment".
In the few cases where I couldn't think of anything reasonable, I just
marked the test as "UNSUPPORTED: remote_run", a new "feature".
* E101: indentation contains mixed spaces and tabs
* E111: indentation is not a multiple of four
* E128: continuation line under-indented for visual indent
* E302: expected 2 blank lines, found 1
* W191: indentation contains tabs
Before this commit:
```
$ flake8
./utils/rth:34:17: E127 continuation line over-indented for visual indent
./utils/rth:67:27: E127 continuation line over-indented for visual indent
$
```
After this commit:
```
$ flake8
$
```
Kavon Farvardin
Evan Wilde
Daniel Duan
3405691582
Saleem Abdulrasool
Karoy Lorentey
Slava Pestov
Daniel Rodríguez Troitiño
Jordan Rose
Arnold Schwaighofer
Hugh Bellamy
practicalswift
Brian Gesiak
Luke Larson