summaryrefslogtreecommitdiffstats
path: root/libcxx/docs
Commit message (Collapse)AuthorAgeFilesLines
* Bump the trunk version to 9.0.0svnHans Wennborg2019-01-162-26/+7
| | | | llvm-svn: 351320
* Implement feature test macros using a script.Eric Fiselier2019-01-163-0/+251
| | | | | | | | | | | | | | | | | | | | Summary: This patch implements all the feature test macros libc++ currently supports, as specified by the standard or cppreference prior to C++2a. The tests and `<version>` header are generated using a script. The script contains a table of each feature test macro, the headers it should be accessible from, and its values of each dialect of C++. When a new feature test macro is added or needed, the table should be updated and the script re-run. Reviewers: mclow.lists, jfb, serge-sans-paille Reviewed By: mclow.lists Subscribers: arphaman, jfb, ldionne, libcxx-commits Differential Revision: https://reviews.llvm.org/D56750 llvm-svn: 351286
* [libcxx] Support building hermetic static libraryPetr Hosek2019-01-061-0/+9
| | | | | | | | | | | | This is useful when static libc++ library is being linked into shared libraries that may be used in combination with libraries. We want to avoid we exporting libc++ symbols in those cases where this option is useful. This is provided as a CMake option and can be enabled by libc++ vendors as needed. Differential Revision: https://reviews.llvm.org/D55404 llvm-svn: 350489
* [libcxx] Make sure use_system_cxx_lib does not override cxx_runtime_root for ↵Louis Dionne2018-12-141-2/+1
| | | | | | | | | | | | DYLD_LIBRARY_PATH Otherwise, even specifying a runtime root different from the library we're linking against won't work -- the library we're linking against is always used. This is undesirable if we try testing something like linking against a recent libc++.dylib but running the tests against an older version (the back-deployment use case). llvm-svn: 349171
* [libcxx] Remove the no_default_flags LIT configurationLouis Dionne2018-12-111-8/+0
| | | | | | | | | This is part of an ongoing cleanup of the LIT test suite, where I'm trying to reduce the number of configuration options. In this case, the original intent seemed to be running the test suite with libstdc++, but this is now supported by specifying cxx_stdlib_under_test=libstdc++. llvm-svn: 348868
* [libcxx] Remove the availability_markup LIT featureLouis Dionne2018-12-071-21/+8
| | | | | | | It is now equivalent to the 'availability' LIT feature, so there's no reason to keep both. llvm-svn: 348653
* [libc++] Improve diagnostics for non-const comparators and hashers in ↵Louis Dionne2018-12-061-2/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | associative containers Summary: When providing a non-const-callable comparator in a map or set, the warning diagnostic does not include the point of instantiation of the container that triggered the warning, which makes it difficult to track down the problem. This commit improves the diagnostic by placing it directly in the body of the associative container. The same change is applied to unordered associative containers, which had a similar problem. Finally, this commit cleans up the forward declarations of several map and unordered_map helpers, which are not needed anymore. <rdar://problem/41370747> Reviewers: EricWF, mclow.lists Subscribers: christof, dexonsmith, llvm-commits Differential Revision: https://reviews.llvm.org/D48955 llvm-svn: 348529
* [libcxx] Always enable availability in the lit test suite.Louis Dionne2018-12-041-4/+2
| | | | | | | | | | | | | | | | | | | | | | Summary: Running the tests without availability enabled doesn't really make sense: availability annotations allow catching errors at compile-time instead of link-time. Running the tests without availability enabled allows confirming that a test breaks at link-time under some configuration, but it is more useful to instead check that it should fail at compile-time. Always enabling availability in the lit test suite will greatly simplify XFAILs and troubleshooting of failing tests, which is currently a giant pain because we have these two levels of possible failure: link-time and compile-time. Reviewers: EricWF, mclow.lists Subscribers: christof, jkorous, dexonsmith, libcxx-commits Differential Revision: https://reviews.llvm.org/D55079 llvm-svn: 348296
* [libcxx] Remove bad_array_lengthLouis Dionne2018-11-291-0/+8
| | | | | | | | | | | | | | | | Summary: std::bad_array_length was added by n3467, but this never made it into C++. This commit removes the definition of std::bad_array_length from the headers AND from the shared library. See the comments in the ABI changelog for details about the ABI implications of this change. Reviewers: mclow.lists, dexonsmith, howard.hinnant, EricWF Subscribers: christof, jkorous, libcxx-commits Differential Revision: https://reviews.llvm.org/D54804 llvm-svn: 347903
* [libcxx] Remove dynarrayLouis Dionne2018-11-281-0/+4
| | | | | | | | | | | | | | Summary: std::dynarray had been proposed for C++14, but it was pulled out from C++14 and there are no plans to standardize it anymore. Reviewers: mclow.lists, EricWF Subscribers: mgorny, christof, jkorous, dexonsmith, arphaman, libcxx-commits Differential Revision: https://reviews.llvm.org/D54801 llvm-svn: 347783
* [NFC] Fix formatting in availability documentationLouis Dionne2018-11-201-12/+12
| | | | llvm-svn: 347362
* [libcxx] Mention restriction on inline namespaces in LIBCXX_ABI_NAMESPACE docsLouis Dionne2018-11-161-1/+3
| | | | | | | | | | I also kept the original "vague" documentation that saying that users are responsible for not breaking us. This doesn't mean anything because there's no way they can actually enforce that unless we restrict ourselves to a specific naming scheme, but I left the documentation because it acts as a good warning and gives us more leeway. llvm-svn: 347052
* Rename cxx-benchmark-unittests target and convert to LIT.Eric Fiselier2018-11-141-0/+9
| | | | | | | | | | | | | | This patch renames the cxx-benchmark-unittests to check-cxx-benchmarks and converts the target to use LIT in order to make the tests run faster and provide better output. In particular this runs each benchmark in a suite one by one, allowing more parallelism while ensuring output isn't garbage with multiple threads. Additionally, it adds the CMake flag '-DLIBCXX_BENCHMARK_TEST_ARGS=<list>' to specify what options are passed when running the benchmarks. llvm-svn: 346888
* Make libc++'s versioning namespace customizableEric Fiselier2018-10-301-0/+12
| | | | | | | | | | | | | | | | | Summary: This patch makes the versioning namespace libc++ uses customizable by the user using `-DLIBCXX_ABI_NAMESPACE=__foo`. This allows users to build custom versions of libc++ which can be linked into binaries with other libc++ versions without causing symbol conflicts or ODR issues. Reviewers: mclow.lists, ldionne Reviewed By: ldionne Subscribers: kristina, smeenai, mgorny, phosek, libcxx-commits Differential Revision: https://reviews.llvm.org/D53879 llvm-svn: 345657
* [libc++] Use exclude_from_explicit_instantiation instead of always_inlineLouis Dionne2018-10-291-0/+7
| | | | | | | | | | | | | | | | | | | | | | | Summary: This commit adopts the exclude_from_explicit_instantiation attribute discussed at [1] and reviewed in [2] in libc++ to supplant the use of __always_inline__ for visibility purposes. This change means that users wanting to link together translation units built with different versions of libc++'s headers into the same final linked image MUST define the _LIBCPP_HIDE_FROM_ABI_PER_TU macro to 1 when building those TUs. Doing otherwise will lead to ODR violations and ABI issues. [1]: http://lists.llvm.org/pipermail/cfe-dev/2018-August/059024.html [2]: https://reviews.llvm.org/D51789 Reviewers: rsmith, EricWF Subscribers: dexonsmith, libcxx-commits Differential Revision: https://reviews.llvm.org/D52405 llvm-svn: 345516
* [libc++] Make sure we can build libc++ with -fvisibility=hiddenLouis Dionne2018-10-251-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: When building with -fvisibility=hidden, some symbols do not get exported from libc++.dylib. This means that some entities are not explicitly given default visibility in the source code, and that we rely on the fact -fvisibility=default is the default. This commit explicitly gives default visibility to those symbols to avoid being dependent on the command line flags used. The commit also remove symbols from the dylib -- those symbols do not actually need to be exported from the dylib and this should not be an ABI break. Finally, in the future, we may want to mark the whole std:: namespace as having hidden visibility (to switch from opt-out to opt-in), in which case the changes done in this commit will be required. Reviewers: EricWF Subscribers: mgorny, christof, dexonsmith, libcxx-commits Differential Revision: https://reviews.llvm.org/D52662 llvm-svn: 345260
* [libcxx] Remove custom CMake code targeting Mac OS 10.6Louis Dionne2018-10-161-1/+1
| | | | | | | | | | | | | libc++ has dropped support for Mac OS 10.6 for a while, and we don't have any testers set up for that OS. This commit puts in an error message so that people can reach out to the libc++ maintainers in case support for 10.6 is still expected (as opposed to silently failing in weird ways). We can completely drop support for 10.6 and remove the error message some time in the future when we're sure that nobody is relying on it. llvm-svn: 344576
* [libc++] Add deprecated attributes to many deprecated componentsLouis Dionne2018-09-231-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: These deprecation warnings are opt-in: they are only enabled when the _LIBCXX_DEPRECATION_WARNINGS macro is defined, which is not the case by default. Note that this is a first step in the right direction, but I wasn't able to get an exhaustive list of all deprecated components per standard, so there's certainly stuff that's missing. The list of components this commit marks as deprecated is: in C++11: - auto_ptr, auto_ptr_ref - binder1st, binder2nd, bind1st(), bind2nd() - pointer_to_unary_function, pointer_to_binary_function, ptr_fun() - mem_fun_t, mem_fun1_t, const_mem_fun_t, const_mem_fun1_t, mem_fun() - mem_fun_ref_t, mem_fun1_ref_t, const_mem_fun_ref_t, const_mem_fun1_ref_t, mem_fun_ref() in C++14: - random_shuffle() in C++17: - unary_negate, binary_negate, not1(), not2() <rdar://problem/18168350> Reviewers: mclow.lists, EricWF Subscribers: christof, dexonsmith, llvm-commits Differential Revision: https://reviews.llvm.org/D48912 llvm-svn: 342843
* Correct docs to reference the new libc++ lists.Eric Fiselier2018-09-221-9/+6
| | | | | | | | We recently added libcxx-dev and libcxx-commits mailing lists. This patch updates the libc++ documentation to correctly reference the libc++ lists instead of the old Clang ones. llvm-svn: 342816
* [libc++] Add _LIBCPP_ENABLE_NODISCARD and _LIBCPP_NODISCARD_EXT to allow ↵Roman Lebedev2018-09-221-0/+70
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | pre-C++2a [[nodiscard]] Summary: The `[[nodiscard]]` attribute is intended to help users find bugs where function return values are ignored when they shouldn't be. After C++17 the C++ standard has started to declared such library functions as `[[nodiscard]]`. However, this application is limited and applies only to dialects after C++17. Users who want help diagnosing misuses of STL functions may desire a more liberal application of `[[nodiscard]]`. For this reason libc++ provides an extension that does just that! The extension must be enabled by defining `_LIBCPP_ENABLE_NODISCARD`. The extended applications of `[[nodiscard]]` takes two forms: 1. Backporting `[[nodiscard]]` to entities declared as such by the standard in newer dialects, but not in the present one. 2. Extended applications of `[[nodiscard]]`, at the libraries discretion, applied to entities never declared as such by the standard. Users may also opt-out of additional applications `[[nodiscard]]` using additional macros. Applications of the first form, which backport `[[nodiscard]]` from a newer dialect may be disabled using macros specific to the dialect it was added. For example `_LIBCPP_DISABLE_NODISCARD_AFTER_CXX17`. Applications of the second form, which are pure extensions, may be disabled by defining `_LIBCPP_DISABLE_NODISCARD_EXT`. This patch was originally written by me (Roman Lebedev), then but then reworked by Eric Fiselier. Reviewers: mclow.lists, thakis, EricWF Reviewed By: thakis, EricWF Subscribers: llvm-commits, mclow.lists, lebedev.ri, EricWF, rjmccall, Quuxplusone, cfe-commits, christof Differential Revision: https://reviews.llvm.org/D45179 llvm-svn: 342808
* fix some typos in the docSylvestre Ledru2018-09-203-5/+5
| | | | llvm-svn: 342628
* refresh the libc++ homepageSylvestre Ledru2018-09-201-3/+3
| | | | llvm-svn: 342624
* ReleaseNotes: update links to use httpsHans Wennborg2018-09-101-6/+6
| | | | llvm-svn: 341789
* [libc++] Add a link to the Release notes from the main libc++ documentationLouis Dionne2018-09-061-0/+1
| | | | llvm-svn: 341551
* [libcxx] Add ReleaseNotes.rst file for release notesLouis Dionne2018-09-061-0/+43
| | | | llvm-svn: 341550
* [libcxx] By default, do not use internal_linkage to hide symbols from the ABILouis Dionne2018-08-162-3/+45
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: https://reviews.llvm.org/D49240 led to symbol size problems in Chromium, and we expect this may be the case in other projects built in debug mode too. Instead, unless users explicitly ask for internal_linkage, we use always_inline like we used to. In the future, when we have a solution that allows us to drop always_inline without falling back on internal_linkage, we can replace always_inline by that. Note that this commit introduces a change in contract for existing libc++ users: by default, libc++ used to guarantee that TUs built with different versions of libc++ could be linked together. With the introduction of the _LIBCPP_HIDE_FROM_ABI_PER_TU macro, the default behavior is that TUs built with different libc++ versions are not guaranteed to link. This is a change in contract but not a change in behavior, since the current implementation still allows linking TUs built with different libc++ versions together. Reviewers: EricWF, mclow.lists, dexonsmith, hans, rnk Subscribers: christof, cfe-commits Differential Revision: https://reviews.llvm.org/D50652 llvm-svn: 339874
* [libc++] Add the _LIBCPP_HIDE_FROM_ABI_AFTER_V1 macroLouis Dionne2018-08-061-9/+15
| | | | | | | | | | | | | | | | | | | | | Summary: This macro allows hiding symbols from the ABI when the library is built with an ABI version after ABI v1, which is currently the only stable ABI. This commit defines `_LIBCPP_EXTERN_TEMPLATE_INLINE_VISIBILITY` to be `_LIBCPP_HIDE_FROM_ABI_AFTER_V1`, meaning that symbols that were only exported by the library for historical reasons are not exported anymore in the unstable ABI. Because of that, this commit is an ABI break for ABI v2. This ABI version is not stable, however, so this should not be a problem. Reviewers: EricWF, mclow.lists Subscribers: christof, dexonsmith, cfe-commits Differential Revision: https://reviews.llvm.org/D49914 llvm-svn: 339012
* Update version to 8.0.0svn: cmake, includes files and docsHans Wennborg2018-08-011-3/+3
| | | | llvm-svn: 338555
* [libc++] Introduce _LIBCPP_HIDE_FROM_ABI to replace _LIBCPP_INLINE_VISIBILITYLouis Dionne2018-07-271-1/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This commit introduces a new macro, _LIBCPP_HIDE_FROM_ABI, whose goal is to mark functions that shouldn't be part of libc++'s ABI. It marks the functions as being hidden for dylib visibility purposes, and as having internal linkage using Clang's __attribute__((internal_linkage)) when available, and __always_inline__ otherwise. It replaces _LIBCPP_INLINE_VISIBILITY, which was always using __always_inline__ to achieve similar goals, but suffered from debuggability and code size problems. The full proposal, along with more background information, can be found here: http://lists.llvm.org/pipermail/cfe-dev/2018-July/058419.html This commit does not rename uses of _LIBCPP_INLINE_VISIBILITY to _LIBCPP_HIDE_FROM_ABI: this wide reaching but mechanical change can be done later when we've confirmed we're happy with the new macro. In the future, it would be nice if we could optionally allow dropping any internal_linkage or __always_inline__ attribute, which could result in code size improvements. However, this is currently impossible for reasons explained here: http://lists.llvm.org/pipermail/cfe-dev/2018-July/058450.html Reviewers: EricWF, dexonsmith, mclow.lists Subscribers: christof, dexonsmith, llvm-commits, mclow.lists Differential Revision: https://reviews.llvm.org/D49240 llvm-svn: 338122
* Implement <filesystem>Eric Fiselier2018-07-272-3/+28
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch implements the <filesystem> header and uses that to provide <experimental/filesystem>. Unlike other standard headers, the symbols needed for <filesystem> have not yet been placed in libc++.so. Instead they live in the new libc++fs.a library. Users of filesystem are required to link this library. (Also note that libc++experimental no longer contains the definition of <experimental/filesystem>, which now requires linking libc++fs). The reason for keeping <filesystem> out of the dylib for now is that it's still somewhat experimental, and the possibility of requiring an ABI breaking change is very real. In the future the symbols will likely be moved into the dylib, or the dylib will be made to link libc++fs automagically). Note that moving the symbols out of libc++experimental may break user builds until they update to -lc++fs. This should be OK, because the experimental library provides no stability guarantees. However, I plan on looking into ways we can force libc++experimental to automagically link libc++fs. In order to use a single implementation and set of tests for <filesystem>, it has been placed in a special `__fs` namespace. This namespace is inline in C++17 onward, but not before that. As such implementation is available in C++11 onward, but no filesystem namespace is present "directly", and as such name conflicts shouldn't occur in C++11 or C++14. llvm-svn: 338093
* [NFC] Fix grammatical mistakes in libc++ FileTimeType design docsLouis Dionne2018-07-251-10/+10
| | | | llvm-svn: 337925
* Fix another typo in the FileTimeType docsEric Fiselier2018-07-251-1/+1
| | | | llvm-svn: 337900
* Fix typos, spelling, and grammar in the FileTimeType design docs.Eric Fiselier2018-07-251-36/+37
| | | | | | I'm sure I'll discover more mistakes as I go on... llvm-svn: 337897
* Add design docs for upcoming file_time_type change.Eric Fiselier2018-07-253-1/+495
| | | | | | | | | | | | | | | | | | In upcoming changes to filesystem I plan to change file_time_type to use __int128_t as its underlying representation, in order to allow it to have a range and resolution at least that of the timespec struct. There was some pushback against this decision, so I drafted a document explaining the problems, potential solutions, and the rational for the decision. However, it's probably easier to let people read the generated HTML rather than the raw restructured text. For this reason I'm commiting the design documents before hand, so they can be available during any subsequent discussion or code review. llvm-svn: 337880
* [libc++] Take 2: Replace uses of _LIBCPP_ALWAYS_INLINE by ↵Louis Dionne2018-07-111-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | _LIBCPP_INLINE_VISIBILITY Summary: We never actually mean to always inline a function -- all the uses of the macro I could find are actually attempts to control the visibility of symbols. This is better described by _LIBCPP_INLINE_VISIBILITY, which is actually always defined the same. This change is orthogonal to the decision of what we're actually going to do with _LIBCPP_INLINE_VISIBILITY -- it just simplifies things by having one canonical way of doing things. Note that this commit had originally been applied in r336369 and then reverted in r336382 because of unforeseen problems. Both of these problems have now been fixed. Reviewers: EricWF, mclow.lists Subscribers: christof, dexonsmith, erikvanderpoel Differential Revision: https://reviews.llvm.org/D48892 llvm-svn: 336866
* Revert "[libc++] Replace uses of _LIBCPP_ALWAYS_INLINE by ↵Louis Dionne2018-07-051-4/+4
| | | | | | | | | | | | | | | _LIBCPP_INLINE_VISIBILITY" This reverts commit r336369. The commit had two problems: 1. __pbump was marked as _LIBCPP_EXTERN_TEMPLATE_INLINE_VISIBILITY instead of _LIBCPP_INLINE_VISIBILITY, which lead to two symbols being added in the dylib and the check-cxx-abilist failing. 2. The LLDB tests started failing because they undefine `_LIBCPP_INLINE_VISIBILITY`. I need to figure out why they do that and fix the tests before we can go forward with this change. llvm-svn: 336382
* [libc++] Replace uses of _LIBCPP_ALWAYS_INLINE by _LIBCPP_INLINE_VISIBILITYLouis Dionne2018-07-051-4/+4
| | | | | | | | | | | | | | | | | | | | Summary: We never actually mean to always inline a function -- all the uses of the macro I could find are actually attempts to control the visibility of symbols. This is better described by _LIBCPP_INLINE_VISIBILITY, which is actually always defined the same. This change is orthogonal to the decision of what we're actually going to do with _LIBCPP_INLINE_VISIBILITY -- it just simplifies things by having one canonical way of doing things. Reviewers: EricWF Subscribers: christof, llvm-commits, dexonsmith, erikvanderpoel, mclow.lists Differential Revision: https://reviews.llvm.org/D48892 llvm-svn: 336369
* Fix typos.Bruce Mitchener2018-02-132-2/+2
| | | | | | | | | | Reviewers: mclow.lists, EricWF Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D43224 llvm-svn: 324989
* [cmake] Add a config option LIBCXX_HAS_WIN32_THREAD_API for enforcing win32 ↵Martin Storsjo2018-01-051-0/+4
| | | | | | | | | | | | | | | | threads This allows keeping libcxx using win32 threads even if a version of pthread.h is installed. This matches the existing cmake option LIBCXX_HAS_PTHREAD_API. Also add missing documentation about the internal define _LIBCPP_HAS_THREAD_API_WIN32. Differential Revision: https://reviews.llvm.org/D41764 llvm-svn: 321896
* Update version to 7.0.0svn: cmake, include files and docsHans Wennborg2018-01-031-2/+2
| | | | llvm-svn: 321725
* Corrected a typo in the building libc++ docsHamza Sood2017-12-031-1/+1
| | | | llvm-svn: 319631
* Teach test suite about C++2a dialect flag.Eric Fiselier2017-11-071-1/+1
| | | | | | | | This patch teaches the test suite configuration about the -std=c++2a flag. And, since it's the newest dialect, change the test suite to choose it, if possible, by default. llvm-svn: 317611
* Change test suite to support c++17 dialect flag instead of c++1z.Eric Fiselier2017-11-071-1/+1
| | | | | | | | This patch changes the test suite to attempt and prefer -std=c++17 over -std=c++1z. It also fixes the REQUIRES and UNSUPPORTED lit markers to refer to c++17 over c++1z. llvm-svn: 317610
* [libc++] Support Microsoft ABI without vcruntime headersShoaib Meenai2017-10-091-0/+20
| | | | | | | | | | | | | | | | | The vcruntime headers are hairy and clash with both libc++ headers themselves and other libraries. libc++ normally deals with the clashes by deferring to the vcruntime headers and silencing its own definitions, but for clients which don't want to depend on vcruntime headers, it's desirable to support the opposite, i.e. have libc++ provide its own definitions. Certain operator new/delete replacement scenarios are not currently supported in this mode, which requires some tests to be marked XFAIL. The added documentation has more details. Differential Revision: https://reviews.llvm.org/D38522 llvm-svn: 315234
* [libc++] Add site config option for ABI macrosShoaib Meenai2017-10-041-0/+7
| | | | | | | | | | | | | | | | | Some ABI macros affect headers, so it's nice to have a site config option for them. Add a LIBCXX_ABI_DEFINES cmake macro to allow specifying a list of ABI macros to define in the site config. The primary design constraint (as discussed with Eric on IRC a while back) was to not have to repeat the ABI macro names in cmake, which only leaves a free-form cmake list as an option. A somewhat unfortunate consequence is that we can't verify that the ABI macros being defined actually exist, though we can at least perform some basic sanity checking, since all the ABI macros begin with _LIBCPP_ABI_. Differential Revision: https://reviews.llvm.org/D36719 llvm-svn: 314946
* Bump docs version to 6.0Hans Wennborg2017-07-191-2/+2
| | | | llvm-svn: 308462
* [libc++] class template -> template class. NFCShoaib Meenai2017-07-131-1/+1
| | | | llvm-svn: 307972
* [libc++] Mark string operator+ _LIBCPP_FUNC_VISShoaib Meenai2017-07-131-1/+2
| | | | | | | | | | | | | | | It has an extern template instantiation declaration in the headers and a corresponding instantiation definition in the library, so we must mark it with _LIBCPP_FUNC_VIS to make it available outside the library. This doesn't cause any ABI changes as-is since we don't build libc++ with hidden visibility (so the function is exported anyway). It's needed for building libc++ with hidden visibility, however. Clarify the Windows behavior for extern function templates while I'm here, since this exercises that behavior. llvm-svn: 307966
* [libc++] Use proper template terminology. NFCShoaib Meenai2017-07-131-3/+3
| | | | | | | It's supposed to be "class template" and "function template" instead of "template class" and "template function". llvm-svn: 307954
* [libcxx][CMake] Add install path variable to allow overriding the destinationPetr Hosek2017-07-111-0/+5
| | | | | | | | | This is going to be used by the runtime build in the multi-target setup to allow using different install prefix for each target. Differential Revision: https://reviews.llvm.org/D33762 llvm-svn: 307615
OpenPOWER on IntegriCloud