Skip to content

Remove all Uses of TimeValue #12

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 1 commit into from
Mar 29, 2019

Conversation

gmittert
Copy link
Contributor

The latest version of llvm no longer has TimeValue.h, so this replaces uses
with TimePoint and std::chrono.

I'd like to start porting this to Windows and as part of that, I need to pull in the Windows headers which means updating the llvm support libraries that are part of indexstore-db.

TimestampedFileForProviderData entry{file, unit, module, modTime.seconds(), modTime.nanoseconds(), isSystem};
auto nanos = std::chrono::duration_cast<std::chrono::nanoseconds>(modTime.time_since_epoch()).count();
auto secComponent = nanos / 1000000000;
int32_t nanoComponent = nanos % 1000000000;
Copy link
Contributor

Choose a reason for hiding this comment

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

This changes the interpretation of any existing index data. TimeValue's internal epoch was/is 00:00:00 Jan 1, 2000 UTC, but this changes it to store the time using system_clock's epoch, which is probably the posix epoch in 1970.

I think we need to bump DATABASE_FORMAT_VERSION CC @akyrtzi to verify this.

@akyrtzi since we need to bump the format anyway, is there a reason we need to split up the time into components like this? Could we store a std::chrono::time_point<std::chrono::system_clock, nanoseconds> directly instead (we'd want to use that instead of TimePoint<> to guard against changes in llvm)?

Copy link
Contributor

Choose a reason for hiding this comment

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

@akyrtzi since we need to bump the format anyway, is there a reason we need to split up the time into components like this? Could we store a std::chrono::time_point<std::chrono::system_clock, nanoseconds> directly instead

I agree, we should store this as a single uint64 and bump the database format.

@@ -174,7 +177,8 @@ void ImportTransaction::Implementation::addFileAssociationForProvider(IDCode pro
lmdb::val existingValue;
cursor.get(existingKey, existingValue, MDB_GET_CURRENT);
const auto &existingData = *(TimestampedFileForProviderData*)existingValue.data();
llvm::sys::TimeValue existingModTime(existingData.Seconds, existingData.Nanoseconds);
llvm::sys::TimePoint<> existingModTime = std::chrono::time_point_cast<std::chrono::nanoseconds>(llvm::sys::toTimePoint(existingData.Seconds));
Copy link
Contributor

Choose a reason for hiding this comment

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

toTimePoint assumes you're converting from a time_t. We should only do that if we're using toTimeT on the other side.

The lastest version of llvm no longer has TimeValue.h, so this replaces uses
with TimePoint and std::chrono.
@gmittert
Copy link
Contributor Author

Updated the database version and now use uint64_t NanoTime instead of Seconds and Nanoseconds. Assuming I did the math right, nanoseconds since the epoch fits in a uint64_t for the next few hundred years.

@benlangmuir
Copy link
Contributor

@swift-ci please test

@benlangmuir benlangmuir merged commit 6d2b38c into swiftlang:master Mar 29, 2019
@gmittert gmittert deleted the NoTimeComeQuick branch April 1, 2019 19:18
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