tree: 2f955d50dbfbd345d1d45e9aa98f02b9b55d4d4a [path history] [tgz]
  1. test/
  2. BUILD
  3. conversion_function_helpers.h
  4. cpp_std_allocator.rs
  5. headers.bzl
  6. README.md
  7. slice_ptr.rs
  8. std_allocator.h
  9. string.rs
  10. string_view.rs
  11. unique_ptr.rs
  12. vector.rs
  13. vector_partial_eq.rs
support/cc_std_impl/README.md

This directory contains extra Rust customizations for cc_std.

Making backwards-incompatible changes

Like most directories in support/, changes to this file take effect instantly. To make version-dependent changes, pair them with a feature flag and cfg guard.

For example, consider std::vector: a new pending release might change the layout of std::vector, so that instead of using begin/end/capacity_end pointers, it uses a begin pointer and size/capacity integers. This can be released as so:

// cc_std_impl/unique_ptr.rs
#[cfg(not(feature = "len_capacity_encoding"))]
#[repr(C)]
pub struct vector<T> {
    begin: *const T,
    _end: *const T,
    _capacity_end: *const T,
}

/// 2. This layout is experimental.
#[cfg(feature = "len_capacity_encoding")]
#[repr(C)]
pub struct vector<T> {
    begin: *const T,
    len: usize,
    capacity: usize,
}
# cc_std/BUILD
bindings_for_toolchain_headers(
    name = "cc_std",
    ...
    crate_features = ["len_capacity_encoding"],
    ...
)

The old release, which contains the old copy of BUILD, will not pass the len_capacity_encoding feature, and will use the previous layout.

Crubit when built at head, and for the next release, will use the new copy of BUILD, which sets the feature, and obtains the new struct definition.

Even though the source code is live-at-head, changes like this will be release-gated through the crate features, which are not.