BLI: put C++ data structures in "blender" namespace instead of "BLI"

We plan to use the "blender" namespace in other modules as well.

source/blender/blenkernel/intern/simulation.cc

@@ -54,9 +54,9 @@
 #include "DEG_depsgraph.h"
 #include "DEG_depsgraph_query.h"
 
-using BLI::ArrayRef;
-using BLI::float3;
-using BLI::MutableArrayRef;
+using blender::ArrayRef;
+using blender::float3;
+using blender::MutableArrayRef;
 
 static void simulation_init_data(ID *id)
 {

source/blender/blenlib/BLI_allocator.hh

@@ -19,9 +19,9 @@
 /** \file
  * \ingroup bli
  *
- * An `Allocator` can allocate and deallocate memory. It is used by containers such as BLI::Vector.
- * The allocators defined in this file do not work with standard library containers such as
- * std::vector.
+ * An `Allocator` can allocate and deallocate memory. It is used by containers such as
+ * blender::Vector. The allocators defined in this file do not work with standard library
+ * containers such as std::vector.
  *
  * Every allocator has to implement two methods:
  *   void *allocate(size_t size, size_t alignment, const char *name);
@@ -46,7 +46,7 @@
 #include "BLI_math_base.h"
 #include "BLI_utildefines.h"
 
-namespace BLI {
+namespace blender {
 
 /**
  * Use Blender's guarded allocator (aka MEM_*). This should always be used except there is a
@@ -99,6 +99,6 @@ class RawAllocator {
   }
 };
 
-}  // namespace BLI
+}  // namespace blender
 
 #endif /* __BLI_ALLOCATOR_HH__ */

source/blender/blenlib/BLI_array.hh

@@ -19,23 +19,23 @@
 /** \file
  * \ingroup bli
  *
- * A `BLI::Array<T>` is a container for a fixed size array the size of which is NOT known at
+ * A `blender::Array<T>` is a container for a fixed size array the size of which is NOT known at
  * compile time.
  *
  * If the size is known at compile time, `std::array<T, N>` should be used instead.
  *
- * BLI::Array should usually be used instead of BLI::Vector whenever the number of elements is
- * known at construction time. Note however, that BLI::Array will default construct all elements
- * when initialized with the size-constructor. For trivial types, this does nothing. In all other
- * cases, this adds overhead. If this becomes a problem, a different constructor which does not do
- * default construction can be added.
+ * blender::Array should usually be used instead of blender::Vector whenever the number of elements
+ * is known at construction time. Note however, that blender::Array will default construct all
+ * elements when initialized with the size-constructor. For trivial types, this does nothing. In
+ * all other cases, this adds overhead. If this becomes a problem, a different constructor which
+ * does not do default construction can be added.
  *
  * A main benefit of using Array over Vector is that it expresses the intent of the developer
  * better. It indicates that the size of the data structure is not expected to change. Furthermore,
  * you can be more certain that an array does not overallocate.
  *
- * BLI::Array supports small object optimization to improve performance when the size turns out to
- * be small at run-time.
+ * blender::Array supports small object optimization to improve performance when the size turns out
+ * to be small at run-time.
  */
 
 #include "BLI_allocator.hh"
@@ -44,7 +44,7 @@
 #include "BLI_memory_utils.hh"
 #include "BLI_utildefines.h"
 
-namespace BLI {
+namespace blender {
 
 template<
     /**
@@ -341,6 +341,6 @@ class Array {
   }
 };
 
-}  // namespace BLI
+}  // namespace blender
 
 #endif /* __BLI_ARRAY_HH__ */

source/blender/blenlib/BLI_array_ref.hh

@@ -20,26 +20,26 @@
 /** \file
  * \ingroup bli
  *
- * A `BLI::ArrayRef<T>` references an array that is owned by someone else. It is just a pointer and
- * a size. Since the memory is not owned, ArrayRef should not be used to transfer ownership. The
- * array cannot be modified through the ArrayRef. However, if T is a non-const pointer, the
- * pointed-to elements can be modified.
+ * An `blender::ArrayRef<T>` references an array that is owned by someone else. It is just a
+ * pointer and a size. Since the memory is not owned, ArrayRef should not be used to transfer
+ * ownership. The array cannot be modified through the ArrayRef. However, if T is a non-const
+ * pointer, the pointed-to elements can be modified.
  *
- * There is also `BLI::MutableArrayRef<T>`. It is mostly the same as ArrayRef, but allows the array
- * to be modified.
+ * There is also `blender::MutableArrayRef<T>`. It is mostly the same as ArrayRef, but allows the
+ * array to be modified.
  *
  * An (Mutable)ArrayRef can refer to data owned by many different data structures including
- * BLI::Vector, BLI::Array, BLI::VectorSet, std::vector, std::array, std::string,
+ * blender::Vector, blender::Array, blender::VectorSet, std::vector, std::array, std::string,
  * std::initializer_list and c-style array.
  *
- * `BLI::ArrayRef<T>` should be your default choice when you have to pass a read-only array into a
- * function. It is better than passing a `const Vector &`, because then the function only works for
- * vectors and not for e.g. arrays. Using ArrayRef as function parameter makes it usable in more
- * contexts, better expresses the intent and does not sacrifice performance. It is also better than
- * passing a raw pointer and size separately, because it is more convenient and safe.
+ * `blender::ArrayRef<T>` should be your default choice when you have to pass a read-only array
+ * into a function. It is better than passing a `const Vector &`, because then the function only
+ * works for vectors and not for e.g. arrays. Using ArrayRef as function parameter makes it usable
+ * in more contexts, better expresses the intent and does not sacrifice performance. It is also
+ * better than passing a raw pointer and size separately, because it is more convenient and safe.
  *
- * `BLI::MutableArrayRef<T>` can be used when a function is supposed to return an array, the size
- * of which is known before the function is called. One advantage of this approach is that the
+ * `blender::MutableArrayRef<T>` can be used when a function is supposed to return an array, the
+ * size of which is known before the function is called. One advantage of this approach is that the
  * caller is responsible for allocation and deallocation. Furthermore, the function can focus on
  * its task, without having to worry about memory allocation. Alternatively, a function could
  * return an Array or Vector.
@@ -64,7 +64,7 @@
 #include "BLI_memory_utils.hh"
 #include "BLI_utildefines.h"
 
-namespace BLI {
+namespace blender {
 
 /**
  * References an array of type T that is owned by someone else. The data in the array cannot be
@@ -625,6 +625,6 @@ void assert_same_size(const T1 &v1, const T2 &v2, const T3 &v3)
 #endif
 }
 
-} /* namespace BLI */
+} /* namespace blender */
 
 #endif /* __BLI_ARRAY_REF_HH__ */

source/blender/blenlib/BLI_color.hh

@@ -21,7 +21,7 @@
 
 #include "BLI_math_color.h"
 
-namespace BLI {
+namespace blender {
 
 struct Color4f {
   float r, g, b, a;
@@ -87,6 +87,6 @@ struct Color4b {
   }
 };
 
-}  // namespace BLI
+}  // namespace blender
 
 #endif /* __BLI_COLOR_HH__ */

source/blender/blenlib/BLI_dot_export.hh

@@ -34,7 +34,7 @@
 
 #include <sstream>
 
-namespace BLI {
+namespace blender {
 namespace DotExport {
 
 class Graph;
@@ -208,7 +208,7 @@ class NodePort {
   void to_dot_string(std::stringstream &ss) const;
 };
 
-class Edge : BLI::NonCopyable, BLI::NonMovable {
+class Edge : blender::NonCopyable, blender::NonMovable {
  protected:
   AttributeList m_attributes;
   NodePort m_a;
@@ -284,6 +284,6 @@ class NodeWithSocketsRef {
 };
 
 }  // namespace DotExport
-}  // namespace BLI
+}  // namespace blender
 
 #endif /* __BLI_DOT_EXPORT_HH__ */

source/blender/blenlib/BLI_dot_export_attribute_enums.hh

@@ -19,7 +19,7 @@
 
 #include "BLI_string_ref.hh"
 
-namespace BLI {
+namespace blender {
 namespace DotExport {
 
 enum class Attr_rankdir {
@@ -120,6 +120,6 @@ inline StringRef dirType_to_string(Attr_dirType value)
 }
 
 }  // namespace DotExport
-}  // namespace BLI
+}  // namespace blender
 
 #endif /* __BLI_DOT_EXPORT_ATTRIBUTE_ENUMS_HH__ */

source/blender/blenlib/BLI_float2.hh

@@ -19,7 +19,7 @@
 
 #include "BLI_float3.hh"
 
-namespace BLI {
+namespace blender {
 
 struct float2 {
   float x, y;
@@ -81,6 +81,6 @@ struct float2 {
   }
 };
 
-}  // namespace BLI
+}  // namespace blender
 
 #endif /* __BLI_FLOAT2_HH__ */

source/blender/blenlib/BLI_float3.hh

@@ -21,7 +21,7 @@
 
 #include "BLI_math_vector.h"
 
-namespace BLI {
+namespace blender {
 
 struct float3 {
   float x, y, z;
@@ -213,6 +213,6 @@ struct float3 {
   }
 };
 
-}  // namespace BLI
+}  // namespace blender
 
 #endif /* __BLI_FLOAT3_HH__ */

source/blender/blenlib/BLI_float4x4.hh

@@ -20,7 +20,7 @@
 #include "BLI_float3.hh"
 #include "BLI_math_matrix.h"
 
-namespace BLI {
+namespace blender {
 
 struct float4x4 {
   float values[4][4];
@@ -110,6 +110,6 @@ struct float4x4 {
   }
 };
 
-}  // namespace BLI
+}  // namespace blender
 
 #endif /* __BLI_FLOAT4X4_HH__ */

source/blender/blenlib/BLI_hash.hh

@@ -20,8 +20,8 @@
 /** \file
  * \ingroup bli
  *
- * A specialization of `BLI::DefaultHash<T>` provides a hash function for values of type T. This
- * hash function is used by default in hash table implementations in blenlib.
+ * A specialization of `blender::DefaultHash<T>` provides a hash function for values of type T.
+ * This hash function is used by default in hash table implementations in blenlib.
  *
  * The actual hash function is in the `operator()` method of DefaultHash<T>. The following code
  * computes the hash of some value using DefaultHash.
@@ -30,8 +30,8 @@
  *   DefaultHash<T> hash_function;
  *   uint32_t hash = hash_function(value);
  *
- * Hash table implementations like BLI::Set support heterogeneous key lookups. That means that one
- * can do a lookup with a key of type A in a hash table that stores keys of type B. This is
+ * Hash table implementations like blender::Set support heterogeneous key lookups. That means that
+ * one can do a lookup with a key of type A in a hash table that stores keys of type B. This is
  * commonly done when B is std::string, because the conversion from e.g. a StringRef to std::string
  * can be costly and is unnecessary. To make this work, values of type A and B that compare equal
  * have to have the same hash value. This is achieved by defining potentially multiple `operator()`
@@ -57,7 +57,7 @@
  *   specialization to the DefaultHash struct. This can be done by writing code like below in
  *   either global or BLI namespace.
  *
- *     template<> struct BLI::DefaultHash<TheType> {
+ *     template<> struct blender::DefaultHash<TheType> {
  *       uint32_t operator()(const TheType &value) const {
  *         return ...;
  *       }
@@ -83,7 +83,7 @@
 #include "BLI_string_ref.hh"
 #include "BLI_utildefines.h"
 
-namespace BLI {
+namespace blender {
 
 /**
  * If there is no other specialization of DefaultHash for a given type, try to call `hash()` on the
@@ -206,6 +206,6 @@ template<typename T1, typename T2> struct DefaultHash<std::pair<T1, T2>> {
   }
 };
 
-}  // namespace BLI
+}  // namespace blender
 
 #endif /* __BLI_HASH_HH__ */

source/blender/blenlib/BLI_hash_tables.hh

@@ -33,7 +33,7 @@
 #include "BLI_utildefines.h"
 #include "BLI_vector.hh"
 
-namespace BLI {
+namespace blender {
 
 /* -------------------------------------------------------------------- */
 /** \name Constexpr Utility Functions
@@ -345,6 +345,6 @@ struct DefaultEquality {
   }
 };
 
-}  // namespace BLI
+}  // namespace blender
 
 #endif /* __BLI_OPEN_ADDRESSING_HH__ */

source/blender/blenlib/BLI_index_mask.hh

@@ -41,7 +41,7 @@
 #include "BLI_array_ref.hh"
 #include "BLI_index_range.hh"
 
-namespace BLI {
+namespace blender {
 
 class IndexMask {
  private:
@@ -207,6 +207,6 @@ class IndexMask {
   }
 };
 
-}  // namespace BLI
+}  // namespace blender
 
 #endif /* __BLI_INDEX_MASK_HH__ */

source/blender/blenlib/BLI_index_range.hh

@@ -20,7 +20,7 @@
 /** \file
  * \ingroup bli
  *
- * A `BLI::IndexRange` wraps an interval of non-negative integers. It can be used to reference
+ * A `blender::IndexRange` wraps an interval of non-negative integers. It can be used to reference
  * consecutive elements in an array. Furthermore, it can make for loops more convenient and less
  * error prone, especially when using nested loops.
  *
@@ -35,10 +35,10 @@
  *    for (uint j : IndexRange(20)) {
  *      for (uint k : IndexRange(30)) {
  *
- * Some containers like BLI::Vector have an index_range() method. This will return the IndexRange
- * that contains all indices that can be used to access the container. This is particularly useful
- * when you want to iterate over the indices and the elements (much like Python's enumerate(), just
- * worse). Again, I think the second example here is better:
+ * Some containers like blender::Vector have an index_range() method. This will return the
+ * IndexRange that contains all indices that can be used to access the container. This is
+ * particularly useful when you want to iterate over the indices and the elements (much like
+ * Python's enumerate(), just worse). Again, I think the second example here is better:
  *
  *  for (uint i = 0; i < my_vector_with_a_long_name.size(); i++) {
  *    do_something(i, my_vector_with_a_long_name[i]);
@@ -64,7 +64,7 @@ namespace tbb {
 template<typename Value> class blocked_range;
 }
 
-namespace BLI {
+namespace blender {
 
 template<typename T> class ArrayRef;
 
@@ -236,6 +236,6 @@ class IndexRange {
   }
 };
 
-}  // namespace BLI
+}  // namespace blender
 
 #endif /* __BLI_INDEX_RANGE_HH__ */

source/blender/blenlib/BLI_linear_allocator.hh

@@ -29,7 +29,7 @@
 #include "BLI_utility_mixins.hh"
 #include "BLI_vector.hh"
 
-namespace BLI {
+namespace blender {
 
 template<typename Allocator = GuardedAllocator> class LinearAllocator : NonCopyable, NonMovable {
  private:
@@ -215,6 +215,6 @@ template<typename Allocator = GuardedAllocator> class LinearAllocator : NonCopya
   }
 };
 
-}  // namespace BLI
+}  // namespace blender
 
 #endif /* __BLI_LINEAR_ALLOCATOR_HH__ */

source/blender/blenlib/BLI_listbase_wrapper.hh

@@ -20,16 +20,16 @@
 /** \file
  * \ingroup bli
  *
- * `BLI::ListBaseWrapper` is a typed wrapper for the ListBase struct. That makes it safer and more
- * convenient to use in C++ in some cases. However, if you find yourself iterating over a linked
- * list a lot, consider to convert it into a vector for further processing. This improves
+ * `blender::ListBaseWrapper` is a typed wrapper for the ListBase struct. That makes it safer and
+ * more convenient to use in C++ in some cases. However, if you find yourself iterating over a
+ * linked list a lot, consider to convert it into a vector for further processing. This improves
  * performance and debugability.
  */
 
 #include "BLI_listbase.h"
 #include "DNA_listBase.h"
 
-namespace BLI {
+namespace blender {
 
 template<typename T> class ListBaseWrapper {
  private:
@@ -110,6 +110,6 @@ template<typename T> class ListBaseWrapper {
   }
 };
 
-} /* namespace BLI */
+} /* namespace blender */
 
 #endif /* __BLI_LISTBASE_WRAPPER_HH__ */

source/blender/blenlib/BLI_map.hh

@@ -20,16 +20,16 @@
 /** \file
  * \ingroup bli
  *
- * A `BLI::Map<Key, Value>` is an unordered associative container that stores key-value pairs. The
- * keys have to be unique. It is designed to be a more convenient and efficient replacement for
+ * A `blender::Map<Key, Value>` is an unordered associative container that stores key-value pairs.
+ * The keys have to be unique. It is designed to be a more convenient and efficient replacement for
  * `std::unordered_map`. All core operations (add, lookup, remove and contains) can be done in O(1)
  * amortized expected time.
  *
- * Your default choice for a hash map in Blender should be `BLI::Map`.
+ * Your default choice for a hash map in Blender should be `blender::Map`.
  *
- * BLI::Map is implemented using open addressing in a slot array with a power-of-two size. Every
- * slot is in one of three states: empty, occupied or removed. If a slot is occupied, it contains
- * a Key and Value instance.
+ * blender::Map is implemented using open addressing in a slot array with a power-of-two size.
+ * Every slot is in one of three states: empty, occupied or removed. If a slot is occupied, it
+ * contains a Key and Value instance.
  *
  * Benchmarking and comparing hash tables is hard, because many factors influence the result. The
  * performance of a hash table depends on the combination of the hash function, probing strategy,
@@ -38,7 +38,7 @@
  * that allow it to be optimized for a specific use case.
  *
  * A rudimentary benchmark can be found in BLI_map_test.cc. The results of that benchmark are there
- * as well. The numbers show that in this specific case BLI::Map outperforms std::unordered_map
+ * as well. The numbers show that in this specific case blender::Map outperforms std::unordered_map
  * consistently by a good amount.
  *
  * Some noteworthy information:
@@ -64,7 +64,7 @@
  * - The method names don't follow the std::unordered_map names in many cases. Searching for such
  *   names in this file will usually let you discover the new name.
  * - There is a StdUnorderedMapWrapper class, that wraps std::unordered_map and gives it the same
- *   interface as BLI::Map. This is useful for benchmarking.
+ *   interface as blender::Map. This is useful for benchmarking.
  */
 
 #include <unordered_map>
@@ -75,7 +75,7 @@
 #include "BLI_map_slots.hh"
 #include "BLI_probing_strategies.hh"
 
-namespace BLI {
+namespace blender {
 
 template<
     /**
@@ -1097,11 +1097,12 @@ class Map {
 };
 
 /**
- * A wrapper for std::unordered_map with the API of BLI::Map. This can be used for benchmarking.
+ * A wrapper for std::unordered_map with the API of blender::Map. This can be used for
+ * benchmarking.
  */
 template<typename Key, typename Value> class StdUnorderedMapWrapper {
  private:
-  using MapType = std::unordered_map<Key, Value, BLI::DefaultHash<Key>>;
+  using MapType = std::unordered_map<Key, Value, blender::DefaultHash<Key>>;
   MapType m_map;
 
  public:
@@ -1162,6 +1163,6 @@ template<typename Key, typename Value> class StdUnorderedMapWrapper {
   }
 };
 
-}  // namespace BLI
+}  // namespace blender
 
 #endif /* __BLI_MAP_HH__ */

source/blender/blenlib/BLI_map_slots.hh

@@ -20,7 +20,7 @@
 /** \file
  * \ingroup bli
  *
- * This file contains slot types that are supposed to be used with BLI::Map.
+ * This file contains slot types that are supposed to be used with blender::Map.
  *
  * Every slot type has to be able to hold a value of type Key, a value of type Value and state
  * information. A map slot has three possible states: empty, occupied and removed.
@@ -37,7 +37,7 @@
 
 #include "BLI_memory_utils.hh"
 
-namespace BLI {
+namespace blender {
 
 /**
  * The simplest possible map slot. It stores the slot state and the optional key and value
@@ -356,6 +356,6 @@ template<typename Key, typename Value> struct DefaultMapSlot<Key *, Value> {
   using type = IntrusiveMapSlot<Key *, Value, PointerKeyInfo<Key *>>;
 };
 
-}  // namespace BLI
+}  // namespace blender
 
 #endif /* __BLI_MAP_SLOTS_HH__ */

source/blender/blenlib/BLI_memory_utils.hh

@@ -25,7 +25,7 @@
 
 #include "BLI_utildefines.h"
 
-namespace BLI {
+namespace blender {
 
 /**
  * Call the default constructor on n consecutive elements. For trivially constructible types, this
@@ -249,6 +249,6 @@ template<size_t Size, size_t Alignment> class alignas(Alignment) AlignedBuffer {
   }
 };
 
-}  // namespace BLI
+}  // namespace blender
 
 #endif /* __BLI_MEMORY_UTILS_HH__ */

source/blender/blenlib/BLI_optional.hh

@@ -29,7 +29,7 @@
 #include <algorithm>
 #include <memory>
 
-namespace BLI {
+namespace blender {
 
 template<typename T> class Optional {
  private:
@@ -184,6 +184,6 @@ template<typename T> class Optional {
   }
 };
 
-} /* namespace BLI */
+} /* namespace blender */
 
 #endif /* __BLI_OPTIONAL_HH__ */

source/blender/blenlib/BLI_probing_strategies.hh

@@ -21,8 +21,8 @@
  * \ingroup bli
  *
  * This file implements different probing strategies. Those can be used by different hash table
- * implementations like BLI::Set and BLI::Map. A probing strategy produces a sequence of values
- * based on an initial hash value.
+ * implementations like blender::Set and blender::Map. A probing strategy produces a sequence of
+ * values based on an initial hash value.
  *
  * A probing strategy has to implement the following methods:
  * - Constructor(uint32_t hash): Start a new probing sequence based on the given hash.
@@ -56,7 +56,7 @@
 
 #include "BLI_sys_types.h"
 
-namespace BLI {
+namespace blender {
 
 /**
  * The simplest probing strategy. It's bad in most cases, because it produces clusters in the hash
@@ -245,6 +245,6 @@ using DefaultProbingStrategy = PythonProbingStrategy<>;
 
 // clang-format on
 
-}  // namespace BLI
+}  // namespace blender
 
 #endif /* __BLI_PROBING_STRATEGIES_HH__ */

source/blender/blenlib/BLI_set.hh

@@ -20,15 +20,15 @@
 /** \file
  * \ingroup bli
  *
- * A `BLI::Set<Key>` is an unordered container for unique elements of type `Key`. It is designed to
- * be a more convenient and efficient replacement for `std::unordered_set`. All core operations
- * (add, remove and contains) can be done in O(1) amortized expected time.
+ * A `blender::Set<Key>` is an unordered container for unique elements of type `Key`. It is
+ * designed to be a more convenient and efficient replacement for `std::unordered_set`. All core
+ * operations (add, remove and contains) can be done in O(1) amortized expected time.
  *
- * In most cases, your default choice for a hash set in Blender should be `BLI::Set`.
+ * In most cases, your default choice for a hash set in Blender should be `blender::Set`.
  *
- * BLI::Set is implemented using open addressing in a slot array with a power-of-two size. Every
- * slot is in one of three states: empty, occupied or removed. If a slot is occupied, it contains
- * an instance of the key type.
+ * blender::Set is implemented using open addressing in a slot array with a power-of-two size.
+ * Every slot is in one of three states: empty, occupied or removed. If a slot is occupied, it
+ * contains an instance of the key type.
  *
  * Benchmarking and comparing hash tables is hard, because many factors influence the result. The
  * performance of a hash table depends on the combination of the hash function, probing strategy,
@@ -37,7 +37,7 @@
  * points that allow it to be optimized for a specific use case.
  *
  * A rudimentary benchmark can be found in BLI_set_test.cc. The results of that benchmark are
- * there as well. The numbers show that in this specific case BLI::Set outperforms
+ * there as well. The numbers show that in this specific case blender::Set outperforms
  * std::unordered_set consistently by a good amount.
  *
  * Some noteworthy information:
@@ -59,7 +59,7 @@
  * - The method names don't follow the std::unordered_set names in many cases. Searching for such
  *   names in this file will usually let you discover the new name.
  * - There is a StdUnorderedSetWrapper class, that wraps std::unordered_set and gives it the same
- *   interface as BLI::Set. This is useful for benchmarking.
+ *   interface as blender::Set. This is useful for benchmarking.
  *
  * Possible Improvements:
  * - Use a branchless loop over slots in grow function (measured ~10% performance improvement when
@@ -78,7 +78,7 @@
 #include "BLI_probing_strategies.hh"
 #include "BLI_set_slots.hh"
 
-namespace BLI {
+namespace blender {
 
 template<
     /** Type of the elements that are stored in this set. It has to be movable. Furthermore, the
@@ -684,11 +684,12 @@ class Set {
 };
 
 /**
- * A wrapper for std::unordered_set with the API of BLI::Set. This can be used for benchmarking.
+ * A wrapper for std::unordered_set with the API of blender::Set. This can be used for
+ * benchmarking.
  */
 template<typename Key> class StdUnorderedSetWrapper {
  private:
-  using SetType = std::unordered_set<Key, BLI::DefaultHash<Key>>;
+  using SetType = std::unordered_set<Key, blender::DefaultHash<Key>>;
   SetType m_set;
 
  public:
@@ -763,6 +764,6 @@ template<typename Key> class StdUnorderedSetWrapper {
   }
 };
 
-}  // namespace BLI
+}  // namespace blender
 
 #endif /* __BLI_SET_HH__ */

source/blender/blenlib/BLI_set_slots.hh

@@ -20,7 +20,7 @@
 /** \file
  * \ingroup bli
  *
- * This file contains different slot types that are supposed to be used with BLI::Set.
+ * This file contains different slot types that are supposed to be used with blender::Set.
  *
  * Every slot type has to be able to hold a value of the Key type and state information.
  * A set slot has three possible states: empty, occupied and removed.
@@ -35,7 +35,7 @@
 #include "BLI_memory_utils.hh"
 #include "BLI_string_ref.hh"
 
-namespace BLI {
+namespace blender {
 
 /**
  * The simplest possible set slot. It stores the slot state and the optional key instance in
@@ -410,6 +410,6 @@ template<typename Key> struct DefaultSetSlot<Key *> {
   using type = IntrusiveSetSlot<Key *, PointerKeyInfo<Key *>>;
 };
 
-}  // namespace BLI
+}  // namespace blender
 
 #endif /* __BLI_SET_SLOTS_HH__ */

source/blender/blenlib/BLI_stack.hh

@@ -20,7 +20,7 @@
 /** \file
  * \ingroup bli
  *
- * A `BLI::Stack<T>` is a dynamically growing FILO (first-in, last-out) data structure. It is
+ * A `blender::Stack<T>` is a dynamically growing FILO (first-in, last-out) data structure. It is
  * designed to be a more convenient and efficient replacement for `std::stack`.
  *
  * The improved efficiency is mainly achieved by supporting small buffer optimization. As long as
@@ -34,8 +34,8 @@
  * when it grows. This stack implementation does not have to copy all previously pushed elements
  * when it grows.
  *
- * BLI::Stack is implemented using a double linked list of chunks. Each chunk contains an array of
- * elements. The chunk size increases exponentially with every new chunk that is required. The
+ * blender::Stack is implemented using a double linked list of chunks. Each chunk contains an array
+ * of elements. The chunk size increases exponentially with every new chunk that is required. The
  * lowest chunk, i.e. the one that is used for the first few pushed elements, is embedded into the
  * stack.
  */
@@ -44,7 +44,7 @@
 #include "BLI_array_ref.hh"
 #include "BLI_memory_utils.hh"
 
-namespace BLI {
+namespace blender {
 
 /**
  * A StackChunk references a contiguous memory buffer. Multiple StackChunk instances are linked in
@@ -385,6 +385,6 @@ class Stack {
   }
 };
 
-} /* namespace BLI */
+} /* namespace blender */
 
 #endif /* __BLI_STACK_HH__ */

source/blender/blenlib/BLI_string_ref.hh

@@ -20,13 +20,13 @@
 /** \file
  * \ingroup bli
  *
- * A `BLI::StringRef` references a const char array owned by someone else. It is just a pointer and
- * a size. Since the memory is not owned, StringRef should not be used to transfer ownership of the
- * string. The data referenced by a StringRef cannot be mutated through it.
+ * A `blender::StringRef` references a const char array owned by someone else. It is just a pointer
+ * and a size. Since the memory is not owned, StringRef should not be used to transfer ownership of
+ * the string. The data referenced by a StringRef cannot be mutated through it.
  *
  * A StringRef is NOT null-terminated. This makes it much more powerful within C++, because we can
  * also cut off parts of the end without creating a copy. When interfacing with C code that expects
- * null-terminated strings, `BLI::StringRefNull` can be used. It is essentially the same as
+ * null-terminated strings, `blender::StringRefNull` can be used. It is essentially the same as
  * StringRef, but with the restriction that the string has to be null-terminated.
  *
  * Whenever possible, string parameters should be of type StringRef and the string return type
@@ -34,7 +34,7 @@
  * return it when the string exists only in the scope of the function. This convention makes
  * functions usable in the most contexts.
  *
- * BLI::StringRef vs. std::string_view:
+ * blender::StringRef vs. std::string_view:
  *   Both types are certainly very similar. The main benefit of using StringRef in Blender is that
  *   this allows us to add convenience methods at any time. Especially, when doing a lot of string
  *   manipulation, this helps to keep the code clean. Furthermore, we need StringRefNull anyway,
@@ -49,7 +49,7 @@
 #include "BLI_array_ref.hh"
 #include "BLI_utildefines.h"
 
-namespace BLI {
+namespace blender {
 
 class StringRef;
 
@@ -345,6 +345,6 @@ inline StringRef StringRefBase::substr(uint start, uint size) const
   return StringRef(m_data + start, size);
 }
 
-}  // namespace BLI
+}  // namespace blender
 
 #endif /* __BLI_STRING_REF_HH__ */

source/blender/blenlib/BLI_timeit.hh

@@ -23,7 +23,7 @@
 
 #include "BLI_sys_types.h"
 
-namespace BLI {
+namespace blender {
 namespace Timeit {
 
 using Clock = std::chrono::steady_clock;
@@ -55,8 +55,8 @@ class ScopedTimer {
 };
 
 }  // namespace Timeit
-}  // namespace BLI
+}  // namespace blender
 
-#define SCOPED_TIMER(name) BLI::Timeit::ScopedTimer scoped_timer(name)
+#define SCOPED_TIMER(name) blender::Timeit::ScopedTimer scoped_timer(name)
 
 #endif /* __BLI_TIMEIT_HH__ */

source/blender/blenlib/BLI_utility_mixins.hh

@@ -21,7 +21,7 @@
 #ifndef __BLI_UTILITY_MIXINS_HH__
 #define __BLI_UTILITY_MIXINS_HH__
 
-namespace BLI {
+namespace blender {
 
 /**
  * A type that inherits from NonCopyable cannot be copied anymore.
@@ -53,6 +53,6 @@ class NonMovable {
   NonMovable &operator=(const NonMovable &other) = default;
 };
 
-}  // namespace BLI
+}  // namespace blender
 
 #endif /* __BLI_UTILITY_MIXINS_HH__ */

source/blender/blenlib/BLI_vector.hh

@@ -20,7 +20,7 @@
 /** \file
  * \ingroup bli
  *
- * A `BLI::Vector<T>` is a dynamically growing contiguous array for values of type T. It is
+ * A `blender::Vector<T>` is a dynamically growing contiguous array for values of type T. It is
  * designed to be a more convenient and efficient replacement for `std::vector`. Note that the term
  * "vector" has nothing to do with a vector from computer graphics here.
  *
@@ -31,10 +31,10 @@
  *
  * The improved efficiency is mainly achieved by supporting small buffer optimization. As long as
  * the number of elements in the vector does not become larger than InlineBufferCapacity, no memory
- * allocation is done. As a consequence, iterators are invalidated when a BLI::Vector is moved
+ * allocation is done. As a consequence, iterators are invalidated when a blender::Vector is moved
  * (iterators of std::vector remain valid when the vector is moved).
  *
- * `BLI::Vector` should be your default choice for a vector data structure in Blender.
+ * `blender::Vector` should be your default choice for a vector data structure in Blender.
  */
 
 #include <algorithm>
@@ -55,7 +55,7 @@
 
 #include "MEM_guardedalloc.h"
 
-namespace BLI {
+namespace blender {
 
 template<
     /**
@@ -143,7 +143,7 @@ class Vector {
   {
     this->reserve(size);
     this->increase_size_by_unchecked(size);
-    BLI::uninitialized_fill_n(m_begin, size, value);
+    blender::uninitialized_fill_n(m_begin, size, value);
   }
 
   /**
@@ -164,7 +164,7 @@ class Vector {
     uint size = values.size();
     this->reserve(size);
     this->increase_size_by_unchecked(size);
-    BLI::uninitialized_copy_n(values.data(), size, m_begin);
+    blender::uninitialized_copy_n(values.data(), size, m_begin);
   }
 
   /**
@@ -456,7 +456,7 @@ class Vector {
   void append_n_times(const T &value, uint n)
   {
     this->reserve(this->size() + n);
-    BLI::uninitialized_fill_n(m_end, n, value);
+    blender::uninitialized_fill_n(m_end, n, value);
     this->increase_size_by_unchecked(n);
   }
 
@@ -511,7 +511,7 @@ class Vector {
   void extend_unchecked(const T *start, uint amount)
   {
     BLI_assert(m_begin + amount <= m_capacity_end);
-    BLI::uninitialized_copy_n(start, amount, m_end);
+    blender::uninitialized_copy_n(start, amount, m_end);
     m_end += amount;
     UPDATE_VECTOR_SIZE(this);
   }
@@ -844,6 +844,6 @@ class Vector {
 template<typename T, uint InlineBufferCapacity = 20>
 using ScopedVector = Vector<T, InlineBufferCapacity, GuardedAllocator>;
 
-} /* namespace BLI */
+} /* namespace blender */
 
 #endif /* __BLI_VECTOR_HH__ */

source/blender/blenlib/BLI_vector_set.hh

@@ -20,8 +20,8 @@
 /** \file
  * \ingroup bli
  *
- * A `BLI::VectorSet<Key>` is an ordered container for elements of type `Key`. It has the same
- * interface as `BLI::Set` with the following extensions:
+ * A `blender::VectorSet<Key>` is an ordered container for elements of type `Key`. It has the same
+ * interface as `blender::Set` with the following extensions:
  * - The insertion order of keys is maintained as long as no elements are removed.
  * - The keys are stored in a contiguous array.
  *
@@ -35,9 +35,9 @@
  *   the keys are stored in a set. With a VectorSet, one can get an ArrayRef containing all keys
  *   without additional copies.
  *
- * BLI::VectorSet is implemented using open addressing in a slot array with a power-of-two size.
- * Other than in BLI::Set, a slot does not contain the key though. Instead it only contains an
- * index into an array of keys that is stored separately.
+ * blender::VectorSet is implemented using open addressing in a slot array with a power-of-two
+ * size. Other than in blender::Set, a slot does not contain the key though. Instead it only
+ * contains an index into an array of keys that is stored separately.
  *
  * Some noteworthy information:
  * - Key must be a movable type.
@@ -66,7 +66,7 @@
 #include "BLI_probing_strategies.hh"
 #include "BLI_vector_set_slots.hh"
 
-namespace BLI {
+namespace blender {
 
 template<
     /**
@@ -752,6 +752,6 @@ class VectorSet {
   }
 };
 
-}  // namespace BLI
+}  // namespace blender
 
 #endif /* __BLI_VECTOR_SET_HH__ */

source/blender/blenlib/BLI_vector_set_slots.hh

@@ -20,7 +20,7 @@
 /** \file
  * \ingroup bli
  *
- * This file contains slot types that are supposed to be used with BLI::VectorSet.
+ * This file contains slot types that are supposed to be used with blender::VectorSet.
  *
  * Every slot type has to be able to hold an integer index and state information.
  * A vector set slot has three possible states: empty, occupied and removed.
@@ -39,7 +39,7 @@
 
 #include "BLI_sys_types.h"
 
-namespace BLI {
+namespace blender {
 
 /**
  * The simplest possible vector set slot. It stores the index and state in a signed integer. If the
@@ -166,6 +166,6 @@ template<typename Key> struct DefaultVectorSetSlot {
   using type = SimpleVectorSetSlot<Key>;
 };
 
-}  // namespace BLI
+}  // namespace blender
 
 #endif /* __BLI_VECTOR_SET_SLOTS_HH__ */

source/blender/blenlib/intern/BLI_index_range.cc

@@ -22,7 +22,7 @@
 #include "BLI_index_range.hh"
 #include "BLI_vector.hh"
 
-namespace BLI {
+namespace blender {
 
 static Vector<Array<uint, 0, RawAllocator>, 1, RawAllocator> arrays;
 static uint current_array_size = 0;
@@ -57,4 +57,4 @@ ArrayRef<uint> IndexRange::as_array_ref() const
   return ArrayRef<uint>(current_array + m_start, m_size);
 }
 
-}  // namespace BLI
+}  // namespace blender

source/blender/blenlib/intern/dot_export.cc

@@ -18,7 +18,7 @@
 
 #include "BLI_dot_export.hh"
 
-namespace BLI {
+namespace blender {
 namespace DotExport {
 
 /* Graph Building
@@ -302,4 +302,4 @@ NodeWithSocketsRef::NodeWithSocketsRef(Node &node,
 }
 
 }  // namespace DotExport
-}  // namespace BLI
+}  // namespace blender

source/blender/blenlib/intern/timeit.cc

@@ -16,7 +16,7 @@
 
 #include "BLI_timeit.hh"
 
-namespace BLI {
+namespace blender {
 namespace Timeit {
 
 void print_duration(Nanoseconds duration)
@@ -33,4 +33,4 @@ void print_duration(Nanoseconds duration)
 }
 
 }  // namespace Timeit
-}  // namespace BLI
+}  // namespace blender

source/blender/depsgraph/intern/builder/deg_builder_rna.cc

@@ -365,7 +365,7 @@ RNANodeIdentifier RNANodeQuery::construct_node_identifier(const PointerRNA *ptr,
 RNANodeQueryIDData *RNANodeQuery::ensure_id_data(const ID *id)
 {
   unique_ptr<RNANodeQueryIDData> &id_data = id_data_map_.lookup_or_add(
-      id, [&]() { return BLI::make_unique<RNANodeQueryIDData>(id); });
+      id, [&]() { return blender::make_unique<RNANodeQueryIDData>(id); });
   return id_data.get();
 }
 

source/blender/depsgraph/intern/depsgraph_type.h

@@ -53,13 +53,13 @@ struct CustomData_MeshMasks;
 namespace DEG {
 
 /* Commonly used types. */
-using BLI::ArrayRef;
-using BLI::Map;
-using BLI::Set;
-using BLI::StringRef;
-using BLI::StringRefNull;
-using BLI::Vector;
-using BLI::VectorSet;
+using blender::ArrayRef;
+using blender::Map;
+using blender::Set;
+using blender::StringRef;
+using blender::StringRefNull;
+using blender::Vector;
+using blender::VectorSet;
 using std::deque;
 using std::map;
 using std::pair;

source/blender/depsgraph/intern/node/deg_node_component.h

@@ -206,7 +206,7 @@ void deg_register_component_depsnodes();
 
 }  // namespace DEG
 
-namespace BLI {
+namespace blender {
 
 template<> struct DefaultHash<DEG::ComponentNode::OperationIDKey> {
   uint32_t operator()(const DEG::ComponentNode::OperationIDKey &key) const
@@ -219,4 +219,4 @@ template<> struct DefaultHash<DEG::ComponentNode::OperationIDKey> {
   }
 };
 
-}  // namespace BLI
+}  // namespace blender

source/blender/freestyle/intern/blender_interface/BlenderStrokeRenderer.h

@@ -56,7 +56,7 @@ class BlenderStrokeRenderer : public StrokeRenderer {
     {
     }
     vector<StrokeRep *> strokes;
-    BLI::Map<Material *, int> materials;
+    blender::Map<Material *, int> materials;
     int totvert;
     int totedge;
     int totpoly;

source/blender/functions/FN_cpp_type.hh

@@ -72,9 +72,9 @@
 
 namespace FN {
 
-using BLI::IndexMask;
-using BLI::StringRef;
-using BLI::StringRefNull;
+using blender::IndexMask;
+using blender::StringRef;
+using blender::StringRefNull;
 
 class CPPType {
  public:
@@ -538,7 +538,7 @@ template<typename T> void construct_default_cb(void *ptr)
 }
 template<typename T> void construct_default_n_cb(void *ptr, uint n)
 {
-  BLI::default_construct_n((T *)ptr, n);
+  blender::default_construct_n((T *)ptr, n);
 }
 template<typename T> void construct_default_indices_cb(void *ptr, IndexMask index_mask)
 {
@@ -551,7 +551,7 @@ template<typename T> void destruct_cb(void *ptr)
 }
 template<typename T> void destruct_n_cb(void *ptr, uint n)
 {
-  BLI::destruct_n((T *)ptr, n);
+  blender::destruct_n((T *)ptr, n);
 }
 template<typename T> void destruct_indices_cb(void *ptr, IndexMask index_mask)
 {
@@ -583,11 +583,11 @@ void copy_to_initialized_indices_cb(const void *src, void *dst, IndexMask index_
 
 template<typename T> void copy_to_uninitialized_cb(const void *src, void *dst)
 {
-  BLI::uninitialized_copy_n((T *)src, 1, (T *)dst);
+  blender::uninitialized_copy_n((T *)src, 1, (T *)dst);
 }
 template<typename T> void copy_to_uninitialized_n_cb(const void *src, void *dst, uint n)
 {
-  BLI::uninitialized_copy_n((T *)src, n, (T *)dst);
+  blender::uninitialized_copy_n((T *)src, n, (T *)dst);
 }
 template<typename T>
 void copy_to_uninitialized_indices_cb(const void *src, void *dst, IndexMask index_mask)
@@ -608,7 +608,7 @@ template<typename T> void relocate_to_initialized_cb(void *src, void *dst)
 }
 template<typename T> void relocate_to_initialized_n_cb(void *src, void *dst, uint n)
 {
-  BLI::initialized_relocate_n((T *)src, n, (T *)dst);
+  blender::initialized_relocate_n((T *)src, n, (T *)dst);
 }
 template<typename T>
 void relocate_to_initialized_indices_cb(void *src, void *dst, IndexMask index_mask)
@@ -632,7 +632,7 @@ template<typename T> void relocate_to_uninitialized_cb(void *src, void *dst)
 }
 template<typename T> void relocate_to_uninitialized_n_cb(void *src, void *dst, uint n)
 {
-  BLI::uninitialized_relocate_n((T *)src, n, (T *)dst);
+  blender::uninitialized_relocate_n((T *)src, n, (T *)dst);
 }
 template<typename T>
 void relocate_to_uninitialized_indices_cb(void *src, void *dst, IndexMask index_mask)

source/blender/functions/intern/cpp_types.cc

@@ -26,15 +26,15 @@ namespace FN {
 MAKE_CPP_TYPE(bool, bool)
 
 MAKE_CPP_TYPE(float, float)
-MAKE_CPP_TYPE(float3, BLI::float3)
-MAKE_CPP_TYPE(float4x4, BLI::float4x4)
+MAKE_CPP_TYPE(float3, blender::float3)
+MAKE_CPP_TYPE(float4x4, blender::float4x4)
 
 MAKE_CPP_TYPE(int32, int32_t)
 MAKE_CPP_TYPE(uint32, uint32_t)
 MAKE_CPP_TYPE(uint8, uint8_t)
 
-MAKE_CPP_TYPE(Color4f, BLI::Color4f)
-MAKE_CPP_TYPE(Color4b, BLI::Color4b)
+MAKE_CPP_TYPE(Color4f, blender::Color4f)
+MAKE_CPP_TYPE(Color4b, blender::Color4b)
 
 MAKE_CPP_TYPE(string, std::string)
 

source/blender/modifiers/intern/MOD_mask.cc

@@ -66,12 +66,12 @@
 #include "BLI_listbase_wrapper.hh"
 #include "BLI_vector.hh"
 
-using BLI::Array;
-using BLI::ArrayRef;
-using BLI::IndexRange;
-using BLI::ListBaseWrapper;
-using BLI::MutableArrayRef;
-using BLI::Vector;
+using blender::Array;
+using blender::ArrayRef;
+using blender::IndexRange;
+using blender::ListBaseWrapper;
+using blender::MutableArrayRef;
+using blender::Vector;
 
 static void requiredDataMask(Object *UNUSED(ob),
                              ModifierData *UNUSED(md),

source/blender/modifiers/intern/MOD_simulation.cc

@@ -64,7 +64,7 @@
 #include "MOD_modifiertypes.h"
 #include "MOD_ui_common.h"
 
-using BLI::float3;
+using blender::float3;
 
 static void updateDepsgraph(ModifierData *md, const ModifierUpdateDepsgraphContext *ctx)
 {

tests/gtests/blenlib/BLI_array_ref_test.cc

@@ -3,11 +3,11 @@
 #include "BLI_vector.hh"
 #include "testing/testing.h"
 
-using namespace BLI;
+using namespace blender;
 
-using IntVector = BLI::Vector<int>;
-using IntArrayRef = BLI::ArrayRef<int>;
-using MutableIntArrayRef = BLI::MutableArrayRef<int>;
+using IntVector = blender::Vector<int>;
+using IntArrayRef = blender::ArrayRef<int>;
+using MutableIntArrayRef = blender::MutableArrayRef<int>;
 
 TEST(array_ref, FromSmallVector)
 {

tests/gtests/blenlib/BLI_array_test.cc

@@ -2,7 +2,7 @@
 #include "BLI_strict_flags.h"
 #include "testing/testing.h"
 
-using namespace BLI;
+using namespace blender;
 
 TEST(array, DefaultConstructor)
 {

tests/gtests/blenlib/BLI_index_mask_test.cc

@@ -1,7 +1,7 @@
 #include "BLI_index_mask.hh"
 #include "testing/testing.h"
 
-using namespace BLI;
+using namespace blender;
 
 TEST(index_mask, DefaultConstructor)
 {

tests/gtests/blenlib/BLI_index_range_test.cc

@@ -3,7 +3,7 @@
 #include "BLI_vector.hh"
 #include "testing/testing.h"
 
-using namespace BLI;
+using namespace blender;
 
 TEST(index_range, DefaultConstructor)
 {

tests/gtests/blenlib/BLI_linear_allocator_test.cc

@@ -2,7 +2,7 @@
 #include "BLI_strict_flags.h"
 #include "testing/testing.h"
 
-using namespace BLI;
+using namespace blender;
 
 static bool is_aligned(void *ptr, uint alignment)
 {
@@ -30,7 +30,7 @@ TEST(linear_allocator, AllocationAlignment)
 TEST(linear_allocator, PackedAllocation)
 {
   LinearAllocator<> allocator;
-  BLI::AlignedBuffer<256, 32> buffer;
+  blender::AlignedBuffer<256, 32> buffer;
   allocator.provide_buffer(buffer);
 
   uintptr_t ptr1 = (uintptr_t)allocator.allocate(10, 4); /*  0 - 10 */
@@ -52,7 +52,7 @@ TEST(linear_allocator, PackedAllocation)
 TEST(linear_allocator, CopyString)
 {
   LinearAllocator<> allocator;
-  BLI::AlignedBuffer<256, 1> buffer;
+  blender::AlignedBuffer<256, 1> buffer;
   allocator.provide_buffer(buffer);
 
   StringRefNull ref1 = allocator.copy_string("Hello");

tests/gtests/blenlib/BLI_map_test.cc

@@ -6,7 +6,7 @@
 #include "BLI_vector.hh"
 #include "testing/testing.h"
 
-using namespace BLI;
+using namespace blender;
 
 TEST(map, DefaultConstructor)
 {
@@ -103,7 +103,7 @@ TEST(map, ValueIterator)
   map.add(1, 2.0f);
   map.add(7, -2.0f);
 
-  BLI::Set<float> values;
+  blender::Set<float> values;
 
   uint iterations = 0;
   for (float value : map.values()) {
@@ -124,7 +124,7 @@ TEST(map, KeyIterator)
   map.add(2, 4.0f);
   map.add(1, 3.0f);
 
-  BLI::Set<int> keys;
+  blender::Set<int> keys;
 
   uint iterations = 0;
   for (int key : map.keys()) {
@@ -145,8 +145,8 @@ TEST(map, ItemIterator)
   map.add(2, 9.0f);
   map.add(1, 0.0f);
 
-  BLI::Set<int> keys;
-  BLI::Set<float> values;
+  blender::Set<int> keys;
+  blender::Set<float> values;
 
   uint iterations = 0;
   for (auto item : map.items()) {
@@ -423,63 +423,63 @@ BLI_NOINLINE void benchmark_random_ints(StringRef name, uint amount, uint factor
 TEST(map, Benchmark)
 {
   for (uint i = 0; i < 3; i++) {
-    benchmark_random_ints<BLI::Map<int, int>>("BLI::Map          ", 1000000, 1);
-    benchmark_random_ints<BLI::StdUnorderedMapWrapper<int, int>>("std::unordered_map", 1000000, 1);
+    benchmark_random_ints<blender::Map<int, int>>("blender::Map          ", 1000000, 1);
+    benchmark_random_ints<blender::StdUnorderedMapWrapper<int, int>>("std::unordered_map", 1000000, 1);
   }
   std::cout << "\n";
   for (uint i = 0; i < 3; i++) {
     uint32_t factor = (3 << 10);
-    benchmark_random_ints<BLI::Map<int, int>>("BLI::Map          ", 1000000, factor);
-    benchmark_random_ints<BLI::StdUnorderedMapWrapper<int, int>>(
+    benchmark_random_ints<blender::Map<int, int>>("blender::Map          ", 1000000, factor);
+    benchmark_random_ints<blender::StdUnorderedMapWrapper<int, int>>(
         "std::unordered_map", 1000000, factor);
   }
 }
 
 /**
- * Timer 'BLI::Map           Add' took 61.7616 ms
- * Timer 'BLI::Map           Contains' took 18.4989 ms
- * Timer 'BLI::Map           Remove' took 20.5864 ms
+ * Timer 'blender::Map           Add' took 61.7616 ms
+ * Timer 'blender::Map           Contains' took 18.4989 ms
+ * Timer 'blender::Map           Remove' took 20.5864 ms
  * Count: 1999755
  * Timer 'std::unordered_map Add' took 188.674 ms
  * Timer 'std::unordered_map Contains' took 44.3741 ms
  * Timer 'std::unordered_map Remove' took 169.52 ms
  * Count: 1999755
- * Timer 'BLI::Map           Add' took 37.9196 ms
- * Timer 'BLI::Map           Contains' took 16.7361 ms
- * Timer 'BLI::Map           Remove' took 20.9568 ms
+ * Timer 'blender::Map           Add' took 37.9196 ms
+ * Timer 'blender::Map           Contains' took 16.7361 ms
+ * Timer 'blender::Map           Remove' took 20.9568 ms
  * Count: 1999755
  * Timer 'std::unordered_map Add' took 166.09 ms
  * Timer 'std::unordered_map Contains' took 40.6133 ms
  * Timer 'std::unordered_map Remove' took 142.85 ms
  * Count: 1999755
- * Timer 'BLI::Map           Add' took 37.3053 ms
- * Timer 'BLI::Map           Contains' took 16.6731 ms
- * Timer 'BLI::Map           Remove' took 18.8304 ms
+ * Timer 'blender::Map           Add' took 37.3053 ms
+ * Timer 'blender::Map           Contains' took 16.6731 ms
+ * Timer 'blender::Map           Remove' took 18.8304 ms
  * Count: 1999755
  * Timer 'std::unordered_map Add' took 170.964 ms
  * Timer 'std::unordered_map Contains' took 38.1824 ms
  * Timer 'std::unordered_map Remove' took 140.263 ms
  * Count: 1999755
  *
- * Timer 'BLI::Map           Add' took 50.1131 ms
- * Timer 'BLI::Map           Contains' took 25.0491 ms
- * Timer 'BLI::Map           Remove' took 32.4225 ms
+ * Timer 'blender::Map           Add' took 50.1131 ms
+ * Timer 'blender::Map           Contains' took 25.0491 ms
+ * Timer 'blender::Map           Remove' took 32.4225 ms
  * Count: 1889920
  * Timer 'std::unordered_map Add' took 150.129 ms
  * Timer 'std::unordered_map Contains' took 34.6999 ms
  * Timer 'std::unordered_map Remove' took 120.907 ms
  * Count: 1889920
- * Timer 'BLI::Map           Add' took 50.4438 ms
- * Timer 'BLI::Map           Contains' took 25.2677 ms
- * Timer 'BLI::Map           Remove' took 32.3047 ms
+ * Timer 'blender::Map           Add' took 50.4438 ms
+ * Timer 'blender::Map           Contains' took 25.2677 ms
+ * Timer 'blender::Map           Remove' took 32.3047 ms
  * Count: 1889920
  * Timer 'std::unordered_map Add' took 144.015 ms
  * Timer 'std::unordered_map Contains' took 36.3387 ms
  * Timer 'std::unordered_map Remove' took 119.109 ms
  * Count: 1889920
- * Timer 'BLI::Map           Add' took 48.6995 ms
- * Timer 'BLI::Map           Contains' took 25.1846 ms
- * Timer 'BLI::Map           Remove' took 33.0283 ms
+ * Timer 'blender::Map           Add' took 48.6995 ms
+ * Timer 'blender::Map           Contains' took 25.1846 ms
+ * Timer 'blender::Map           Remove' took 33.0283 ms
  * Count: 1889920
  * Timer 'std::unordered_map Add' took 143.494 ms
  * Timer 'std::unordered_map Contains' took 34.8905 ms

tests/gtests/blenlib/BLI_optional_test.cc

@@ -3,7 +3,7 @@
 #include "testing/testing.h"
 #include <string>
 
-using namespace BLI;
+using namespace blender;
 
 TEST(optional, DefaultConstructor)
 {

tests/gtests/blenlib/BLI_set_test.cc

@@ -9,7 +9,7 @@
 #include "BLI_vector.hh"
 #include "testing/testing.h"
 
-using namespace BLI;
+using namespace blender;
 
 TEST(set, DefaultConstructor)
 {
@@ -191,7 +191,7 @@ TEST(set, AddMultipleNew)
 TEST(set, Iterator)
 {
   Set<int> set = {1, 3, 2, 5, 4};
-  BLI::Vector<int> vec;
+  blender::Vector<int> vec;
   for (int value : set) {
     vec.append(value);
   }
@@ -290,7 +290,7 @@ bool operator==(const Type2 &a, const Type1 &b)
   return a.value == b.value;
 }
 
-template<> struct BLI::DefaultHash<Type1> {
+template<> struct blender::DefaultHash<Type1> {
   uint32_t operator()(const Type1 &value) const
   {
     return value.value;
@@ -445,64 +445,64 @@ BLI_NOINLINE void benchmark_random_ints(StringRef name, uint amount, uint factor
 TEST(set, Benchmark)
 {
   for (uint i = 0; i < 3; i++) {
-    benchmark_random_ints<BLI::Set<int>>("BLI::Set          ", 100000, 1);
-    benchmark_random_ints<BLI::StdUnorderedSetWrapper<int>>("std::unordered_set", 100000, 1);
+    benchmark_random_ints<blender::Set<int>>("blender::Set      ", 100000, 1);
+    benchmark_random_ints<blender::StdUnorderedSetWrapper<int>>("std::unordered_set", 100000, 1);
   }
   std::cout << "\n";
   for (uint i = 0; i < 3; i++) {
     uint32_t factor = (3 << 10);
-    benchmark_random_ints<BLI::Set<int>>("BLI::Set          ", 100000, factor);
-    benchmark_random_ints<BLI::StdUnorderedSetWrapper<int>>("std::unordered_set", 100000, factor);
+    benchmark_random_ints<blender::Set<int>>("blender::Set      ", 100000, factor);
+    benchmark_random_ints<blender::StdUnorderedSetWrapper<int>>("std::unordered_set", 100000, factor);
   }
 }
 
 /**
  * Output of the rudimentary benchmark above on my hardware.
  *
- * Timer 'BLI::Set           Add' took 5.5573 ms
- * Timer 'BLI::Set           Contains' took 0.807384 ms
- * Timer 'BLI::Set           Remove' took 0.953436 ms
+ * Timer 'blender::Set       Add' took 5.5573 ms
+ * Timer 'blender::Set       Contains' took 0.807384 ms
+ * Timer 'blender::Set       Remove' took 0.953436 ms
  * Count: 199998
  * Timer 'std::unordered_set Add' took 12.551 ms
  * Timer 'std::unordered_set Contains' took 2.3323 ms
  * Timer 'std::unordered_set Remove' took 5.07082 ms
  * Count: 199998
- * Timer 'BLI::Set           Add' took 2.62526 ms
- * Timer 'BLI::Set           Contains' took 0.407499 ms
- * Timer 'BLI::Set           Remove' took 0.472981 ms
+ * Timer 'blender::Set       Add' took 2.62526 ms
+ * Timer 'blender::Set       Contains' took 0.407499 ms
+ * Timer 'blender::Set       Remove' took 0.472981 ms
  * Count: 199998
  * Timer 'std::unordered_set Add' took 6.26945 ms
  * Timer 'std::unordered_set Contains' took 1.17236 ms
  * Timer 'std::unordered_set Remove' took 3.77402 ms
  * Count: 199998
- * Timer 'BLI::Set           Add' took 2.59152 ms
- * Timer 'BLI::Set           Contains' took 0.415254 ms
- * Timer 'BLI::Set           Remove' took 0.477559 ms
+ * Timer 'blender::Set       Add' took 2.59152 ms
+ * Timer 'blender::Set       Contains' took 0.415254 ms
+ * Timer 'blender::Set       Remove' took 0.477559 ms
  * Count: 199998
  * Timer 'std::unordered_set Add' took 6.28129 ms
  * Timer 'std::unordered_set Contains' took 1.17562 ms
  * Timer 'std::unordered_set Remove' took 3.77811 ms
  * Count: 199998
  *
- * Timer 'BLI::Set           Add' took 3.16514 ms
- * Timer 'BLI::Set           Contains' took 0.732895 ms
- * Timer 'BLI::Set           Remove' took 1.08171 ms
+ * Timer 'blender::Set       Add' took 3.16514 ms
+ * Timer 'blender::Set       Contains' took 0.732895 ms
+ * Timer 'blender::Set       Remove' took 1.08171 ms
  * Count: 198790
  * Timer 'std::unordered_set Add' took 6.57377 ms
  * Timer 'std::unordered_set Contains' took 1.17008 ms
  * Timer 'std::unordered_set Remove' took 3.7946 ms
  * Count: 198790
- * Timer 'BLI::Set           Add' took 3.11439 ms
- * Timer 'BLI::Set           Contains' took 0.740159 ms
- * Timer 'BLI::Set           Remove' took 1.06749 ms
+ * Timer 'blender::Set       Add' took 3.11439 ms
+ * Timer 'blender::Set       Contains' took 0.740159 ms
+ * Timer 'blender::Set       Remove' took 1.06749 ms
  * Count: 198790
  * Timer 'std::unordered_set Add' took 6.35597 ms
  * Timer 'std::unordered_set Contains' took 1.17713 ms
  * Timer 'std::unordered_set Remove' took 3.77826 ms
  * Count: 198790
- * Timer 'BLI::Set           Add' took 3.09876 ms
- * Timer 'BLI::Set           Contains' took 0.742072 ms
- * Timer 'BLI::Set           Remove' took 1.06622 ms
+ * Timer 'blender::Set       Add' took 3.09876 ms
+ * Timer 'blender::Set       Contains' took 0.742072 ms
+ * Timer 'blender::Set       Remove' took 1.06622 ms
  * Count: 198790
  * Timer 'std::unordered_set Add' took 6.4469 ms
  * Timer 'std::unordered_set Contains' took 1.16515 ms

tests/gtests/blenlib/BLI_stack_cxx_test.cc

@@ -3,7 +3,7 @@
 #include "BLI_vector.hh"
 #include "testing/testing.h"
 
-using namespace BLI;
+using namespace blender;
 
 TEST(stack, DefaultConstructor)
 {

tests/gtests/blenlib/BLI_string_ref_test.cc

@@ -3,9 +3,9 @@
 #include "BLI_vector.hh"
 #include "testing/testing.h"
 
-using BLI::StringRef;
-using BLI::StringRefNull;
-using BLI::Vector;
+using blender::StringRef;
+using blender::StringRefNull;
+using blender::Vector;
 
 TEST(string_ref_null, DefaultConstructor)
 {

tests/gtests/blenlib/BLI_vector_set_test.cc

@@ -2,7 +2,7 @@
 #include "BLI_vector_set.hh"
 #include "testing/testing.h"
 
-using BLI::VectorSet;
+using blender::VectorSet;
 
 TEST(vector_set, DefaultConstructor)
 {

tests/gtests/blenlib/BLI_vector_test.cc

@@ -3,7 +3,7 @@
 #include "testing/testing.h"
 #include <forward_list>
 
-using namespace BLI;
+using namespace blender;
 
 TEST(vector, DefaultConstructor)
 {