Skip to content

Conversation

@augusto2112
Copy link

No description provided.

@augusto2112
Copy link
Author

@swift-ci test

Choose a reason for hiding this comment

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

IIRC, I renamed this to target_holder because in the end we wanted to read the Target* from it. If that's true, maybe this should be a std::function<Target *()> target_provider?

Copy link
Author

Choose a reason for hiding this comment

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

I agree, that sounds better.

Choose a reason for hiding this comment

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

Edit: std::function<TargetWP()>

Copy link
Author

Choose a reason for hiding this comment

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

There's one situation where we need the ASTContext, so I think keeping it returning a SwiftASTContext is probably better.

  } Impl(swift_ast_context ? swift_ast_context->GetASTContext() : nullptr);

Choose a reason for hiding this comment

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

That's in GetClangTypeNode(CompilerType clang_type, swift::Demangle::Demangler &dem, SwiftASTContext *swift_ast_context) which doesn't call the argument target_holder. Maybe those two use-cases can be treated separately?

Choose a reason for hiding this comment

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

Uh.. it's unfortunate that we need this there unconditionally. I guess the next task will be to see if we can factor out AST->getSwiftName() to not need a full SwiftASTContext initialization.

Copy link
Author

Choose a reason for hiding this comment

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

I think it's better to keep it like this for now, as we're threading to both places from the same intermediary functions, and I think it'd be more confusing to treat them as separate (for now). If we factor out AST->getSwiftName() then we'll probably have to separate the cases.

Choose a reason for hiding this comment

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

Is either of GetSwiftASTContextLazy() or GetLazySwiftASTContext() a more descriptive name?

Choose a reason for hiding this comment

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

Yes, it looks like we really just want a TargetWP here.

Choose a reason for hiding this comment

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

If we do go with the "lazy" naming scheme, we could call swift_ast_context_provider lazy_swift_ast_context

Copy link

@adrian-prantl adrian-prantl left a comment

Choose a reason for hiding this comment

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

I have a few naming suggestions inside, but otherwise this looks good!

@augusto2112 augusto2112 force-pushed the get-swift-ast-context-provider branch from 18830ba to 8f891eb Compare December 14, 2021 17:52
@augusto2112
Copy link
Author

@swift-ci test

@augusto2112
Copy link
Author

@swift-ci test Linux

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.

2 participants