Changes in insert_allocator_requirements.pass.cpp

31cbe0f2 - [libc++] Remove the c++98 Lit feature from the test suite

Mon, 01 Jun 2020 14:38:23 +0000

[libc++] Remove the c++98 Lit feature from the test suiteC++98 and C++03 are effectively aliases as far as Clang is concerned.As such, allowing both std=c++98 and std=c++03 as Lit parameters isjust slightly confusing, but provides no value. It's similar to allowingboth std=c++17 and std=c++1z, which we don't do.This was discovered because we had an internal bot that ran the testsuite under both c++98 AND c++03 -- one of which is redundant.Differential Revision: https://reviews.llvm.org/D80926 List of files: /llvm-project-15.0.7/libcxx/test/std/containers/associative/multimap/multimap.modifiers/insert_allocator_requirements.pass.cpp

7fc6a556 - Add include for 'test_macros.h' to all the tests that were missing them. Thanks to Zoe for the (big, but simple) patch. NFC intended.

Fri, 31 May 2019 18:35:30 +0000

Add include for 'test_macros.h' to all the tests that were missing them. Thanks to Zoe for the (big, but simple) patch. NFC intended.llvm-svn: 362252 List of files: /llvm-project-15.0.7/libcxx/test/std/containers/associative/multimap/multimap.modifiers/insert_allocator_requirements.pass.cpp

2df59c50 - Support tests in freestanding

Mon, 04 Feb 2019 20:31:13 +0000

Support tests in freestandingSummary:Freestanding is *weird*. The standard allows it to differ in a bunch of oddmanners from regular C++, and the committee would like to improve thatsituation. I'd like to make libc++ behave better with what freestanding shouldbe, so that it can be a tool we use in improving the standard. To do that weneed to try stuff out, both with "freestanding the language mode" and"freestanding the library subset".Let's start with the super basic: run the libc++ tests in freestanding, usingclang as the compiler, and see what works. The easiest hack to do this:In utils/libcxx/test/config.py add: self.cxx.compile_flags += ['-ffreestanding']Run the tests and they all fail.Why? Because in freestanding `main` isn't special. This "not special" propertyhas two effects: main doesn't get mangled, and main isn't allowed to omit its`return` statement. The first means main gets mangled and the linker can'tcreate a valid executable for us to test. The second means we spew out warnings(ew) and the compiler doesn't insert the `return` we omitted, and main justfalls of the end and does whatever undefined behavior (if you're luck, ud2leading to non-zero return code).Let's start my work with the basics. This patch changes all libc++ tests todeclare `main` as `int main(int, char**` so it mangles consistently (enabling usto declare another `extern "C"` main for freestanding which calls the mangledone), and adds `return 0;` to all places where it was missing. This touches 6124files, and I apologize.The former was done with The Magic Of Sed.The later was done with a (not quite correct but decent) clang tool: https://gist.github.com/jfbastien/793819ff360baa845483dde81170feedThis works for most tests, though I did have to adjust a few places when e.g.the test runs with `-x c`, macros are used for main (such as for the filesystemtests), etc.Once this is in we can create a freestanding bot which will prevent furtherregressions. After that, we can start the real work of supporting C++freestanding fairly well in libc++.Reviewers: ldionne, mclow.lists, EricWFSubscribers: christof, jkorous, dexonsmith, arphaman, miyuki, libcxx-commitsDifferential Revision: https://reviews.llvm.org/D57624llvm-svn: 353086 List of files: /llvm-project-15.0.7/libcxx/test/std/containers/associative/multimap/multimap.modifiers/insert_allocator_requirements.pass.cpp

57b08b09 - Update more file headers across all of the LLVM projects in the monorepo

Sat, 19 Jan 2019 10:56:40 +0000

Update more file headers across all of the LLVM projects in the monorepoto reflect the new license. These used slightly different spellings thatdefeated my regular expressions.We understand that people may be surprised that we're moving the headerentirely to discuss the new license. We checked this carefully with theFoundation's lawyer and we believe this is the correct approach.Essentially, all code in the project is now made available by the LLVMproject under our new license, so you will see that the license headersinclude that license only. Some of our contributors have contributedcode under our old license, and accordingly, we have retained a copy ofour old license notice in the top-level files in each project andrepository.llvm-svn: 351648 List of files: /llvm-project-15.0.7/libcxx/test/std/containers/associative/multimap/multimap.modifiers/insert_allocator_requirements.pass.cpp

7a9f500f - Fix LWG issue 2345 - Add insert(value_type&&)

Mon, 18 Apr 2016 01:40:45 +0000

Fix LWG issue 2345 - Add insert(value_type&&)llvm-svn: 266585 List of files: /llvm-project-15.0.7/libcxx/test/std/containers/associative/multimap/multimap.modifiers/insert_allocator_requirements.pass.cpp

fa1f613f - Extract key to avoid preemptive mallocs in insert/emplace in associative containers

Fri, 15 Apr 2016 23:27:27 +0000

Extract key to avoid preemptive mallocs in insert/emplace in associative containersSummary: This patch applies Duncan's work on __hash_table to __tree.Reviewers: mclow.lists, dexonsmithSubscribers: dexonsmith, cfe-commitsDifferential Revision: http://reviews.llvm.org/D18637llvm-svn: 266491 List of files: /llvm-project-15.0.7/libcxx/test/std/containers/associative/multimap/multimap.modifiers/insert_allocator_requirements.pass.cpp

5e3ea4dd - Teach tree how to handle map's value_type

Thu, 31 Mar 2016 02:15:15 +0000

Teach __tree how to handle map's __value_typeThis patch is fairly large and contains a number of changes. The changes all work towardsallowing __tree to properly handle __value_type esspecially when inserting into the __tree.I chose not to break this change into smaller patches because it wouldn't be possible towrite meaningful standard-compliant tests for each patch.It is very similar to r260513 "[libcxx] Teach __hash_table how to handle unordered_map's __hash_value_type".Changes in * Remove __value_type's constructors because it should never be constructed directly. * Make map::emplace and multimap::emplace forward to __tree and remove the old definitions * Remove "__construct_node" map and multimap member functions. Almost all of the construction is done within __tree. * Fix map's move constructor to access "__value_type.__nc" directly and pass this object to __tree::insert.Changes in <__tree> * Add traits to detect, handle, and unwrap, map's "__value_type". * Convert methods taking "value_type" to take "__container_value_type" instead. Previously these methods caused unwanted implicit conversions from "std::pair" to "__value_type". * Delete __tree_node and __tree_node_base's constructors and assignment operators. The node types should never be constructed because the "__value_" member of __tree_node must be constructed directly by the allocator. * Make the __tree_node_destructor class and "__construct_node" methods unwrap "__node_value_type" into "__container_value_type" before invoking the allocator. The user's allocator can only be used to construct and destroy the container's value_type. Passing it map's "__value_type" was incorrect. * Cleanup the "__insert" and "__emplace" methods. Have __insert forward to an __emplace function wherever possible to reduce code duplication. __insert_unique(value_type const&) and __insert_unique(value_type&&) forward to __emplace_unique_key_args. These functions will not allocate a new node if the value is already in the tree. * Change the __find* functions to take the "key_type" directly instead of passing in "value_type" and unwrapping the key later. This change allows the find functions to be used without having to construct a "value_type" first. This allows for a number of optimizations. * Teach __move_assign and __assign_multi methods to unwrap map's __value_type.llvm-svn: 264986 List of files: /llvm-project-15.0.7/libcxx/test/std/containers/associative/multimap/multimap.modifiers/insert_allocator_requirements.pass.cpp