Skip to content

[Sema] Implement type erasure for dynamic replacement. #30101

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 5 commits into from
Feb 28, 2020

Conversation

hborla
Copy link
Member

@hborla hborla commented Feb 27, 2020

Before generating constraints for an expression that could potentially be a return value, perform type erasure on this expression if needed. An expression needs type erasure if:

  1. The expression is a return value.
  2. The enclosing function is dynamic or a dynamic replacement.
  3. The enclosing function returns an opaque type.
  4. The opaque type conforms to (exactly) one protocol, and the protocol has a declared type eraser.

Resolves: rdar://problem/58763698

@hborla hborla requested review from xedin and DougGregor February 27, 2020 19:51
@hborla
Copy link
Member Author

hborla commented Feb 27, 2020

@swift-ci please smoke test

@hborla hborla merged commit 87bb775 into swiftlang:master Feb 28, 2020
@hborla hborla deleted the dynamic-replacement-type-erasure branch February 28, 2020 17:45
Printer << "(";
Printer.callPrintNamePre(PrintNameContext::Attribute);
auto typeLoc = cast<TypeEraserAttr>(this)->getTypeEraserLoc();
if (auto type = typeLoc.getType())
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There's an option to prefer the TypeRepr when printing. Can you check willUseTypeReprPrinting in this conditional?

@@ -520,7 +520,7 @@ SIMPLE_DECL_ATTR(_inheritsConvenienceInitializers,
93)

DECL_ATTR(_typeEraser, TypeEraser,
OnProtocol | UserInaccessible | NotSerialized |
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm. Please bump the version number in ModuleFormat.h to account for this.

@@ -7417,6 +7417,7 @@ ExprWalker::rewriteTarget(SolutionApplicationTarget target) {
return None;

result.setFunctionBody(newBody);
fn.getAbstractFunctionDecl()->setHasSingleExpressionBody(false);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why do we need this?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Anything that calls hasSingleExperssionBody and subsequently calls getSingleExpressionBody after the function builder transformation is applied will crash. In my case it was -dump-ast

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.

3 participants