Skip to content
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

Starboardize base #2182

Conversation

andrewsavage1
Copy link
Contributor

b/298237511

b/298237511
@andrewsavage1
Copy link
Contributor Author

Note these changes are all already in feature/all-upstream-update, this is just a review for cleanliness. Nothing will be able to build yet as the update to //build is still in progress in #2100

Copy link
Member

@jellefoks jellefoks left a comment

Choose a reason for hiding this comment

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

This is great! Having this diff should allow for future followup refactors and hopefully some upstreaming to reduce the footprints of our changes here.

Comments are all small-ish things.

@@ -96,7 +97,7 @@ bool IsLargeMemoryDevice() {
}

bool SetAddressSpaceLimit() {
#if !defined(ARCH_CPU_64_BITS) || !BUILDFLAG(IS_POSIX)
#if !defined(ARCH_CPU_64_BITS) || !BUILDFLAG(IS_POSIX) || 1
Copy link
Member

Choose a reason for hiding this comment

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

|| defined(STARBOARD)

@@ -124,7 +125,7 @@ bool SetAddressSpaceLimit() {
}

bool ClearAddressSpaceLimit() {
#if !defined(ARCH_CPU_64_BITS) || !BUILDFLAG(IS_POSIX)
#if !defined(ARCH_CPU_64_BITS) || !BUILDFLAG(IS_POSIX) || 1
Copy link
Member

Choose a reason for hiding this comment

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

|| defined(STARBOARD)

@@ -621,7 +622,7 @@ void FreeFullSlotSpan(PartitionRoot<internal::ThreadSafe>* root,
EXPECT_TRUE(slot_span->is_empty());
}

#if BUILDFLAG(IS_LINUX) || BUILDFLAG(IS_CHROMEOS)
#if 0// BUILDFLAG(IS_LINUX) || BUILDFLAG(IS_CHROMEOS)
Copy link
Member

Choose a reason for hiding this comment

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

() && !defined(STARBOARD)

@@ -341,6 +345,9 @@ absl::optional<std::vector<uint8_t>> ReadFileToBytes(const FilePath& path) {
})) {
return absl::nullopt;
}
#else
std::vector<uint8_t> bytes;
Copy link
Member

Choose a reason for hiding this comment

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

Add a NOTIMPLEMENTED() or equivalent help to help highlight when this no-op code is executed.

ScopedFILE file_stream(OpenFile(path, "rb"));
if (!file_stream)
return false;
return ReadStreamToStringWithMaxSize(file_stream.get(), max_size, contents);
#endif
return false;
Copy link
Member

Choose a reason for hiding this comment

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

#else ... #endif so that this doesn't become unreachable code on non-cobalt builds.

And also add a NOTIMPLEMENTED() or equivalent help to help highlight when this no-op code is executed.

#if !(BUILDFLAG(IS_IOS) || BUILDFLAG(IS_ANDROID))

TEST(BreakIteratorTest, BreakWordChinese) {
TEST(BreakIteratorTest, DISABLED_BreakWordChinese) {
Copy link
Member

Choose a reason for hiding this comment

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

Instead of these, why not || defined(STARBOARD) on the #if above that encloses these three tests.

Copy link
Contributor

Choose a reason for hiding this comment

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

There are actually some discussions happening here: #2074. The original idea here is to use DISABLED_ is to better tracking tests. But I don't think that point stands anymore. There will be tests that need to use || defined(STARBOARD) to disable parts of it, because they can't be compiled. I think we should have this questions discussed in meetings to keep everyone in the same page.

DCHECK(result);
}

// bool LockImpl::Try() {
Copy link
Member

Choose a reason for hiding this comment

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

Delete commented out obsolete code

@sherryzy
Copy link
Contributor

sherryzy commented Jan 9, 2024

Btw I'm getting a little bit confused on how are we using this branch feature/update-base vs feature/all-upstream-update. Is this just purely for reviewing all past code change in feature/all-upstream-update?

@andrewsavage1
Copy link
Contributor Author

Btw I'm getting a little bit confused on how are we using this branch feature/update-base vs feature/all-upstream-update. Is this just purely for reviewing all past code change in feature/all-upstream-update?

More or less, yeah, I'm thinking of feature/all-upstream-update as a place where we can make more hacky changes that would need to be cleaned up before being merged into trunk, and feature/update-base as a staging ground to clean up those changes and prepare for the final merge into trunk

@kaidokert
Copy link
Member

Is this obsolete / can close ?

@andrewsavage1
Copy link
Contributor Author

Yes this is obsolete

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.

4 participants