absl::InlinedVector is an implementation of the std::vector API that stores up to a fixed number of elements inside the object itself, meaning that heap allocation can be avoided in common cases. Heap allocation is used if the built-in storage turns out not to be big enough.
base::StackVector is based on a similar idea, but has a slightly awkward API due to delegating to a std::vector internally. For example, you need to write
v->push_back() rather than
v.push_back(). It also takes a bit more memory because of the way it is implemented.
My proposal is to
1) Permit absl::InlinedVector, and comment that base::StackVector should not be used for new code.
2) Replace all users of base::StackVector with absl::InlinedVector (mostly trivial).
3) Remove base::StackVector and its supporting classes.
The benefit is less Chromium-specific code to maintain and a better implementation of this pattern.
The main use case for InlinedVector is small temporary vectors that are created during the lifetime of a function and then discarded.
InlinedVector should only be used in performance-critical functions. Other functions should continue to use std::vector + reserve() as it results in slightly smaller code.
https://chromium-review.googlesource.com/c/chromium/src/+/4672187 demonstrates a 40 byte binary size increase from switching std::vector to absl::InlinedVector.