C++20 not on all builders?

[Roland Bock]

Hi,

Not that I really need it, but I tried adding constexpr strings in a unittest since we can now use c++20, e.g.

// Topic is an alias for std::string.

constexpr Topic topic1 = "user.policy";

It compiles just fine on most builders in the CQ. But on Android, I am getting

Tryjob [chromium/try/android-x86-rel](https://cr-buildbucket.appspot.com/build/8763890318104482337) has failed with summary [(view all results)](https://chromium-review.googlesource.com/c/5045490?checksPatchset=2&tab=checks):

---
#### Step _compile (with patch)_ failed. Error logs are shown below:
```
CXX obj/components/invalidation/impl/unit_tests/fcm_invalidation_service_unittest.o
../../third_party/llvm-build/Release+Asserts/bin/clang++ -MMD -MF obj/components/invalidation/impl/u...(too long)
../../components/invalidation/impl/fcm_invalidation_service_unittest.cc:43:17: error: constexpr variable 'topic1' must be initialized by a constant expression
   43 | constexpr Topic topic1 = "user.policy";
      |                 ^        ~~~~~~~~~~~~~
../../components/invalidation/impl/fcm_invalidation_service_unittest.cc:43:17: note: pointer to subobject of heap-allocated object is not a constant expression
```
##### ...The message was too long...
#### More information in raw_io.output_text[failure_summary]

Is that expected?

Thanks,

Roland

--

--

Roland Bock

Software Engineering Manager

rb...@google.com

Google Germany GmbH

Erika-Mann-Straße 33

80636 München

Geschäftsführer: Paul Manicle, Liana Sebastian

Registergericht und -nummer: Hamburg, HRB 86891

Sitz der Gesellschaft: Hamburg

This e-mail is confidential. If you received this communication by mistake, please don't forward it to anyone else, please erase all copies and attachments, and please let me know that it has gone to the wrong person.

The above terms reflect a potential business arrangement, are provided solely as a basis for further discussion, and are not intended to be and do not constitute a legally binding obligation. No legally binding obligations will be created, implied, or inferred until an agreement in final form is executed in writing by all parties involved.

[Dana Jansens]

We should have the same libc++ and same clang there, so no.. can you file a bug?

--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev
---
You received this message because you are subscribed to the Google Groups "Chromium-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-dev...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/CAHq1K7RUx8kxxqkXTAUHrA%2BCT6GE%2BoFbdQRYk-C%3DiFtg0OU5VA%40mail.gmail.com.

[Roland Bock]

Sure, which component?

[Dana Jansens]

LLVM>Build

However, looking at your CL, I see you're building constexpr std::string in a non-constexpr context. Then those can only be constexpr if the string fits into the SSO. Probably android has a shorter SSO, so this isn't so surprising. Relying on the SSO for getting constexpr std::string constants is not a great idea anyhow, and we should still be using const char[] for constants.

[Roland Bock]

TIL.

OK, I was too naive :-) Thanks for looking into it!

So I will change my CL and not file a bug.

Thanks!

[Nico Weber]

On Mon, Nov 20, 2023, 2:36 PM Dana Jansens <dan...@chromium.org> wrote:

LLVM>Build

However, looking at your CL, I see you're building constexpr std::string in a non-constexpr context. Then those can only be constexpr if the string fits into the SSO. Probably android has a shorter SSO,

The bot does 32-bit builds, and SSO is shorter on 32-bit (std::string stores data in a pointer for short strings, and 32-bit pointers are smaller than 64-bit pointers).

Other than that, I agree with Dana on everything she says 🙂

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/CAHtyhaStQ6TuS5JTjZ3n4nYk9tRfm3OUVQdejBMfs8hasyRnsQ%40mail.gmail.com.