summaryrefslogtreecommitdiffstats
path: root/libcxx/include/ios
Commit message (Collapse)AuthorAgeFilesLines
* [NFC][libcxx] Remove trailing whitespaceLouis Dionne2019-05-291-15/+15
| | | | | | It's incredibly annoying when trying to create diffs llvm-svn: 361981
* [libc++] Fix error flags and exceptions propagated from input stream operationsLouis Dionne2019-04-051-0/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This is a re-application of r357533 and r357531. They had been reverted because we thought the commits broke the LLDB data formatters, but it turns out this was because only r357531 had been included in the CI run. Before this patch, we would only ever throw an exception if the badbit was set on the stream. The Standard is currently very unclear on how exceptions should be propagated and what error flags should be set by the input stream operations. This commit changes libc++ to behave under a different (but valid) interpretation of the Standard. This interpretation of the Standard matches what other implementations are doing. This effectively implements the wording in p1264r0. It hasn't been voted into the Standard yet, however there is wide agreement that the fix is correct and it's just a matter of time before the fix is standardized. PR21586 PR15949 rdar://problem/15347558 Reviewers: mclow.lists, EricWF Subscribers: christof, dexonsmith, cfe-commits Differential Revision: https://reviews.llvm.org/D49863 llvm-svn: 357775
* Revert "[libc++] Fix error flags and exceptions propagated from input stream ↵Louis Dionne2019-04-021-9/+0
| | | | | | | | | | operations" This reverts commits r357533 and r357531, which broke the LLDB data formatters. I'll hold off until we know how to fix the data formatters accordingly. llvm-svn: 357536
* [libc++] Fix error flags and exceptions propagated from input stream operationsLouis Dionne2019-04-021-0/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Before this patch, we would only ever throw an exception if the badbit was set on the stream. The Standard is currently very unclear on how exceptions should be propagated and what error flags should be set by the input stream operations. This commit changes libc++ to behave under a different (but valid) interpretation of the Standard. This interpretation of the Standard matches what other implementations are doing. I will submit a paper in San Diego to clarify the Standard such that the interpretation used in this commit (and other implementations) is the only possible one. PR21586 PR15949 rdar://problem/15347558 Reviewers: mclow.lists, EricWF Subscribers: christof, dexonsmith, cfe-commits Differential Revision: https://reviews.llvm.org/D49863 llvm-svn: 357531
* [libc++] Avoid UB in the no-exceptions mode in a few placesLouis Dionne2019-02-121-0/+10
| | | | | | | | | | | | | | | | | | | | | | | Summary: A few places in the library seem to behave unexpectedly when the library is compiled or used with exceptions disabled. For example, not throwing an exception when a pointer is NULL can lead us to dereference the pointer later on, which is UB. This patch fixes such occurences. It's hard to tell whether there are other places where the no-exceptions mode misbehaves like this, because the replacement for throwing an exception does not always seem to be abort()ing, but at least this patch will improve the situation somewhat. See http://lists.llvm.org/pipermail/libcxx-dev/2019-January/000172.html Reviewers: mclow.lists, EricWF Subscribers: christof, jkorous, dexonsmith, libcxx-commits Differential Revision: https://reviews.llvm.org/D57761 llvm-svn: 353850
* Update more file headers across all of the LLVM projects in the monorepoChandler Carruth2019-01-191-4/+3
| | | | | | | | | | | | | | | | | | 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
* [libc++] Take 2: Replace uses of _LIBCPP_ALWAYS_INLINE by ↵Louis Dionne2018-07-111-17/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | _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-17/+17
| | | | | | | | | | | | | | | _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-17/+17
| | | | | | | | | | | | | | | | | | | | 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 incorrect indentation.Bruce Mitchener2018-02-141-1/+1
| | | | | | | | | | Reviewers: mclow.lists Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D43167 llvm-svn: 325087
* Add static_asserts to basic_ios and basic_stream_buf to ensure that that the ↵Marshall Clow2018-02-011-0/+3
| | | | | | traits match the character type. This is a requirement on the user - now we get consistent failures at compile time instead of incomprehensible error messages or runtime failures. This is also LWG#2994 - not yet adopted. llvm-svn: 323945
* Cleanup usages of _LIBCPP_HAS_NO_<c++11-feature> in <bitset>, <ios>, ↵Eric Fiselier2017-04-191-1/+1
| | | | | | <locale>, and <iterator> llvm-svn: 300648
* Fix merge conflict caused by r291921Eric Fiselier2017-01-131-1/+1
| | | | llvm-svn: 291925
* Revert "Rework fix for PR19460 - Use explicit bool as an extension instead."Eric Fiselier2017-01-131-0/+17
| | | | | | This reverts commit 3a1b90a866b6d5d62a5f37fbfb3a1ee36cc70dd1. llvm-svn: 291921
* [NFC] Rename _LIBCPP_TYPE_VIS_ONLY to _LIBCPP_TEMPLATE_VISEric Fiselier2017-01-041-3/+3
| | | | | | | | | | | | | The name _LIBCPP_TYPE_VIS_ONLY is no longer accurate because both _LIBCPP_TYPE_VIS and _LIBCPP_TYPE_VIS_ONLY expand to __attribute__((__type_visibility__)) with Clang. The only remaining difference is that _LIBCPP_TYPE_VIS_ONLY can be applied to templates whereas _LIBCPP_TYPE_VIS cannot (due to dllimport/dllexport not being allowed on templates). This patch renames _LIBCPP_TYPE_VIS_ONLY to _LIBCPP_TEMPLATE_VIS. llvm-svn: 291035
* Rework fix for PR19460 - Use explicit bool as an extension instead.Eric Fiselier2017-01-021-17/+0
| | | | | | | | | | | | | | | | | | | | | | | | | In the previous fix I used a PMF type as a semi-safe bool type in C++03. However immediately after committing I realized clang offered explicit conversion operators as an extension. This patch removes the old fix and enables _LIBCPP_EXPLICIT using __has_extension instead. This change also affects the following other classes, which have '_LIBCPP_EXPLICIT operator bool()'. * shared_ptr * unique_ptr * error_condition * basic_ios * function (already C++11 only) * istream::sentry * experimental::string_view. In all of the above cases I believe it is safe to enable the extension, except in the experimental::string_view case. There seem to be some Clang bugs affecting the experimental::string_view conversion to std::basic_string. To work around that I manually disabled _LIBCPP_EXPLICIT in that case. llvm-svn: 290831
* Recommit r290750: Fix PR19460 - std::ios is convertible to int.Eric Fiselier2016-12-301-2/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | There were two problems with the initial fix. 1. The added tests flushed out that we misconfigured _LIBCPP_EXPLICIT with GCC. 2. Because the boolean type was a member function template it caused weird link errors. I'm assuming due to the vague linkage rules. This time the bool type is a non-template member function pointer. That seems to have fixed the failing tests. Plus it will end up generating less symbols overall, since the bool type is no longer per instantiation. original commit message below ----------------------------- std::basic_ios has an operator bool(). In C++11 and later it is explicit, and only allows contextual implicit conversions. However explicit isn't available in C++03 which causes std::istream (et al) to have an implicit conversion to int. This can easily cause ambiguities when calling operator<< and operator>>. This patch uses a "bool-like" type in C++03 to work around this. The "bool-like" type is an arbitrary pointer to member function type. It will not convert to either int or void*, but will convert to bool. llvm-svn: 290754
* Revert r290750 - Fix PR19460 - std::ios is convertible to int.Eric Fiselier2016-12-301-15/+2
| | | | llvm-svn: 290752
* Fix PR19460 - std::ios is convertible to int.Eric Fiselier2016-12-301-2/+15
| | | | | | | | | | | | | | | std::basic_ios has an operator bool(). In C++11 and later it is explicit, and only allows contextual implicit conversions. However explicit isn't available in C++03 which causes std::istream (et al) to have an implicit conversion to int. This can easily cause ambiguities when calling operator<< and operator>>. This patch uses a "bool-like" type in C++03 to work around this. The "bool-like" type is an arbitrary pointer to member function type. It will not convert to either int or void*, but will convert to bool. llvm-svn: 290750
* Make ios_base::failure visibility specified consistentEric Fiselier2016-04-211-1/+1
| | | | llvm-svn: 267076
* Implement P0004R1 'Remove Deprecated iostreams aliases'Marshall Clow2015-10-291-6/+9
| | | | llvm-svn: 251618
* [libcxx] Allow use of <atomic> in C++03. Try 3.Eric Fiselier2015-08-191-2/+4
| | | | | | | | | | | | | | | | | | | | | | | Summary: After putting this question up on cfe-dev I have decided that it would be best to allow the use of `<atomic>` in C++03. Although static initialization is a concern the syntax required to get it is C++11 only. Meaning that C++11 constant static initialization cannot silently break in C++03, it will always cause a syntax error. Furthermore `ATOMIC_VAR_INIT` and `ATOMIC_FLAG_INIT` remain defined in C++03 even though they cannot be used because C++03 usages will cause better error messages. The main change in this patch is to replace `__has_feature(cxx_atomic)`, which only returns true when C++ >= 11, to `__has_extension(c_atomic)` which returns true whenever clang supports the required atomic builtins. This patch adds the following macros: * `_LIBCPP_HAS_C_ATOMIC_IMP` - Defined on clang versions which provide the C `_Atomic` keyword. * `_LIBCPP_HAS_GCC_ATOMIC_IMP` - Defined on GCC > 4.7. We must use the fallback atomic implementation. * `_LIBCPP_HAS_NO_ATOMIC_HEADER` - Defined when it is not safe to include `<atomic>`. `_LIBCPP_HAS_C_ATOMIC_IMP` and `_LIBCPP_HAS_GCC_ATOMIC_IMP` are mutually exclusive, only one should be defined. If neither is defined then `<atomic>` is not implemented and including `<atomic>` will issue an error. Reviewers: chandlerc, jroelofs, mclow.lists Subscribers: cfe-commits Differential Revision: http://reviews.llvm.org/D11555 llvm-svn: 245463
* Address some post-commit review comments on r217261Jonathan Roelofs2014-09-051-2/+2
| | | | llvm-svn: 217276
* Allow libc++ to be built on systems without POSIX threadsJonathan Roelofs2014-09-051-2/+2
| | | | | | | | | | If you're crazy enough to want this sort of thing, then add -D_LIBCPP_HAS_NO_THREADS to your CXXFLAGS and --param=additiona_features=libcpp-has-no-threads to your lit commnad line. http://reviews.llvm.org/D3969 llvm-svn: 217271
* Patch by GM: Making implicit conversion to bool explicit in <ios> and <__locale>Marshall Clow2013-10-211-3/+3
| | | | llvm-svn: 193085
* LWG Issue 2087: iostream_category() and noexceptMarshall Clow2013-10-121-6/+6
| | | | llvm-svn: 192545
* LWG issue 2143: ios_base::xalloc should be thread-safeMarshall Clow2013-10-121-0/+8
| | | | llvm-svn: 192539
* G M: Rename local variable from __except to avoid MSVC keyword clash.Howard Hinnant2013-10-061-4/+4
| | | | llvm-svn: 192072
* Nico Rieck: this patch series fixes visibility issues on Windows as ↵Howard Hinnant2013-08-121-3/+3
| | | | | | explained in <http://lists.cs.uiuc.edu/pipermail/cfe-dev/2013-August/031214.html>. llvm-svn: 188192
* move __save_flags from <random> to <ios> in preparation for reuse; no ↵Marshall Clow2013-07-091-0/+27
| | | | | | functionality change llvm-svn: 185968
* No functionality change at this time. I've split _LIBCPP_VISIBLE up into ↵Howard Hinnant2013-03-061-8/+8
| | | | | | two flags: _LIBCPP_TYPE_VIS and _LIBCPP_FUNC_VIS. This is in preparation for taking advantage of clang's new __type_visibility__ attribute. llvm-svn: 176593
* Rename uses of _ and __ because these are getting stepped on by macros from ↵Howard Hinnant2012-10-301-1/+1
| | | | | | other system code. llvm-svn: 167038
* Dimitry Andric: many visibility fixes. Howard: Much appreciated. Can you ↵Howard Hinnant2012-09-141-2/+2
| | | | | | send me a patch to CREDITS.TXT? llvm-svn: 163862
* Hyeon-bin Jeong: libc++ fails to create any classes inherit from basic_ios ↵Howard Hinnant2012-08-261-2/+4
| | | | | | | | | | | if they provided char type other than char or wchar_t. It throw exception during construction, so there is no chance to imbue own ctype. This fixes http://llvm.org/bugs/show_bug.cgi?id=13698 llvm-svn: 162648
* noexcept and constexpr applied to <ios>.Howard Hinnant2012-07-211-35/+35
| | | | llvm-svn: 160593
* Modernize conversion to bool to the explicit bool conversion operator ↵Howard Hinnant2012-02-211-1/+2
| | | | | | (library wide). This fixes http://llvm.org/bugs/show_bug.cgi?id=12058. llvm-svn: 151088
* Fix http://llvm.org/bugs/show_bug.cgi?id=11428. Fix provided by Alberto ↵Howard Hinnant2011-12-021-7/+5
| | | | | | Ganesh Barbati llvm-svn: 145698
* Windows support by Ruben Van Boxem.Howard Hinnant2011-10-171-0/+2
| | | | llvm-svn: 142235
* _STD -> _VSTD to avoid macro clash on windowsHoward Hinnant2011-06-301-4/+4
| | | | llvm-svn: 134190
* Effort to reduce the number of exported symbolsHoward Hinnant2010-12-171-17/+31
| | | | llvm-svn: 122057
* license changeHoward Hinnant2010-11-161-2/+2
| | | | llvm-svn: 119395
* visibility-decoration.Howard Hinnant2010-09-221-7/+13
| | | | llvm-svn: 114545
* Changed __config to react to all of clang's currently documented has_feature ↵Howard Hinnant2010-09-041-1/+1
| | | | | | flags, and renamed _LIBCPP_MOVE to _LIBCPP_HAS_NO_RVALUE_REFERENCES to be more consistent with the rest of the libc++'s flags, and with clang's nomenclature. llvm-svn: 113086
* Fixing whitespace problemsHoward Hinnant2010-08-221-9/+9
| | | | llvm-svn: 111750
* Wiped out some non-ascii characters that snuck into the copyright.Howard Hinnant2010-05-111-1/+1
| | | | llvm-svn: 103516
* libcxx initial importHoward Hinnant2010-05-111-0/+965
llvm-svn: 103490
OpenPOWER on IntegriCloud