Skip to content

[Serialization] Remove several unnecessary bits of helper logic #26735

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 4 commits into from
Aug 20, 2019

Conversation

jrose-apple
Copy link
Contributor

Several commits that simplify Serialization in mostly trivial ways, mainly by removing Serialization's ad-hoc copy of an existing helper function. No intended functionality change.

No functionality change (based on where it was used)
We used to track final-ness separately from FinalAttr, but
serialization didn't know how to handle that, so we synthesized a fake
FinalAttr. However, final-ness (finality, I guess) is always kept in
sync with FinalAttr now, so this check is no longer necessary.

No functionality change.
- Use Optional::getValueOr instead of a handrolled version.
- Use swift::reversed for reverse iteration instead of reversing a
  buffer mutably.
- Use StringRef::withNullAsEmpty instead of checking both kinds of
  empty string
@jrose-apple
Copy link
Contributor Author

@swift-ci Please test

Copy link
Contributor

@beccadax beccadax 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 questions, but I assume you have answers.

SmallVectorImpl<char> &out) {
llvm::raw_svector_ostream outStream(out);
import.second->getReverseFullModuleName().printForward(outStream,
StringRef("\0", 1));
Copy link
Contributor

Choose a reason for hiding this comment

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

I'm surprised you can't just say "\0" here. Would it try to use strlen() if you did?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yeah, that's the default behavior for StringRef. The subclass StringLiteral knows how to handle embedded NULs but that's more verbose than just doing this.

@@ -2848,13 +2808,6 @@ class Serializer::DeclSerializer : public DeclVisitor<DeclSerializer> {
for (auto Attr : D->getAttrs())
writeDeclAttribute(Attr);

if (auto VD = dyn_cast<ValueDecl>(D)) {
// Hack: synthesize a 'final' attribute if finality was inferred.
if (VD->isFinal() && !D->getAttrs().hasAttribute<FinalAttr>())
Copy link
Contributor

Choose a reason for hiding this comment

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

Has this become impossible?

Copy link
Contributor

Choose a reason for hiding this comment

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

Would it be worthwhile to have an assertion here to double-check that FinalAttr is in sync or is that not useful because correctness is guaranteed by construction?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Good point. I'll add it to the AST verifier; that's where such correct-by-construction assertions belong.

@jrose-apple jrose-apple merged commit c4ee7ec into swiftlang:master Aug 20, 2019
@jrose-apple jrose-apple deleted the heart-healthy branch August 20, 2019 23:20
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