Abseil now allowed in Chromium code

[Peter Kasting]

Chromium contributors (and bcc abseil-io as FYI),

TLDR: It's now possible to use Abseil in first-party Chromium code.

• Only absl::variant is currently allowed.
• See http://chromium-cpp.appspot.com/ for the current status of features. To request more features, email c...@chromium.org.
• To use an allowed feature, have your target depend appropriately on "//third_party/abseil-cpp:absl", and #include the relevant header from third_party/abseil-cpp/absl/.  
  

Longer version follows

As of today, first-party code in Chromium is allowed to use Abseil. As with new versions of the C++ standard, support is initially restricted to features which are explicitly allowlisted; consideration of a feature is by request. To begin with, absl::variant is the only allowed feature.

To use an Abseil feature in your code:

• #include the relevant header(s) from third_party/abseil-cpp/absl/.  For example, #include "third_party/abseil-cpp/absl/types/variant.h".
• In the relevant BUILD.gn, add "//third_party/abseil-cpp:absl" to your target's deps or "public_deps" as appropriate. Because of visibility restrictions designed to hinder inappropriate use, you will need to use public_deps if your #include is in a .h that another target #includes.

To see or request allowed features:

• To see the current status of features, visit http://chromium-cpp.appspot.com/. Some features are explicitly banned for various reasons; most remain banned-by-default as "TBD".
• To request consideration of a TBD or banned feature, mail c...@chromium.org, ideally with a use case and relevant context.
• After two years, style arbiters will explicitly allow or ban all remaining TBD features.

FAQ:

• What about third-party code?
• Code in third_party can use Abseil freely, except for features explicitly banned due to incompatibility; code that needs those features is allowed if it won't actually cause problems. Contact cxx@ for more information.
• What do you mean, incompatibility?  And why are there weird visibility restrictions?
• Certain Abseil features (e.g. absl::any, ABSL_FLAG) rely on either RTTI (which Chromium disables) or a workaround called FastTypeId that isn't compatible with the component build. Using such features risks subtle bugs when code compiles and links but doesn't behave as expected, so these are banned from being linked into Chromium.
• Partly to enforce these bans, both the .gn and DEPS files have various restrictions (such as include_rules and visibility adjustments) designed to hinder accidental misuse. It's not impossible, but hopefully we made it hard to accidentally blow your leg off.
• What about first-party code that needs to interact with third-party code that uses types Chromium doesn't currently allow?
• Assuming the third-party use is otherwise allowed (see above), you are allowed to use banned features as minimally necessary at the third-party code boundary to interface with it. Convert to Chromium types/features/etc. as early as possible. Contact cxx@ for more information.
• Will we be replacing base:: types like Span and Optional with absl:: ones?
• All other things being equal, we would slightly prefer to use an absl:: type to an identical base:: one.  That's one less thing we have to maintain, and we trust the Abseil team.
  
• For cases like Span, the base:: type is more std::-compliant than the absl:: one. Since in such cases our ultimate goal would be to move to the std:: type, we won't migrate to absl:: unless compliance improves to at least match base::.
• For cases like time handling where there are significant design/API differences, we'd need a compelling reason to migrate existing code, since a migration plan would be significantly more complicated. 
• In the other cases, we won't migrate unless there's a migration plan (and responsible owner(s)). The default plan is "make base:: API match absl::; change base:: implementation to be an alias; replace usage of base:: with absl:: everywhere; remove base:: implementation". Those steps aren't free, and someone needs to be willing to pay the cost.
  
• When Chromium supports C++17, will we replace absl:: types with std:: ones?
• Yes, assuming we can do so without regressing security guarantees. We have various hardening tests that ensure certain misuses cause checkfailures. We won't migrate code to STL implementations that don't provide at least equivalent checks we can enable. The most likely path in many cases is that libc++ adds such checks.  I'm sure pal...@chromium.org would love to talk to you about this. :D
• Something something Chromium C++14 Abseil support guarantees NaCl toolchain compatibility something uh oh?
• If you have no idea what this question could be about, you don't need to worry about it.
• Leadership on various sides have made commitments that should ensure it's safe to start relying on Abseil, and we won't get stuck in a year or two with libraries that stop working, unsupported code, etc.  I don't know what all is public so that's all I'll say.
• Why can't I use ___________ from Abseil yet?
• Likely because we haven't formally considered it.  Propose it per instructions above.
• To make sure we don't unintentionally cause catastrophe, we reserve the right to slow the adoption rate of even clearly-OK features.  But in the limit that should be weeks, not years.
• Abseil is cool, now can I get support for {boost, EASTL, $your_favorite_here}?
• We'll consider anything reasonable, but no guarantees.  (Author's note: my recent proposition to add a couple Boost items already on Google's officially approved list was not met with great enthusiasm, if this tells you anything.)
• pkasting, you're so amazing, I just want to hear more from you. Is there anything else you haven't mentioned?
• Why yes! Gtest support for Abseil has also been enabled, which provides pretty-printers for various types.  For example, here's the output of an EXPECT_EQ() on two absl::variants, one containing <bool>(false), and one containing <gfx::Rect>({1, 2, 3, 4}):
  
  Before:
  error: Expected equality of these values:
    V(false)
      Which is: 24-byte object <00-F9 63-74 F7-7F 00-00 00-00 00-00 FA-00 00-00 01-00 00-00 00-00 00-00>
    c
      Which is: 24-byte object <01-00 00-00 02-00 00-00 03-00 00-00 04-00 00-00 02-00 00-00 00-00 00-00>
  
  After:
  error: Expected equality of these values:
    V(false)
      Which is: ('<type>(index = 1)' with value false)
    c
      Which is: ('<type>(index = 2)' with value 1,2 3x4)
  

Thanks

• The Abseil team, who have been very helpful in working with Chromium to support our needs.
• mbonadei@ and danilchap@, the people mainly responsible for keeping Abseil rolled into Chromium's tree and functioning as desired, including testing and adding various things to resolve blockers.
• cxx@ et al., especially those who sent explicit input on this, including (but not limited to) danakj@, jbroman@, jdoerrie@, gab@, jam@, dpranke@, dcheng@.
• If you read this far, you!  Hope it was informative.

PK

P.S. OK, I admit, no one asked that last FAQ.

[Yutaka Hirano]

-chromium-dev, -cxx

We have some restrictions on the use of base/ in blink. Do we have a similar policy for abseil?

--
You received this message because you are subscribed to the Google Groups "cxx" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cxx+uns...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/cxx/CAAHOzFBcZhhOXwVNaPtF5h82goGqMCFYOGu8k3D1wnYg60bMww%40mail.gmail.com.

[Peter Kasting]

On Wed, Aug 5, 2020 at 1:42 AM Yutaka Hirano <yhi...@chromium.org> wrote:

-chromium-dev, -cxx

We have some restrictions on the use of base/ in blink. Do we have a similar policy for abseil?

I think Blink owners would need to define this -- my perspective is just in terms of removing Chromium-wide roadblocks.  I don't know how, say, Oilpan considerations might cause Blink to want further restrictions  on potential Abseil use.

PK

[Jeremy Roman]

The restrictions should largely be similar to using STL and base types -- where there are reasons that WTF has provided something else, the WTF one should probably be used (for example, string and collection types). Aside from those anything that's good in Chromium should be fine.

You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABihn6HpBWHSR9B2-%3DjM%3DvX2j8wnOo-mroanX6JnCJhhg8BqSQ%40mail.gmail.com.

[wei cheng]

Hi,

I want to use randen_engine, so I add code in \third_party\abseil-cpp\absl\random\random.h

// Make randen_engine available for direct usage, because

// absl::BitGen/InsecureBitGen uses always-on process-bound salt for seeded

// generators.

template <typename T>

using randen_engine = random_internal::randen_engine<T>;

then in my codes, \third_party\blink\renderer\core\farbling\brave_session_cache.h

typedef absl::randen_engine<uint64_t> FarblingPRNG;

third_party\blink\renderer\core\farbling\brave_session_cache.cc

int BraveSessionCache::FarbledInteger(FarbleKey key,

                                      int spoof_value,

                                      int min_random_offset,

                                      int max_random_offset) {

  if (farbled_integers_.count(key) == 0) {

    FarblingPRNG prng = MakePseudoRandomGenerator(key);

    farbled_integers_[key] =

        prng() % (1 + max_random_offset - min_random_offset) +

        min_random_offset;

  }

  return farbled_integers_[key] + spoof_value;

}

but failed as below

c:\code\chromium_git\chromium\src>ninja -C out\Release_GN_x86 cef
ninja: Entering directory `out\Release_GN_x86'
[0/1] Regenerating ninja files
[10/23] LINK v8_context_snapshot_generator.exe v8_context_snapshot_generator.exe.pdb
FAILED: v8_context_snapshot_generator.exe v8_context_snapshot_generator.exe.pdb
ninja -t msvc -e environment.x86 -- ..\..\third_party\llvm-build\Release+Asserts\bin\lld-link.exe /nologo -libpath:..\..\third_party\llvm-build\Release+Asserts\lib\clang\12.0.0\lib\windows "-libpath:..\..\..\..\..\..\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.28.29910\ATLMFC\lib\x86" "-libpath:..\..\..\..\..\..\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.28.29910\lib\x86" "-libpath:..\..\..\..\..\..\Program Files (x86)\Windows Kits\10\lib\10.0.19041.0\ucrt\x86" "-libpath:..\..\..\..\..\..\Program Files (x86)\Windows Kits\10\lib\10.0.19041.0\um\x86" /OUT:./v8_context_snapshot_generator.exe /PDB:./v8_context_snapshot_generator.exe.pdb @./v8_context_snapshot_generator.exe.rsp
lld-link: error: undefined symbol: public: __thiscall absl::random_internal::Randen::Randen(void)
>>> referenced by .\..\..\third_party\blink\renderer\core\farbling\brave_session_cache.cc:357
>>>               blink_core.lib(brave_session_cache.obj):(public: bool __thiscall brave::BraveSessionCache::AllowFontFamily(class blink::WebContentSettingsClient *, class WTF::AtomicString const &))
>>> referenced by .\..\..\third_party\blink\renderer\core\farbling\brave_session_cache.cc:343
>>>               blink_core.lib(brave_session_cache.obj):(public: int __thiscall brave::BraveSessionCache::FarbledInteger(enum brave::FarbleKey, int, int, int))
>>> referenced by .\..\..\third_party\blink\renderer\core\farbling\brave_session_cache.cc:329
>>>               blink_core.lib(brave_session_cache.obj):(public: class WTF::String __thiscall brave::BraveSessionCache::FarbledUserAgent(class WTF::String))
>>> referenced 1 more times

what should I do to fix it? thankx

[K. Moon]

You should start a new thread for this kind of question, rather than replying to this one.

Additionally, if you're modifying Abseil, I don't think this question has anything to do with Chromium. You could try asking on an Abseil discussion group, but I suspect you're on your own, since you're modifying APIs meant for internal Abseil use only.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/b5885d2a-e202-4e75-ad2f-22e5902080a2n%40chromium.org.