This revision was automatically updated to reflect the committed changes.
Closed by commit rL304357: [Libc++] Use #pragma push_macro/pop_macro to better
handle min/max on Windows (authored by EricWF).
Changed prior to commit:
https://reviews.llvm.org/D33080?vs=100361=100925#toc
Repository:
EricWF accepted this revision.
EricWF added a comment.
LGTM.
https://reviews.llvm.org/D33080
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
EricWF updated this revision to Diff 100361.
EricWF added a comment.
- Fix whitespace in `__config`.
@compnerd Any final thoughts?
https://reviews.llvm.org/D33080
Files:
include/__bit_reference
include/__config
include/__hash_table
include/__mutex_base
include/__split_buffer
EricWF updated this revision to Diff 100269.
EricWF added a comment.
- Remove the external include guards for `__undef_macros` as requested by
@compnerd.
I couldn't come up with a easy test case that showed any notable difference
having the external guards.
https://reviews.llvm.org/D33080
EricWF added a comment.
In https://reviews.llvm.org/D33080#754442, @compnerd wrote:
> I think that we should sink the `min`/`max` checks into `__undef_macros`. I
> don't like the idea of littering that check everywhere.
I would much rather litter at the cost of the implementation than
compnerd requested changes to this revision.
compnerd added a comment.
This revision now requires changes to proceed.
I think that we should sink the `min`/`max` checks into `__undef_macros`. I
don't like the idea of littering that check everywhere.
Comment at:
bcraig added a comment.
> I noticed that the Windows STL headers have to do this dance with `new` (even
> though they do `(foo)(...)` for `min` and `max`). If we're going to need
> to guard against a bunch of macros I would like to use a single approach.
> Other than updating the `#if
EricWF updated this revision to Diff 98725.
EricWF added a comment.
- Fix missing `_LIBCPP_POP_MACROS` in `<__threading_support>`.
- Add test that each header is unaffected by `min` and `max` macros and that
the macros themselves are unaffected.
https://reviews.llvm.org/D33080
Files:
EricWF added a comment.
In https://reviews.llvm.org/D33080#752202, @bcraig wrote:
> I like the warning that you generate for min and max macros existing.
Only on warn on platforms where we don't have `#pragma push_macro/pop_macro`.
> Is the push_macro / pop_macro the right way to go though?
bcraig added a comment.
I like the warning that you generate for min and max macros existing. Is the
push_macro / pop_macro the right way to go though? You could throw extra
parenthesis around the declaration and usages of min/max to avoid macro
expansion.
#define add(x,y) (x)-(y)
EricWF added inline comments.
Comment at: include/__threading_support:632
#endif // _LIBCPP_HAS_THREAD_API_PTHREAD
#endif // !_LIBCPP_HAS_THREAD_LIBRARY_EXTERNAL ||
_LIBCPP_BUILDING_THREAD_LIBRARY_EXTERNAL
Missing _LIBCPP_POP_MACROS
EricWF updated this revision to Diff 98562.
EricWF added a comment.
- Fix unterminated preprocessor directive.
https://reviews.llvm.org/D33080
Files:
include/__bit_reference
include/__config
include/__hash_table
include/__mutex_base
include/__split_buffer
include/__std_stream
EricWF updated this revision to Diff 98561.
EricWF added a comment.
- Remove failing test. This patch cannot be easily tested because the system's
libc might also mess with the definitions of `min` and `max`.
https://reviews.llvm.org/D33080
Files:
include/__bit_reference
include/__config
EricWF created this revision.
Herald added a subscriber: krytarowski.
This patch improves how libc++ handles min/max macros within the headers.
Previously libc++ would undef them and emit a warning.
This patch changes libc++ to use `#pragma push_macro` to save the macro before
undefining it,
14 matches
Mail list logo
