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.
rdar://problem/18168350
Paths
| Differential D48912
[libc++] Add deprecated attributes to many deprecated components ClosedPublic Authored by ldionne on Jul 3 2018, 6:51 PM.
Details Summary This is a first step in the right direction, but I wasn't able to get an rdar://problem/18168350
Diff Detail
Event TimelineHerald added subscribers: llvm-commits, dexonsmith, christof. · View Herald TranscriptJul 3 2018, 6:51 PM Comment Actions We'll also want tests that very the deprecated diagnostics are emitted correctly. To test for the production of diagnostics, Libc++ uses *.fail.cpp tests along with Clang Verify.
Comment Actions Like the "don't discard return values" patch that is currently under review (D45179), this needs to be opt-in - otherwise people will complain (loudly). Comment Actions So if someone defines (say) _LIBCXX_DEPRECATION_WARNINGS in their build flags, they get the warnings. Otherwise, not. ldionne added inline comments.
ldionne marked 4 inline comments as done. Comment ActionsAddressed reviewer feedback.
Comment Actions
I'm not sure this is a good/correct example. Comment Actions FWIW, I would prefer to enable deprecation warnings by default and to have a way of turning them off -- so as to be as close to the standard as possible by default. But I'm fine either way, and this is always a choice we can revisit later by just switching the default from opt-in to opt-out.
Comment Actions
I have a strong preference for this as well.
I think that silencing deprecation warnings by default does users a disservice. Comment Actions Regarding whether we want to enable or disable those warnings by default: it seems like we've reached consensus (on the LLVM IRC) for enabling the deprecation warnings by default. However, I suggest we keep them disabled by default in this commit, and then change the default in a subsequent change. This will make things easier from an integration perspective, and also in case we need to roll back the defaults because of some unforeseen circumstances.
Comment Actions
This approach sounds fine to me. Comment Actions Made sure the attributes worked properly on GCC. This still requires using attribute((deprecated)) whenever that's Comment Actions In general this lgtm. First comment I think you need to fix, others can go together in a follow-up I think.
Comment Actions I still think this is good to go as-is, given my answer to JF's comments.
Closed by commit rCXX342843: [libc++] Add deprecated attributes to many deprecated components (authored by ldionne). · Explain Why This revision was automatically updated to reflect the committed changes.
Revision Contents
Diff 154040 libcxx/include/__config
libcxx/include/__functional_base
libcxx/include/algorithm
libcxx/include/functional
libcxx/include/memory
libcxx/include/utility
libcxx/test/libcxx/algorithms/alg.modifying.operations/alg.random.shuffle/random_shuffle.cxx1z.pass.cpp
libcxx/test/libcxx/depr/depr.auto.ptr/auto.ptr/auto_ptr.cxx1z.pass.cpp
libcxx/test/libcxx/depr/depr.function.objects/depr.adaptors.cxx1z.pass.cpp
libcxx/test/std/algorithms/alg.modifying.operations/alg.random.shuffle/random_shuffle.pass.cpp
libcxx/test/std/algorithms/alg.modifying.operations/alg.random.shuffle/random_shuffle_rand.pass.cpp
libcxx/test/std/algorithms/alg.modifying.operations/alg.random.shuffle/random_shuffle_urng.pass.cpp
libcxx/test/std/depr/depr.auto.ptr/auto.ptr/auto.ptr.cons/assignment.fail.cpp
libcxx/test/std/depr/depr.auto.ptr/auto.ptr/auto.ptr.cons/assignment.pass.cpp
libcxx/test/std/depr/depr.auto.ptr/auto.ptr/auto.ptr.cons/convert.fail.cpp
libcxx/test/std/depr/depr.auto.ptr/auto.ptr/auto.ptr.cons/convert.pass.cpp
libcxx/test/std/depr/depr.auto.ptr/auto.ptr/auto.ptr.cons/convert_assignment.fail.cpp
libcxx/test/std/depr/depr.auto.ptr/auto.ptr/auto.ptr.cons/convert_assignment.pass.cpp
libcxx/test/std/depr/depr.auto.ptr/auto.ptr/auto.ptr.cons/copy.fail.cpp
libcxx/test/std/depr/depr.auto.ptr/auto.ptr/auto.ptr.cons/copy.pass.cpp
libcxx/test/std/depr/depr.auto.ptr/auto.ptr/auto.ptr.cons/explicit.fail.cpp
libcxx/test/std/depr/depr.auto.ptr/auto.ptr/auto.ptr.cons/pointer.pass.cpp
libcxx/test/std/depr/depr.auto.ptr/auto.ptr/auto.ptr.conv/assign_from_auto_ptr_ref.pass.cpp
libcxx/test/std/depr/depr.auto.ptr/auto.ptr/auto.ptr.conv/convert_from_auto_ptr_ref.pass.cpp
libcxx/test/std/depr/depr.auto.ptr/auto.ptr/auto.ptr.conv/convert_to_auto_ptr.pass.cpp
libcxx/test/std/depr/depr.auto.ptr/auto.ptr/auto.ptr.conv/convert_to_auto_ptr_ref.pass.cpp
libcxx/test/std/depr/depr.auto.ptr/auto.ptr/auto.ptr.members/arrow.pass.cpp
libcxx/test/std/depr/depr.auto.ptr/auto.ptr/auto.ptr.members/deref.pass.cpp
libcxx/test/std/depr/depr.auto.ptr/auto.ptr/auto.ptr.members/release.pass.cpp
libcxx/test/std/depr/depr.auto.ptr/auto.ptr/auto.ptr.members/reset.pass.cpp
libcxx/test/std/depr/depr.auto.ptr/auto.ptr/element_type.pass.cpp
libcxx/test/std/utilities/function.objects/negators/binary_negate.pass.cpp
libcxx/test/std/utilities/function.objects/negators/not1.pass.cpp
libcxx/test/std/utilities/function.objects/negators/not2.pass.cpp
libcxx/test/std/utilities/function.objects/negators/unary_negate.pass.cpp
|
Why are we switching the attribute from its C++11 form?
I suspect this will break MSVC builds, or other compilers that don't provide GNU attributes.