Commit Graph

12 Commits

Author SHA1 Message Date
Anthony Latsis
17fc00f8a7 [test] IRGen: Adjust FileCheck patterns for new nuw attribute in upstream LLVM
This attribute was introduced in
7eca38ce76d5d1915f4ab7e665964062c0b37697 (llvm-project).

Match it using a wildcard regex, since it is not relevant to these
tests.

This is intended to reduce future conflicts with rebranch.
2025-05-04 03:28:56 +01:00
Doug Gregor
f269cb5fbe Disable mangling of inverses for generalized existential shape symbols 2024-03-06 13:41:49 -08:00
Kavon Farvardin
2a1cf37458 XFAIL tests now failing under noncopyable_generics
After implementing mangling for inverses, issues have been revealed.
2024-03-05 14:19:00 -08:00
Dario Rexin
90c11024a4 Update more IRGen tests for opaque pointers 2023-06-23 06:57:37 -07:00
Arnold Schwaighofer
c1a93e0bde Move tests over to use the %use_no_opaque_pointers option 2023-06-14 10:49:48 -07:00
John McCall
175f74d38f Implement symbolic demangling for extended existential metadata
Fixes rdar://96268090.
2022-07-01 11:21:53 -04:00
Robert Widmann
dde0d8f609 Generalize the Mangling of Constrained Existential Types
Upgrade the old mangling from a list of argument types to a
list of requiremnets. For now, only same-type requirements
may actually be mangled since those are all that are available
to the surface language.

Reconstruction of existential types now consists of demangling (a list of)
base protocol(s), decoding the constraints, and converting the same-type
constraints back into a list of arguments.

rdar://96088707
2022-06-30 15:32:37 -07:00
Robert Widmann
663722d892 Parameterized Existential Types Are Enabled By Default
See https://forums.swift.org/t/accepted-se-0353-constrained-existential-types/57560
2022-05-25 09:50:36 -07:00
John McCall
bd77714537 Unique extended existential shapes using the generalized AST type.
I wrote out this whole analysis of why different existential types
might have the same logical content, and then I turned around and
immediately uniqued existential shapes purely by logical content
rather than the (generalized) formal type.  Oh well.  At least it's
not too late to make ABI changes like this.

We now store a reference to a mangling of the generalized formal
type directly in the shape.  This type alone is sufficient to unique
the shape:

- By the nature of the generalization algorithm, every type parameter
  in the generalization signature should be mentioned in the
  generalized formal type in a deterministic order.

- By the nature of the generalization algorithm, every other
  requirement in the generalization signature should be implied
  by the positions in which generalization type parameters appear
  (e.g. because the formal type is C<T> & P, where C constrains
  its type parameter for well-formedness).

- The requirement signature and type expression are extracted from
  the existential type.

As a result, we no longer rely on computing a unique hash at
compile time.

Storing this separately from the requirement signature potentially
allows runtimes with general shape support to work with future
extensions to existential types even if they cannot demangle the
generalized formal type.

Storing the generalized formal type also allows us to easily and
reliably extract the formal type of the existential.  Otherwise,
it's quite a heroic endeavor to match requirements back up with
primary associated types.  Doing so would also only allows us to
extract *some* matching formal type, not necessarily the *right*
formal type.  So there's some good synergy here.
2022-04-21 23:47:01 -04:00
John McCall
7ba8b474be Fix test for pointer authentication.
Fixes rdar://91669918
2022-04-13 02:06:00 -04:00
Erik Eckstein
a8c9182763 tests: disable IRGen/existential_shape_metadata.swift
to unblock CI
2022-04-13 07:31:40 +02:00
John McCall
6385934d7e Metadata emission for extended existential type shapes 2022-04-12 14:52:47 -04:00