Commit Graph

9 Commits

Author SHA1 Message Date
Meghana Gupta
e8abd59da5 Update tests 2024-11-18 18:09:19 -08:00
Daniel Rodríguez Troitiño
ba68faaed5 [test] Mark tests that use experimental/upcoming features as such
Find all the usages of `--enable-experimental-feature` or
`--enable-upcoming-feature` in the tests and replace some of the
`REQUIRES: asserts` to use `REQUIRES: swift-feature-Foo` instead, which
should correctly apply to depending on the asserts/noasserts mode of the
toolchain for each feature.

Remove some comments that talked about enabling asserts since they don't
apply anymore (but I might had miss some).

All this was done with an automated script, so some formatting weirdness
might happen, but I hope I fixed most of those.

There might be some tests that were `REQUIRES: asserts` that might run
in `noasserts` toolchains now. This will normally be because their
feature went from experimental to upcoming/base and the tests were not
updated.
2024-11-02 11:46:46 -07:00
Kavon Farvardin
545844ce8f ASTPrinter: fix nested signatures with inverses
A generic signature's `getInnermostGenericParams` will find the generic
parameters in the innermost scope. That's not quite right for printing
inverses, since we don't want to print an inverse for `T` when emitting
the generic signature of `f` below:

```swift
    struct S<T: ~Copyable, E> {
        func f() where E == Never {}
    }
```

Since `f` has its own generic signature, but doesn't define any generic
parameters, it shouldn't have an inverse emitted. The solution here is
to filter inverses by depth of the generic parameter.

We also want to print _all_ of the inverses in other situations, rather
than just the innermost ones. This aids in debugging and other
tools like the API digester.

resolves rdar://130179698
2024-06-25 12:06:23 -07:00
Kavon Farvardin
ec4a125f3e NCGenerics: ext's might not infer invertible req's
If the extension adds conformance to an invertible protocol, it's
confusing for people to also infer conditional requirements on the
generic parameters for those invertible protocols. This came up in the
review of SE-427.
2024-06-12 14:44:22 -07:00
Kavon Farvardin
0420310623 NCGenerics: it's no longer "experimental"
resolves rdar://127701059
2024-05-08 10:49:12 -07:00
Andrew Trick
9bd9218761 Fix mangling tests after fixing AbstractionPattern::isNonCopyable. 2024-04-07 22:58:28 -07:00
Doug Gregor
757ebe2979 Future-proof the mangling of invertible protocols
Invertible protocols are currently always mangled with `Ri`, followed by
a single letter for each invertible protocol (e.g., `c` and `e` for
`Copyable` and `Escapable`, respectively), followed by the generic
parameter index. However, this requires that we extend the mangling
for any future invertible protocols, which mean they won't be
backward compatible.

Replace this mangling with one that mangles the bit # for the
invertible protocol, e.g., `Ri_` (followed by the generic parameter
index) is bit 0, which is `Copyable`. `Ri0_` (then generic parameter
index) is bit 1, which is `Escapable`. This allows us to round-trip
through mangled names for any invertible protocol, without any
knowledge of what the invertible protocol is, providing forward
compatibility. The same forward compatibility is present in all
metadata and the runtime, allowing us to add more invertible
protocols in the future without updating any of them, and also
allowing backward compatibility.

Only the demangling to human-readable strings maps the bit numbers
back to their names, and there's a fallback printing with just the bit
number when appropriate.

Also generalize the mangling a bit to allow for mangling of invertible
requirements on associated types, e.g., `S.Sequence: ~Copyable`. This
is currently unsupported by the compiler or runtime, but that may
change, and it was easy enough to finish off the mangling work for it.
2024-03-28 21:26:13 -07:00
Slava Pestov
dcea491dbe Sema: Remove inference of conditional Copyable conformance from generic parameters 2024-03-06 22:47:54 -05:00
Kavon Farvardin
215bd3cab4 Mangling: handle inverse requirements 2024-03-05 14:19:00 -08:00