Skip to content

Conversation

@slavapestov
Copy link
Contributor

An opaque archetype contains a substitution map. Previously, we required that all replacement types in this substitution map were canonical. This requires the ASTPrinter to re-sugaring generic parameter types in order to get something that round trips, and this re-sugaring was hacky and not fully correct.

Instead, let's just say that opaque archetypes can be non-canonical if their replacement types are non-canonical. Computing the canonical type of an opaque archetype then canonicalizes this substitution map.

This PR only changes opaque archetypes, but existential and pack element archetypes also store substitution maps, and they should receive the same treatment eventually too.

We cannot in general assume the substitution map's replacement types
are written in terms of the generic signautre of the owner declaration.

This was only necessary because this substitution map did not
preserve type sugar, but now that it does, we no longer need
this hack.
@slavapestov slavapestov force-pushed the non-canonical-archetypes branch from 95b582f to d7726dc Compare October 8, 2025 19:17
@slavapestov slavapestov marked this pull request as ready for review October 8, 2025 19:17
@slavapestov
Copy link
Contributor Author

@swift-ci Please smoke test

@slavapestov
Copy link
Contributor Author

@swift-ci Please test source compatibility

@slavapestov slavapestov enabled auto-merge October 9, 2025 01:44
@slavapestov slavapestov merged commit 47049ce into swiftlang:main Oct 9, 2025
5 checks passed
slavapestov added a commit to slavapestov/swift that referenced this pull request Nov 19, 2025
…utions

We need to serialize the underlying type substitution map for an
inlinable function. However, there is no reason to deserialize it
eagerly, since doing so can lead to cycles. It is better for
correctness and performance to only deserialize it when needed.

Technically this fixes a regression from swiftlang#84299, but the actual
problem was there all along, it was just exposed by my change
on a specific project.

Fixes rdar://163301203.
slavapestov added a commit to slavapestov/swift that referenced this pull request Nov 19, 2025
…utions

We need to serialize the underlying type substitution map for an
inlinable function. However, there is no reason to deserialize it
eagerly, since doing so can lead to cycles. It is better for
correctness and performance to only deserialize it when needed.

Technically this fixes a regression from swiftlang#84299, but the actual
problem was there all along, it was just exposed by my change
on a specific project.

Fixes rdar://163301203.
slavapestov added a commit to slavapestov/swift that referenced this pull request Nov 19, 2025
…utions

We need to serialize the underlying type substitution map for an
inlinable function. However, there is no reason to deserialize it
eagerly, since doing so can lead to cycles. It is better for
correctness and performance to only deserialize it when needed.

Technically this fixes a regression from swiftlang#84299, but the actual
problem was there all along, it was just exposed by my change
on a specific project.

Fixes rdar://163301203.
slavapestov added a commit to slavapestov/swift that referenced this pull request Nov 20, 2025
…utions

We need to serialize the underlying type substitution map for an
inlinable function. However, there is no reason to deserialize it
eagerly, since doing so can lead to cycles. It is better for
correctness and performance to only deserialize it when needed.

Technically this fixes a regression from swiftlang#84299, but the actual
problem was there all along, it was just exposed by my change
on a specific project.

Fixes rdar://163301203.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant