Skip to content

Ensure that SourceFiles always have a backing buffer in the SourceManager #76512

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
Sep 18, 2024

Conversation

DougGregor
Copy link
Member

@DougGregor DougGregor commented Sep 17, 2024

The "buffer ID" in a SourceFile, which is used to find the source file's contents in the SourceManager, has always been optional. However, the effectively every SourceFile actually does have a buffer ID, and the vast majority of accesses to this information dereference the optional without checking.

Update the handful of call sites that provided nullopt as the buffer ID to provide a proper buffer instead. These were mostly unit tests and testing programs, with a few places that passed a never-empty optional through to the SourceFile constructor. The code that created a source buffer to parse C swift_attr attributes also failed to pass that source buffer through.

Then, remove optionality from the representation and accessors. It is now the case that every SourceFile has a buffer ID, simplying a bunch of code.

…butes

When rendering a swift_attr attribute for parsing, we were creating both
the backing buffer and a source file, but not providing the buffer's ID
to the source file, so we couldn't find the source code again. Fix that.

While here, also register the source file with the module, so we can
find the source file again based on location.
…ager

The "buffer ID" in a SourceFile, which is used to find the source file's
contents in the SourceManager, has always been optional. However, the
effectively every SourceFile actually does have a buffer ID, and the
vast majority of accesses to this information dereference the optional
without checking.

Update the handful of call sites that provided `nullopt` as the buffer
ID to provide a proper buffer instead. These were mostly unit tests
and testing programs, with a few places that passed a never-empty
optional through to the SourceFile constructor.

Then, remove optionality from the representation and accessors. It is
now the case that every SourceFile has a buffer ID, simplying a bunch
of code.
@DougGregor
Copy link
Member Author

@swift-ci please smoke test

@DougGregor
Copy link
Member Author

@swift-ci please test source compatibility

ParsingOptions parsingOpts, bool isPrimary)
: FileUnit(FileUnitKind::Source, M), BufferID(bufferID ? *bufferID : -1),
: FileUnit(FileUnitKind::Source, M), BufferID(bufferID),
ParsingOpts(parsingOpts), IsPrimary(isPrimary), Kind(K) {
M.getASTContext().addDestructorCleanup(*this);
Copy link
Contributor

@CodaFi CodaFi Sep 17, 2024

Choose a reason for hiding this comment

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

Should this assert that the buffer ID isn't ~0 or is that now valid (if... very unlikely to be encountered in the wild)?

Copy link
Member Author

Choose a reason for hiding this comment

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

Good idea!

-1 was once used as a sentinel value for "no buffer"; make sure it
doesn't persist anywhere.
@DougGregor
Copy link
Member Author

swiftlang/llvm-project#9269

@swift-ci please test

@DougGregor
Copy link
Member Author

swiftlang/llvm-project#9269

@swift-ci please smoke test

@DougGregor
Copy link
Member Author

@swift-ci please smoke test

@DougGregor DougGregor merged commit da0c70f into swiftlang:main Sep 18, 2024
3 checks passed
@DougGregor DougGregor deleted the sourcefile-nonopt-buffer branch September 18, 2024 18:13
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