[Serialization] Fix deserializing opaque types for computed properties and subscripts

A client shouldn't know about the underlying type of an opaque type
unless it can see the body of the naming decl. Attempting to read it can
lead to accessing a hidden dependency and a compiler crash.

This was protected by a check specific to function decls but var decls
and subscripts were not handled. To support them we have to move this
logic to the writer side where we have access to the full
AbstractStorageDecl and write in the swifmodule whether the underlying
type should be visible outside of the module.

rdar://117607906
This commit is contained in:
Alexis Laferrière
2023-10-30 14:44:20 -07:00
parent d976ea676c
commit f2d1627656
7 changed files with 237 additions and 8 deletions

View File

@@ -3324,6 +3324,9 @@ public:
};
}
/// Should the underlying type be visible to clients outside of the module?
bool exportUnderlyingType() const;
/// The substitutions that map the generic parameters of the opaque type to
/// the unique underlying types, when that information is known.
llvm::Optional<SubstitutionMap> getUniqueUnderlyingTypeSubstitutions() const {