mirrors/llvm-project
0
0
Fork 0
mirror of https://github.com/llvm/llvm-project.git synced 2025-04-26 20:36:05 +00:00
Code Issues Projects Releases Wiki Activity
llvm-project/libcxx/include/csetjmp

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

60 lines
1.3 KiB
Plaintext
Raw Normal View History

libcxx initial import llvm-svn: 103490
2010-05-11 19:42:16 +00:00
// -*- C++ -*-
[runtimes][NFC] Remove filenames at the top of the license notice We've stopped doing it in libc++ for a while now because these names would end up rotting as we move things around and copy/paste stuff. This cleans up all the existing files so as to stop the spreading as people copy-paste headers around.
2021-11-17 16:25:01 -05:00
//===----------------------------------------------------------------------===//
libcxx initial import llvm-svn: 103490
2010-05-11 19:42:16 +00:00
//
Update more file headers across all of the LLVM projects in the monorepo to reflect the new license. These used slightly different spellings that defeated my regular expressions. We understand that people may be surprised that we're moving the header entirely to discuss the new license. We checked this carefully with the Foundation's lawyer and we believe this is the correct approach. Essentially, all code in the project is now made available by the LLVM project under our new license, so you will see that the license headers include that license only. Some of our contributors have contributed code under our old license, and accordingly, we have retained a copy of our old license notice in the top-level files in each project and repository. llvm-svn: 351648
2019-01-19 10:56:40 +00:00
// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
// See https://llvm.org/LICENSE.txt for license information.
// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
libcxx initial import llvm-svn: 103490
2010-05-11 19:42:16 +00:00
//
//===----------------------------------------------------------------------===//
#ifndef _LIBCPP_CSETJMP
#define _LIBCPP_CSETJMP
/*
csetjmp synopsis
Macros:
setjmp
namespace std
{
Types:
jmp_buf
void longjmp(jmp_buf env, int val);
} // std
*/
[libc++][C++03] Use `__cxx03/` headers in C++03 mode (#109002) This patch implements the forwarding to frozen C++03 headers as discussed in https://discourse.llvm.org/t/rfc-freezing-c-03-headers-in-libc. In the RFC, we initially proposed selecting the right headers from the Clang driver, however consensus seemed to steer towards handling this in the library itself. This patch implements that direction. At a high level, the changes basically amount to making each public header look like this: ``` // inside <vector> #ifdef _LIBCPP_CXX03_LANG # include <__cxx03/vector> #else // normal <vector> content #endif ``` In most cases, public headers are simple umbrella headers so there isn't much code in the #else branch. In other cases, the #else branch contains the actual implementation of the header.
2024-12-21 13:01:48 +01:00
#if __cplusplus < 201103L && defined(_LIBCPP_USE_FROZEN_CXX03_HEADERS)
# include <__cxx03/csetjmp>
#else
[libc++] Add #if 0 block to all the top-level headers (#119234) Including The frozen C++03 headers results in a lot of formatting changes in the main headers, so this splits these changes into a separate commit instead. This is part of https://discourse.llvm.org/t/rfc-freezing-c-03-headers-in-libc.
2024-12-10 16:02:12 +01:00
# include <__config>
[libc++] Diagnose when header search paths are set up incorrectly An issue I often see in codebases compiled for unusual platforms is that header search paths are specified manually and are subtly wrong. For example, people will manually add `-isystem <some-toolchain>/usr/include`, which ends up messing up the layering of header search paths required by libc++ (because the C Standard Library now appears *before* libc++ in the search paths). Without this patch, this will end up causing compilation errors that are pretty inscrutable. This patch aims to improve the user experience by diagnosing this issue explicitly. In all cases I can think of, I would expect that a compilation error occur if these header search paths are not layered properly. This should only provide an explicit diagnostic instead of failing due to seemingly unrelated compilation errors. Differential Revision: https://reviews.llvm.org/D131441
2022-08-08 17:03:56 -04:00
[libc++] Only include <setjmp.h> from the C library if it exists (#81887) In 2cea1babefbb, we removed the <setjmp.h> header provided by libc++. However, we did not conditionally include the underlying <setjmp.h> header only if the C library provides one, which we otherwise do consistently (see e.g. 647ddc08f43c). rdar://122978778
2024-02-16 16:45:00 -05:00
// <setjmp.h> is not provided by libc++
[libc++] Add #if 0 block to all the top-level headers (#119234) Including The frozen C++03 headers results in a lot of formatting changes in the main headers, so this splits these changes into a separate commit instead. This is part of https://discourse.llvm.org/t/rfc-freezing-c-03-headers-in-libc.
2024-12-10 16:02:12 +01:00
# if __has_include(<setjmp.h>)
# include <setjmp.h>
# ifdef _LIBCPP_SETJMP_H
# error "If libc++ starts defining <setjmp.h>, the __has_include check should move to libc++'s <setjmp.h>"
# endif
[libc++] Only include <setjmp.h> from the C library if it exists (#81887) In 2cea1babefbb, we removed the <setjmp.h> header provided by libc++. However, we did not conditionally include the underlying <setjmp.h> header only if the C library provides one, which we otherwise do consistently (see e.g. 647ddc08f43c). rdar://122978778
2024-02-16 16:45:00 -05:00
# endif
libcxx initial import llvm-svn: 103490
2010-05-11 19:42:16 +00:00
[libc++] Add #if 0 block to all the top-level headers (#119234) Including The frozen C++03 headers results in a lot of formatting changes in the main headers, so this splits these changes into a separate commit instead. This is part of https://discourse.llvm.org/t/rfc-freezing-c-03-headers-in-libc.
2024-12-10 16:02:12 +01:00
# if !defined(_LIBCPP_HAS_NO_PRAGMA_SYSTEM_HEADER)
# pragma GCC system_header
# endif
libcxx initial import llvm-svn: 103490
2010-05-11 19:42:16 +00:00
_LIBCPP_BEGIN_NAMESPACE_STD
[libc++] Use the using_if_exists attribute when provided As discussed on cfe-dev [1], use the using_if_exists Clang attribute when the compiler supports it. This makes it easier to port libc++ on top of new platforms that don't fully support the C Standard library. Previously, libc++ would fail to build when trying to import a missing declaration in a <cXXXX> header. With the attribute, the declaration will simply not be imported into namespace std, and hence it won't be available for libc++ to use. In many cases, the declarations were *not* actually required for libc++ to work (they were only surfaced for users to use them as std::XXXX), so not importing them into namespace std is acceptable. The same thing could be achieved by conscious usage of `#ifdef` along with platform detection, however that quickly creates a maintenance problem as libc++ is ported to new platforms. Furthermore, this problem is exacerbated when mixed with vendor internal-only platforms, which can lead to difficulties maintaining a downstream fork of the library. For the time being, we only use the using_if_exists attribute when it is supported. At some point in the future, we will start removing #ifdef paths that are unnecessary when the attribute is supported, and folks who need those #ifdef paths will be required to use a compiler that supports the attribute. [1]: http://lists.llvm.org/pipermail/cfe-dev/2020-June/066038.html Differential Revision: https://reviews.llvm.org/D90257
2021-06-02 10:41:37 -04:00
using ::jmp_buf _LIBCPP_USING_IF_EXISTS;
using ::longjmp _LIBCPP_USING_IF_EXISTS;
libcxx initial import llvm-svn: 103490
2010-05-11 19:42:16 +00:00
_LIBCPP_END_NAMESPACE_STD
[libc++][C++03] Use `__cxx03/` headers in C++03 mode (#109002) This patch implements the forwarding to frozen C++03 headers as discussed in https://discourse.llvm.org/t/rfc-freezing-c-03-headers-in-libc. In the RFC, we initially proposed selecting the right headers from the Clang driver, however consensus seemed to steer towards handling this in the library itself. This patch implements that direction. At a high level, the changes basically amount to making each public header look like this: ``` // inside <vector> #ifdef _LIBCPP_CXX03_LANG # include <__cxx03/vector> #else // normal <vector> content #endif ``` In most cases, public headers are simple umbrella headers so there isn't much code in the #else branch. In other cases, the #else branch contains the actual implementation of the header.
2024-12-21 13:01:48 +01:00
#endif // __cplusplus < 201103L && defined(_LIBCPP_USE_FROZEN_CXX03_HEADERS)
[libc++] Add #if 0 block to all the top-level headers (#119234) Including The frozen C++03 headers results in a lot of formatting changes in the main headers, so this splits these changes into a separate commit instead. This is part of https://discourse.llvm.org/t/rfc-freezing-c-03-headers-in-libc.
2024-12-10 16:02:12 +01:00
[libc++] NFC: Normalize `#endif //` comment indentation
2021-04-20 12:03:32 -04:00
#endif // _LIBCPP_CSETJMP
Reference in New Issue Copy Permalink