-
Notifications
You must be signed in to change notification settings - Fork 10.5k
[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
Conversation
No functionality change (based on where it was used)
No intended functionality change.
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
@swift-ci Please test |
There was a problem hiding this 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)); |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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>()) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Has this become impossible?
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
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.