[PATCH] D39719: [X86][AVX512] lowering kunpack intrinsic - clang part
jina.nahias added inline comments.
Comment at: test/CodeGen/avx512f-builtins.c:6231
+ // CHECK: bitcast <16 x i1> %{{.*}} to i16
+ // CHECK: and i32 %{{.*}}, 255
+ // CHECK: shl i32 %{{.*}}, 8
craig.topper wrote:
> Does this really produce kunpackb in the backend? The type promotion here
> makes me skeptic
yes,
the code we get:
vpcmpneqd %zmm1, %zmm0, %k0
vpcmpneqd %zmm3, %zmm2, %k1
kunpckbw%k1, %k0, %k1
vpcmpneqd %zmm5, %zmm4, %k0 {%k1}
kmovd %k0, %eax
# kill: %AX %AX %EAX
vzeroupper
https://reviews.llvm.org/D39719
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[libcxx] r318012 - Put the status in the wrong column
Author: marshall Date: Sun Nov 12 20:15:39 2017 New Revision: 318012 URL: http://llvm.org/viewvc/llvm-project?rev=318012&view=rev Log: Put the status in the wrong column Modified: libcxx/trunk/www/cxx2a_status.html Modified: libcxx/trunk/www/cxx2a_status.html URL: http://llvm.org/viewvc/llvm-project/libcxx/trunk/www/cxx2a_status.html?rev=318012&r1=318011&r2=318012&view=diff == --- libcxx/trunk/www/cxx2a_status.html (original) +++ libcxx/trunk/www/cxx2a_status.html Sun Nov 12 20:15:39 2017 @@ -64,7 +64,7 @@ https://wg21.link/P0415R1";>P0415R1LWGConstexpr for std::complexAlbuquerque https://wg21.link/P0439R0";>P0439R0LWGMake std::memory_order a scoped enumerationAlbuquerque https://wg21.link/P0457R2";>P0457R2LWGString Prefix and Suffix CheckingAlbuquerque - https://wg21.link/P0550R2";>P0550R2LWGTransformation Trait remove_cvrefAlbuquerqueComplete + https://wg21.link/P0550R2";>P0550R2LWGTransformation Trait remove_cvrefAlbuquerqueComplete6.0 https://wg21.link/P0600R1";>P0600R1LWGnodiscard in the LibraryAlbuquerque https://wg21.link/P0616R0";>P0616R0LWGde-pessimize legacy algorithms with std::moveAlbuquerque https://wg21.link/P0653R2";>P0653R2LWGUtility to convert a pointer to a raw pointerAlbuquerque ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[libcxx] r318011 - Implement P0550R2: Transformation Trait remove_cvref
Author: marshall
Date: Sun Nov 12 19:59:22 2017
New Revision: 318011
URL: http://llvm.org/viewvc/llvm-project?rev=318011&view=rev
Log:
Implement P0550R2: Transformation Trait remove_cvref
Added:
libcxx/trunk/test/std/utilities/meta/meta.trans/meta.trans.other/remove_cvref.pass.cpp
Modified:
libcxx/trunk/include/type_traits
libcxx/trunk/www/cxx2a_status.html
Modified: libcxx/trunk/include/type_traits
URL:
http://llvm.org/viewvc/llvm-project/libcxx/trunk/include/type_traits?rev=318011&r1=318010&r2=318011&view=diff
==
--- libcxx/trunk/include/type_traits (original)
+++ libcxx/trunk/include/type_traits Sun Nov 12 19:59:22 2017
@@ -150,6 +150,7 @@ namespace std
template
struct aligned_storage;
template struct aligned_union;
+template struct remove_cvref; // C++20
template struct decay;
template struct common_type;
@@ -203,6 +204,8 @@ namespace std
template
using aligned_union_t = typename aligned_union::type;
// C++14
template
+ using remove_cvref_t= typename remove_cvref::type; // C++20
+template
using decay_t = typename decay::type; // C++14
template
using enable_if_t = typename enable_if::type; // C++14
@@ -1141,6 +1144,17 @@ template
struct __is_same_uncvref : is_same::type,
typename __uncvref<_Up>::type> {};
+#if _LIBCPP_STD_VER > 17
+// aligned_union - same as __uncvref
+template
+struct remove_cvref {
+using type = remove_cv_t>;
+};
+
+template using remove_cvref_t = typename remove_cvref<_Tp>::type;
+#endif
+
+
struct __any
{
__any(...);
Added:
libcxx/trunk/test/std/utilities/meta/meta.trans/meta.trans.other/remove_cvref.pass.cpp
URL:
http://llvm.org/viewvc/llvm-project/libcxx/trunk/test/std/utilities/meta/meta.trans/meta.trans.other/remove_cvref.pass.cpp?rev=318011&view=auto
==
---
libcxx/trunk/test/std/utilities/meta/meta.trans/meta.trans.other/remove_cvref.pass.cpp
(added)
+++
libcxx/trunk/test/std/utilities/meta/meta.trans/meta.trans.other/remove_cvref.pass.cpp
Sun Nov 12 19:59:22 2017
@@ -0,0 +1,52 @@
+//===--===//
+//
+// The LLVM Compiler Infrastructure
+//
+// This file is dual licensed under the MIT and the University of Illinois Open
+// Source Licenses. See LICENSE.TXT for details.
+//
+//===--===//
+
+// UNSUPPORTED: c++98, c++03, c++11, c++14, c++17
+
+// type_traits
+
+// remove_cvref
+
+#include
+
+#include "test_macros.h"
+
+template
+void test_remove_cvref()
+{
+static_assert((std::is_same::type,
U>::value), "");
+static_assert((std::is_same< std::remove_cvref_t,
U>::value), "");
+}
+
+int main()
+{
+test_remove_cvref();
+test_remove_cvref();
+test_remove_cvref();
+test_remove_cvref();
+test_remove_cvref();
+
+// Doesn't decay
+test_remove_cvref();
+test_remove_cvref();
+test_remove_cvref();
+test_remove_cvref();
+test_remove_cvref();
+
+test_remove_cvref();
+test_remove_cvref();
+test_remove_cvref();
+test_remove_cvref();
+
+test_remove_cvref();
+test_remove_cvref();
+test_remove_cvref();
+test_remove_cvref();
+test_remove_cvref();
+}
Modified: libcxx/trunk/www/cxx2a_status.html
URL:
http://llvm.org/viewvc/llvm-project/libcxx/trunk/www/cxx2a_status.html?rev=318011&r1=318010&r2=318011&view=diff
==
--- libcxx/trunk/www/cxx2a_status.html (original)
+++ libcxx/trunk/www/cxx2a_status.html Sun Nov 12 19:59:22 2017
@@ -64,7 +64,7 @@
https://wg21.link/P0415R1";>P0415R1LWGConstexpr for
std::complexAlbuquerque
https://wg21.link/P0439R0";>P0439R0LWGMake
std::memory_order a scoped
enumerationAlbuquerque
https://wg21.link/P0457R2";>P0457R2LWGString Prefix
and Suffix CheckingAlbuquerque
- https://wg21.link/P0550R2";>P0550R2LWGTransformation
Trait remove_cvrefAlbuquerque
+ https://wg21.link/P0550R2";>P0550R2LWGTransformation
Trait
remove_cvrefAlbuquerqueComplete
https://wg21.link/P0600R1";>P0600R1LWGnodiscard in
the LibraryAlbuquerque
https://wg21.link/P0616R0";>P0616R0LWGde-pessimize
legacy algorithms with
std::moveAlbuquerque
https://wg21.link/P0653R2";>P0653R2LWGUtility to
convert a pointer to a raw
pointerAlbuquerque
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D39947: [OpenMP] Stable sort Privates to remove non-deterministic ordering
mgrang added a comment. In https://reviews.llvm.org/D39947#922889, @rjmccall wrote: > In https://reviews.llvm.org/D39947#922870, @mgrang wrote: > > > Although this patches fixes the above unit test failures, the generated > > code is very different from the one that the tests expect. As a result, > > these tests need to be adjusted. Could the reviewers please comment/suggest > > on whether it is ok to fix the tests as a result of this change? > > > > The other way of obtaining deterministic ordering for privates with the > > same alignment is to use an index for each item inserted into Privates and > > use it as a tie-breaker. But even in that case the generated code is quite > > different and tests still need to be adjusted. > > > Fixing the tests may be acceptable. Can you give an example of the > difference between the old and new test outputs? Please see https://www.diffchecker.com/7V2XFbk4 for the difference in output for the following test before and after my change: clang -cc1 -internal-isystem /build/llvm/lib/clang/6.0.0/include -nostdsysteminc -verify -fopenmp -x c++ -triple x86_64-apple-darwin10 -emit-llvm /src/llvm/tools/clang/test/OpenMP/task_firstprivate_codegen.cpp -o - https://reviews.llvm.org/D39947 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D38892: Bugfix #34804 A universal catch should be able to deal with a passthrough throw.
sgolemon added a comment. Fixed in parallel by https://reviews.llvm.org/D39013 https://reviews.llvm.org/D38892 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D39455: [CodeGen] Add initial support for union members in TBAA
rjmccall added a comment. I think the implementation looks fine. The metadata design also sounds good to me, but I'd like Hal to weigh in before you commit. Repository: rL LLVM https://reviews.llvm.org/D39455 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D39462: [Sema] Implement -Wmaybe-tautological-constant-compare for when the tautologicalness is data model dependent
rjmccall added a comment. That's the template type-propagation problem: the template was invoked with a size_t, but that's erased down to the canonical type by the template machinery. That can't be fixed within the template, but at use sites, we could theoretically recognize that e.g. the result of the callee was originally spelled T and then look for how T was determined; here it comes from an explicit template argument, whose spelling can just be propagated into the sugared type of the call expression. But that's the sort of analysis I think you'd need to do a good job with in order to make this adjustment successful. Repository: rL LLVM https://reviews.llvm.org/D39462 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D39462: [Sema] Implement -Wmaybe-tautological-constant-compare for when the tautologicalness is data model dependent
lebedev.ri added a comment.
In https://reviews.llvm.org/D39462#922847, @rjmccall wrote:
> In https://reviews.llvm.org/D39462#922844, @lebedev.ri wrote:
>
> > In https://reviews.llvm.org/D39462#922826, @rjmccall wrote:
> >
> > > I don't speak for the entire project, but I'm not sure I'm interested in
> > > the diagnostic you're actually offering to contribute here. It may
> > > produce a warning on your specific test case, but I think it's really
> > > much too rigid and will lead to massive false positives. I sketched the
> > > basics of a design that I think I could accept; if you don't want to
> > > implement it, that's your right, but that doesn't make me more likely to
> > > accept what you're willing to implement.
> >
> >
> > Just to reiterate that we are talking about the same thing here:
> >
> > - https://reviews.llvm.org/D38101 is already merged.
> > `-Wtautological-constant-compare` is here.
> > - There are cases when it warns for some target platform, but not the
> > other, as complained in https://reviews.llvm.org/D39149, and post-review
> > mails for https://reviews.llvm.org/D38101
> > - So far it seems all the cases reduce to ``` #include #include
> > int main() { using T1 = long; using T2 = int;
> >
> > T1 r; if (r < std::numeric_limits::min()) {} if (r >
> > std::numeric_limits::max()) {} } ```
> > - *This* differential (https://reviews.llvm.org/D39462) would find such
> > cases, and issue them under different diagnostic, thus reducing the
> > "false-positive" (it is an open question whether they are actual
> > false-positives or not) rate of `-Wtautological-constant-compare`.
>
>
> I think you might have this backwards.
The views here are clearly polarized.
> We think of the check for the diagnostic as being the test, so a false
> positive is when we warn when we shouldn't.
Yes.
> What you've identified here is a false *negative*, i.e. a case where you
> believe it should warn (because it would warn on a different target) that it
> currently does not.
I'm sorry, but where are you getting this from? I don't believe these warnings
should be elevated to always warn even if it is not tautological for the
current target platform. I don't think i have said that?
>> Are you suggesting me to drop this, and implement some other huge new
>> diagnostic that may catch such cases before
>> `-Wtautological-constant-compare`, thus preventing
>> `-Wtautological-constant-compare` from triggering on that completely?
>
> "This warning triggers on some targets and not on others" is a far more
> widespread problem than just -Wtautological-constant-compare. I don't think
> your patch reasonably solves that problem, even for just this diagnostic. I
> think a "strong typedef" analysis would address it, but that's going to
> require a significant amount of work, even if you literally only apply it to
> this warning, because you're going to have to implement a bunch of more
> careful logic about inferring when to propagate typedefs through e.g.
> templates, as well as when to consider a template to have "propagated"
> through arithmetic promotion in the same way we propagate integer ranges.
First and foremost, i do admit that i don't have the full picture in mind.
If other reviewers agree with Your view, i will abandon this differential.
Hopefully someone with clearer understanding will come up with a better
solution.
In https://reviews.llvm.org/D39462#922887, @rjmccall wrote:
> I see. The problem now, though, is that things involving, say, a size_t and
> a numeric_limits will never warn.
The same type (`size_t`) will be on the both sides, so i think it should still
warn. (I do see that the test disagrees with me.)
Repository:
rL LLVM
https://reviews.llvm.org/D39462
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D39430: [clangd] formatting: don't ignore style
rwols marked 4 inline comments as done.
rwols added a comment.
Is this ready to merge? I'd like to implement tests in another differential,
I'm having trouble referencing a temp dir from `lit` in a JSON request to
clangd.
Comment at: clangd/ClangdServer.cpp:429
+ auto TaggedFS = FSProvider.getTaggedFileSystem(File);
+ auto StyleOrError =
+ format::getStyle("file", File, "LLVM", Code, TaggedFS.Value.get());
sammccall wrote:
> getStyle is going to stat several files, in the usual case.
> This seems less than ideal, particularly when we're doing format-on-type.
> Filesystems are not always fast/cheap.
>
> We should really cache this, and I think "when the file is opened" is a
> reasonable tradeoff between simplicity and producing sensible user-facing
> behavior.
>
> Unfortunately I'm not sure there's a sensible place to do things at present:
> addDocument() is fast and doing blocking IO there might be bad. Doing it
> asynchronously also seems bad (what happens if style's not ready?)
>
> Next best thing would be "first format request when the file is opened". If
> you feel like doing that here (only computing the style if it's not already
> known for this file), then feel free, but a **FIXME** is fine too.
>
> (FWIW, Google has a slow FS that's important to us, but we disable
> .clang-format scanning on that FS in other ways because it only holds code in
> one style. Other users might care about this, though)
> but a FIXME is fine too.
I've added a FIXME note. I think implementing a caching strategy is worthy of
its own differential revision.
https://reviews.llvm.org/D39430
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D39430: [clangd] formatting: don't ignore style
rwols updated this revision to Diff 122606.
rwols added a comment.
- Merge with upstream, fix merge conflicts
- Add a FIXME for a caching strategy for .clang-format files
https://reviews.llvm.org/D39430
Files:
clangd/ClangdLSPServer.cpp
clangd/ClangdServer.cpp
clangd/ClangdServer.h
clangd/JSONRPCDispatcher.cpp
clangd/JSONRPCDispatcher.h
Index: clangd/JSONRPCDispatcher.h
===
--- clangd/JSONRPCDispatcher.h
+++ clangd/JSONRPCDispatcher.h
@@ -16,6 +16,7 @@
#include "clang/Basic/LLVM.h"
#include "llvm/ADT/SmallString.h"
#include "llvm/ADT/StringMap.h"
+#include "llvm/Support/Error.h"
#include "llvm/Support/YAMLParser.h"
#include
#include
@@ -58,11 +59,13 @@
RequestContext(JSONOutput &Out, llvm::Optional ID)
: Out(Out), ID(std::move(ID)) {}
- /// Sends a successful reply.
+ /// Send a response to a request from the client.
void reply(json::Expr &&Result);
- /// Sends an error response to the client, and logs it.
+ /// Send an error response to the client, and logs it.
void replyError(ErrorCode code, const llvm::StringRef &Message);
- /// Sends a request to the client.
+ /// Send all error messages contained in Err to the client, and log them.
+ void replyError(llvm::Error Err);
+ /// Send a request to the client.
void call(llvm::StringRef Method, json::Expr &&Params);
private:
Index: clangd/JSONRPCDispatcher.cpp
===
--- clangd/JSONRPCDispatcher.cpp
+++ clangd/JSONRPCDispatcher.cpp
@@ -59,24 +59,28 @@
Out.log("Attempted to reply to a notification!\n");
return;
}
- Out.writeMessage(json::obj{
- {"jsonrpc", "2.0"},
- {"id", *ID},
- {"result", std::move(Result)},
- });
+ Out.writeMessage(
+ json::obj{{"jsonrpc", "2.0"}, {"id", *ID}, {"result", Result}});
}
-void RequestContext::replyError(ErrorCode code, const llvm::StringRef &Message) {
+void RequestContext::replyError(ErrorCode code,
+const llvm::StringRef &Message) {
Out.log("Error " + Twine(static_cast(code)) + ": " + Message + "\n");
if (ID) {
Out.writeMessage(json::obj{
{"jsonrpc", "2.0"},
{"id", *ID},
-{"error", json::obj{{"code", static_cast(code)}, {"message", Message}}},
+{"error",
+ json::obj{{"code", static_cast(code)}, {"message", Message}}},
});
}
}
+void RequestContext::replyError(llvm::Error Err) {
+ const auto Message = llvm::toString(std::move(Err));
+ replyError(ErrorCode::UnknownErrorCode, Message);
+}
+
void RequestContext::call(StringRef Method, json::Expr &&Params) {
// FIXME: Generate/Increment IDs for every request so that we can get proper
// replies once we need to.
Index: clangd/ClangdServer.h
===
--- clangd/ClangdServer.h
+++ clangd/ClangdServer.h
@@ -284,12 +284,18 @@
/// given a header file and vice versa.
llvm::Optional switchSourceHeader(PathRef Path);
- /// Run formatting for \p Rng inside \p File.
- std::vector formatRange(PathRef File, Range Rng);
- /// Run formatting for the whole \p File.
- std::vector formatFile(PathRef File);
- /// Run formatting after a character was typed at \p Pos in \p File.
- std::vector formatOnType(PathRef File, Position Pos);
+ /// Run formatting for \p Rng inside \p File with content \p Code.
+ llvm::Expected>
+ formatRange(llvm::StringRef Code, PathRef File, Range Rng);
+
+ /// Run formatting for the whole \p File with content \p Code.
+ llvm::Expected>
+ formatFile(llvm::StringRef Code, PathRef File);
+
+ /// Run formatting after a character was typed at \p Pos in \p File with
+ /// content \p Code.
+ llvm::Expected>
+ formatOnType(llvm::StringRef Code, PathRef File, Position Pos);
/// Gets current document contents for \p File. \p File must point to a
/// currently tracked file.
@@ -305,6 +311,12 @@
void onFileEvent(const DidChangeWatchedFilesParams &Params);
private:
+ /// FIXME: This stats several files to find a .clang-format file. I/O can be
+ /// slow. Think of a way to cache this.
+ llvm::Expected>
+ formatCode(llvm::StringRef Code, PathRef File,
+ ArrayRef Ranges);
+
std::future
scheduleReparseAndDiags(PathRef File, VersionedDraft Contents,
std::shared_ptr Resources,
Index: clangd/ClangdServer.cpp
===
--- clangd/ClangdServer.cpp
+++ clangd/ClangdServer.cpp
@@ -36,16 +36,6 @@
std::promise &Promise;
};
-std::vector formatCode(StringRef Code, StringRef Filename,
- ArrayRef Ranges) {
- // Call clang-format.
- // FIXME: Don't ignore style.
- format::FormatStyle Style = format::getLLVMStyle();
- auto Result = format::reformat(Style, Code, Ranges, Filename);
-
- return std::vector(Result.begin(), Result.end());
-
[PATCH] D39947: [OpenMP] Stable sort Privates to remove non-deterministic ordering
rjmccall added a comment. In https://reviews.llvm.org/D39947#922870, @mgrang wrote: > Although this patches fixes the above unit test failures, the generated code > is very different from the one that the tests expect. As a result, these > tests need to be adjusted. Could the reviewers please comment/suggest on > whether it is ok to fix the tests as a result of this change? > > The other way of obtaining deterministic ordering for privates with the same > alignment is to use an index for each item inserted into Privates and use it > as a tie-breaker. But even in that case the generated code is quite different > and tests still need to be adjusted. Fixing the tests may be acceptable. Can you give an example of the difference between the old and new test outputs? https://reviews.llvm.org/D39947 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D39462: [Sema] Implement -Wmaybe-tautological-constant-compare for when the tautologicalness is data model dependent
rjmccall added a comment. I see. The problem now, though, is that things involving, say, a size_t and a numeric_limits will never warn. Repository: rL LLVM https://reviews.llvm.org/D39462 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D39948: Make isDefinition matcher support ObjCMethodDecl
kastiglione created this revision.
Herald added a subscriber: klimek.
Allow the `isDefinition()` matcher to apply to `ObjCMethodDecl` nodes, in
addition to those it already supports. For whatever reason, `ObjCMethodDecl`
does not inherit from `FunctionDecl` and so this is specialization is necessary.
https://reviews.llvm.org/D39948
Files:
docs/LibASTMatchersReference.html
include/clang/ASTMatchers/ASTMatchers.h
unittests/ASTMatchers/ASTMatchersNarrowingTest.cpp
Index: unittests/ASTMatchers/ASTMatchersNarrowingTest.cpp
===
--- unittests/ASTMatchers/ASTMatchersNarrowingTest.cpp
+++ unittests/ASTMatchers/ASTMatchersNarrowingTest.cpp
@@ -1315,6 +1315,14 @@
cxxMethodDecl(hasName("a"), isDefinition());
EXPECT_TRUE(matches("class A { void a() {} };", DefinitionOfMethodA));
EXPECT_TRUE(notMatches("class A { void a(); };", DefinitionOfMethodA));
+
+ DeclarationMatcher DefinitionOfObjCMethodA =
+objcMethodDecl(hasName("a"), isDefinition());
+ EXPECT_TRUE(matchesObjC("@interface A @end "
+ "@implementation A; -(void)a {} @end",
+ DefinitionOfObjCMethodA));
+ EXPECT_TRUE(notMatchesObjC("@interface A; - (void)a; @end",
+ DefinitionOfObjCMethodA));
}
TEST(Matcher, HandlesNullQualTypes) {
Index: include/clang/ASTMatchers/ASTMatchers.h
===
--- include/clang/ASTMatchers/ASTMatchers.h
+++ include/clang/ASTMatchers/ASTMatchers.h
@@ -4201,11 +4201,18 @@
/// extern int vb; // Doesn't match, as it doesn't define the variable.
/// void fa() {}
/// void fb(); // Doesn't match, as it has no body.
+/// @interface X
+/// - (void)ma; // Doesn't match, interface is declaration.
+/// @end
+/// @implementation X
+/// - (void)ma {}
+/// @end
/// \endcode
///
/// Usable as: Matcher, Matcher, Matcher
AST_POLYMORPHIC_MATCHER(isDefinition,
AST_POLYMORPHIC_SUPPORTED_TYPES(TagDecl, VarDecl,
+ObjCMethodDecl,
FunctionDecl)) {
return Node.isThisDeclarationADefinition();
}
Index: docs/LibASTMatchersReference.html
===
--- docs/LibASTMatchersReference.html
+++ docs/LibASTMatchersReference.html
@@ -2746,16 +2746,22 @@
-MatcherFunctionDecl>isDefinition
-Matches if a declaration has a body attached.
+MatcherFunctionDecl>isDefinition
+Matches if a declaration has a body attached.
Example matches A, va, fa
class A {};
class B; Doesn't match, as it has no body.
int va;
extern int vb; Doesn't match, as it doesn't define the variable.
void fa() {}
void fb(); Doesn't match, as it has no body.
+ @interface X
+ - (void)ma; Doesn't match, interface is declaration.
+ @end
+ @implementation X
+ - (void)ma {}
+ @end
Usable as: MatcherTagDecl>, MatcherVarDecl>, MatcherFunctionDecl>
@@ -3154,6 +3160,27 @@
+MatcherObjCMethodDecl>isDefinition
+Matches if a declaration has a body attached.
+
+Example matches A, va, fa
+ class A {};
+ class B; Doesn't match, as it has no body.
+ int va;
+ extern int vb; Doesn't match, as it doesn't define the variable.
+ void fa() {}
+ void fb(); Doesn't match, as it has no body.
+ @interface X
+ - (void)ma; Doesn't match, interface is declaration.
+ @end
+ @implementation X
+ - (void)ma {}
+ @end
+
+Usable as: MatcherTagDecl>, MatcherVarDecl>, MatcherFunctionDecl>
+
+
+
MatcherQualType>asStringstd::string Name
Matches if the matched type is represented by the given string.
@@ -3433,6 +3460,12 @@
extern int vb; Doesn't match, as it doesn't define the variable.
void fa() {}
void fb(); Doesn't match, as it has no body.
+ @interface X
+ - (void)ma; Doesn't match, interface is declaration.
+ @end
+ @implementation X
+ - (void)ma {}
+ @end
Usable as: MatcherTagDecl>, MatcherVarDecl>, MatcherFunctionDecl>
@@ -3696,6 +3729,12 @@
extern int vb; Doesn't match, as it doesn't define the variable.
[PATCH] D39622: Fix type debug information generation for enum-based template specialization
xgsa added a comment. In https://reviews.llvm.org/D39622#919579, @aprantl wrote: > For clarification: what is the "symbols table" you are referring to in the > description? I meant the data dumped with "nm -an ./test". By the way, I haven't abandoned the patch, I have found one more case when my fix doesn't work and I am working on improvement. Nevertheless, it would be helpful to get answers to the questions in this review (about changing the "Indentation" field and about the test). Repository: rL LLVM https://reviews.llvm.org/D39622 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: [PATCH] Ensure std::getline always 0-terminates string.
On Thu, Nov 09, 2017 at 05:37:32PM -0800, Volodymyr Sapsai wrote:
> On Nov 9, 2017, at 12:13, Reimar Döffinger wrote:
> >
> > Hello!
> >
> > On Wed, Nov 08, 2017 at 12:36:00PM -0800, Volodymyr Sapsai wrote:
> >> Thanks for the patch, Reimar. Can you please add tests to ensure this
> >> functionality doesn’t regress? As null character is required by the
> >> standard (27.7.2.3p21), a good starting point seems to be
> >> test/std/input.output/iostream.format/input.streams/istream.unformatted/getline_pointer_size.pass.cpp
> >> test/std/input.output/iostream.format/input.streams/istream.unformatted/getline_pointer_size_chart.pass.cpp
> >
> > New patch attached, though I went the lazy way of just adding one case.
> > Not sure that's "good enough" - in principle I think it should be.
> I think it makes sense to cover wchar_t as well. And I think it would be
> useful to test the case with specified delimiter too. Most likely
> implementation should be reused for the case with explicit delimiter and
> default new line delimiter. But I prefer not to rely on this assumption and
> test explicitly.
Well, it was rather trivial to do anyway, so done.
> > More tricky would be to add a test for the _LIBCPP_NO_EXCEPTIONS case,
> > is there any code testing that at all?
> According to tests, exceptions are tested in various ways. Let me find how to
> configure the build to run tests in these modes.
There aren't many references to that mode, and I am not sure
running in a separate mode would make for a good test anyway.
Maybe not how it should done, but for now I added a separate file
that just defines _LIBCPP_NO_EXCEPTIONS before the includes.
>From abfb27562be9bf2838c3357403d1d23297e63f8c Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Reimar=20D=C3=B6ffinger?=
Date: Thu, 7 Sep 2017 08:42:10 +0200
Subject: [PATCH] Ensure std::istream::getline always 0-terminates string.
If the sentinel failed (e.g. due to having reached
EOF before) or an exception was caught it failed to
do that.
The C++14 standard says:
"In any case, if n is greater than zero, it then stores
a null character (using charT()) into the next
successive location of the array."
Other implementations like libstdc++ do 0-terminate and
not doing so may lead security issues in applications.
Note that means behaviour is inconsistent with the
std::getline version returning a std::string, which
does not modify the string in case of error, but
that is both less serious and matches behaviour
of e.g. libstdc++, so leave it as-is for now.
---
include/istream| 6 ++-
.../getline_pointer_size.pass.cpp | 14 ++
.../getline_pointer_size_chart.pass.cpp| 14 ++
.../getline_pointer_size_exception.pass.cpp| 52 ++
4 files changed, 84 insertions(+), 2 deletions(-)
create mode 100644 test/std/input.output/iostream.format/input.streams/istream.unformatted/getline_pointer_size_exception.pass.cpp
diff --git a/include/istream b/include/istream
index 0b8e05d95..5c73df38f 100644
--- a/include/istream
+++ b/include/istream
@@ -1069,16 +1069,18 @@ basic_istream<_CharT, _Traits>::getline(char_type* __s, streamsize __n, char_typ
this->rdbuf()->sbumpc();
++__gc_;
}
-if (__n > 0)
-*__s = char_type();
if (__gc_ == 0)
__err |= ios_base::failbit;
this->setstate(__err);
}
+if (__n > 0)
+*__s = char_type();
#ifndef _LIBCPP_NO_EXCEPTIONS
}
catch (...)
{
+if (__n > 0)
+*__s = char_type();
this->__set_badbit_and_consider_rethrow();
}
#endif // _LIBCPP_NO_EXCEPTIONS
diff --git a/test/std/input.output/iostream.format/input.streams/istream.unformatted/getline_pointer_size.pass.cpp b/test/std/input.output/iostream.format/input.streams/istream.unformatted/getline_pointer_size.pass.cpp
index 465824a65..d0da78b5c 100644
--- a/test/std/input.output/iostream.format/input.streams/istream.unformatted/getline_pointer_size.pass.cpp
+++ b/test/std/input.output/iostream.format/input.streams/istream.unformatted/getline_pointer_size.pass.cpp
@@ -59,6 +59,13 @@ int main()
assert(!is.fail());
assert(std::string(s) == " ");
assert(is.gcount() == 1);
+is.getline(s, 5);
+// check that even in error case the buffer
+// is properly 0-terminated
+assert( is.eof());
+assert( is.fail());
+assert(std::string(s) == "");
+assert(is.gcount() == 0);
}
{
testbuf sb(L" \n\n ");
@@ -79,5 +86,12 @@ int main()
assert(!is.fail());
assert(std::wstring(s) == L" ");
assert(is.gcount() == 1);
+is.getline(s, 5);
+// check that even in error case the buffer
+// is properly 0-terminated
+assert( is.eof());
+assert( is.fail());
+assert(std::wstring(s) == L"");
[PATCH] D39947: [OpenMP] Stable sort Privates to remove non-deterministic ordering
mgrang added a comment. Although this patches fixes the above unit test failures, the generated code is very different from the one that the tests expect. As a result, these tests need to be adjusted. Could the reviewers please comment/suggest on whether it is ok to fix the tests as a result of this change. The other way of obtaining deterministic ordering for privates with the same alignment is to use an index for each item inserted into Privates and use it as a tie-breaker. But even in that case the generated code is quite different and tests still need to be adjusted. https://reviews.llvm.org/D39947 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D39947: [OpenMP] Stable sort Privates to remove non-deterministic ordering
mgrang created this revision.
mgrang added a project: clang.
This fixes the following failures uncovered by https://reviews.llvm.org/D39245:
Clang :: OpenMP/task_firstprivate_codegen.cpp
Clang :: OpenMP/task_private_codegen.cpp
Clang :: OpenMP/taskloop_firstprivate_codegen.cpp
Clang :: OpenMP/taskloop_lastprivate_codegen.cpp
Clang :: OpenMP/taskloop_private_codegen.cpp
Clang :: OpenMP/taskloop_simd_firstprivate_codegen.cpp
Clang :: OpenMP/taskloop_simd_lastprivate_codegen.cpp
Clang :: OpenMP/taskloop_simd_private_codegen.cpp
https://reviews.llvm.org/D39947
Files:
lib/CodeGen/CGOpenMPRuntime.cpp
Index: lib/CodeGen/CGOpenMPRuntime.cpp
===
--- lib/CodeGen/CGOpenMPRuntime.cpp
+++ lib/CodeGen/CGOpenMPRuntime.cpp
@@ -4048,9 +4048,9 @@
return TaskPrivatesMap;
}
-static int array_pod_sort_comparator(const PrivateDataTy *P1,
- const PrivateDataTy *P2) {
- return P1->first < P2->first ? 1 : (P2->first < P1->first ? -1 : 0);
+static bool stable_sort_comparator(const PrivateDataTy P1,
+ const PrivateDataTy P2) {
+ return P1.first < P2.first;
}
/// Emit initialization for private variables in task-based directives.
@@ -4278,8 +4278,7 @@
/*PrivateElemInit=*/nullptr)));
++I;
}
- llvm::array_pod_sort(Privates.begin(), Privates.end(),
- array_pod_sort_comparator);
+ std::stable_sort(Privates.begin(), Privates.end(), stable_sort_comparator);
auto KmpInt32Ty = C.getIntTypeForBitwidth(/*DestWidth=*/32, /*Signed=*/1);
// Build type kmp_routine_entry_t (if not built yet).
emitKmpRoutineEntryT(KmpInt32Ty);
Index: lib/CodeGen/CGOpenMPRuntime.cpp
===
--- lib/CodeGen/CGOpenMPRuntime.cpp
+++ lib/CodeGen/CGOpenMPRuntime.cpp
@@ -4048,9 +4048,9 @@
return TaskPrivatesMap;
}
-static int array_pod_sort_comparator(const PrivateDataTy *P1,
- const PrivateDataTy *P2) {
- return P1->first < P2->first ? 1 : (P2->first < P1->first ? -1 : 0);
+static bool stable_sort_comparator(const PrivateDataTy P1,
+ const PrivateDataTy P2) {
+ return P1.first < P2.first;
}
/// Emit initialization for private variables in task-based directives.
@@ -4278,8 +4278,7 @@
/*PrivateElemInit=*/nullptr)));
++I;
}
- llvm::array_pod_sort(Privates.begin(), Privates.end(),
- array_pod_sort_comparator);
+ std::stable_sort(Privates.begin(), Privates.end(), stable_sort_comparator);
auto KmpInt32Ty = C.getIntTypeForBitwidth(/*DestWidth=*/32, /*Signed=*/1);
// Build type kmp_routine_entry_t (if not built yet).
emitKmpRoutineEntryT(KmpInt32Ty);
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D39462: [Sema] Implement -Wmaybe-tautological-constant-compare for when the tautologicalness is data model dependent
lebedev.ri added a comment.
In https://reviews.llvm.org/D39462#922826, @rjmccall wrote:
> I don't speak for the entire project, but I'm not sure I'm interested in the
> diagnostic you're actually offering to contribute here. It may produce a
> warning on your specific test case, but I think it's really much too rigid
> and will lead to massive false positives. I sketched the basics of a design
> that I think I could accept; if you don't want to implement it, that's your
> right, but that doesn't make me more likely to accept what you're willing to
> implement.
Just to reiterate that we are talking about the same thing here:
- https://reviews.llvm.org/D38101 is already merged.
`-Wtautological-constant-compare` is here.
- There are cases when it warns for some target platform, but not the other, as
complained in https://reviews.llvm.org/D39149, and post-review mails for
https://reviews.llvm.org/D38101
- So far it seems all the cases reduce to
#include
#include
int main() {
using T1 = long;
using T2 = int;
T1 r;
if (r < std::numeric_limits::min()) {}
if (r > std::numeric_limits::max()) {}
}
- *This* differential (https://reviews.llvm.org/D39462) would find such cases,
and issue them under different diagnostic, thus reducing the "false-positive"
(it is an open question whether they are actual false-positives or not) rate of
`-Wtautological-constant-compare`.
Are you suggesting me to drop this, and implement some other huge new
diagnostic that may catch such cases before `-Wtautological-constant-compare`,
thus preventing `-Wtautological-constant-compare` from triggering on that
completely?
Repository:
rL LLVM
https://reviews.llvm.org/D39462
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D39462: [Sema] Implement -Wmaybe-tautological-constant-compare for when the tautologicalness is data model dependent
smeenai added a comment.
In https://reviews.llvm.org/D39462#922847, @rjmccall wrote:
> In https://reviews.llvm.org/D39462#922844, @lebedev.ri wrote:
>
> > In https://reviews.llvm.org/D39462#922826, @rjmccall wrote:
> >
> > > I don't speak for the entire project, but I'm not sure I'm interested in
> > > the diagnostic you're actually offering to contribute here. It may
> > > produce a warning on your specific test case, but I think it's really
> > > much too rigid and will lead to massive false positives. I sketched the
> > > basics of a design that I think I could accept; if you don't want to
> > > implement it, that's your right, but that doesn't make me more likely to
> > > accept what you're willing to implement.
> >
> >
> > Just to reiterate that we are talking about the same thing here:
> >
> > - https://reviews.llvm.org/D38101 is already merged.
> > `-Wtautological-constant-compare` is here.
> > - There are cases when it warns for some target platform, but not the
> > other, as complained in https://reviews.llvm.org/D39149, and post-review
> > mails for https://reviews.llvm.org/D38101
> > - So far it seems all the cases reduce to ``` #include #include
> > int main() { using T1 = long; using T2 = int;
> >
> > T1 r; if (r < std::numeric_limits::min()) {} if (r >
> > std::numeric_limits::max()) {} } ```
> > - *This* differential (https://reviews.llvm.org/D39462) would find such
> > cases, and issue them under different diagnostic, thus reducing the
> > "false-positive" (it is an open question whether they are actual
> > false-positives or not) rate of `-Wtautological-constant-compare`.
>
>
> I think you might have this backwards. We think of the check for the
> diagnostic as being the test, so a false positive is when we warn when we
> shouldn't. What you've identified here is a false *negative*, i.e. a case
> where you believe it should warn (because it would warn on a different
> target) that it currently does not.
I guess you can think of it both ways, but the concern for
https://reviews.llvm.org/D39149 was definitely that of a false positive. More
precisely, a `long` variable was being compared against the limits for `int`.
On a 64-bit platform, you would have no warning. On a 32-bit platform, you
would have a warning, by virtue of `int` and `long` being the same size. I
consider the warning on the 32-bit platform to be a false positive, since the
comparison is serving a purpose, but the compiler is still flagging it as
tautological. In general, I would want is for `-Wtautological-constant-compare`
to only fire in cases where the comparison is **guaranteed** to be
tautological, and would consider anything else to be a false positive.
Repository:
rL LLVM
https://reviews.llvm.org/D39462
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D39462: [Sema] Implement -Wmaybe-tautological-constant-compare for when the tautologicalness is data model dependent
rjmccall added a comment. I don't speak for the entire project, but I'm not sure I'm interested in the diagnostic you're actually offering to contribute here. It may produce a warning on your specific test case, but I think it's really much too rigid and will lead to massive false positives. I sketched the basics of a design that I think I could accept; if you don't want to implement it, that's your right, but that doesn't make me more likely to accept what you're willing to implement. Repository: rL LLVM https://reviews.llvm.org/D39462 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: [PATCH] D39360: [C++11] Don't put empty quotes in static_assert diagnostic.
Agreed! Just wanted to do it but then I noticed that there's already one that landed in r307791! :) On Sun, Oct 29, 2017 at 2:06 PM, Kim Gräsman wrote: > A clang-tidy check to remove empty messages from source would be nice, > though... > > - Kim > > Den 27 okt. 2017 10:24 fm skrev "Nicolas Lesser via Phabricator" < > revi...@reviews.llvm.org>: > >> Rakete abandoned this revision. >> Rakete added a comment. >> >> @kimgr Well, mostly because they bother me a bit, don't know what others >> think though. I just thought it would be nice if they didn't appear, mainly >> because there is no need to show empty quotes in the error message. Hmm, >> you have a point though... Didn't think of that. Thanks +1 >> >> >> https://reviews.llvm.org/D39360 >> >> >> >> ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D39944: [Sema] Stable sort OverloadCandidates to remove non-deterministic ordering
rjmccall accepted this revision. rjmccall added a comment. This revision is now accepted and ready to land. Hmm. It looks like the intent is for CompareOverloadCandidatesForDisplay to be a total order, but I'm sure there are cases where it isn't. Okay, LGTM. https://reviews.llvm.org/D39944 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D39462: [Sema] Implement -Wmaybe-tautological-constant-compare for when the tautologicalness is data model dependent
rjmccall added a comment.
In https://reviews.llvm.org/D39462#922844, @lebedev.ri wrote:
> In https://reviews.llvm.org/D39462#922826, @rjmccall wrote:
>
> > I don't speak for the entire project, but I'm not sure I'm interested in
> > the diagnostic you're actually offering to contribute here. It may produce
> > a warning on your specific test case, but I think it's really much too
> > rigid and will lead to massive false positives. I sketched the basics of a
> > design that I think I could accept; if you don't want to implement it,
> > that's your right, but that doesn't make me more likely to accept what
> > you're willing to implement.
>
>
> Just to reiterate that we are talking about the same thing here:
>
> - https://reviews.llvm.org/D38101 is already merged.
> `-Wtautological-constant-compare` is here.
> - There are cases when it warns for some target platform, but not the other,
> as complained in https://reviews.llvm.org/D39149, and post-review mails for
> https://reviews.llvm.org/D38101
> - So far it seems all the cases reduce to ``` #include #include
> int main() { using T1 = long; using T2 = int;
>
> T1 r; if (r < std::numeric_limits::min()) {} if (r >
> std::numeric_limits::max()) {} } ```
> - *This* differential (https://reviews.llvm.org/D39462) would find such
> cases, and issue them under different diagnostic, thus reducing the
> "false-positive" (it is an open question whether they are actual
> false-positives or not) rate of `-Wtautological-constant-compare`.
I think you might have this backwards. We think of the check for the
diagnostic as being the test, so a false positive is when we warn when we
shouldn't. What you've identified here is a false *negative*, i.e. a case
where you believe it should warn (because it would warn on a different target)
that it currently does not.
> Are you suggesting me to drop this, and implement some other huge new
> diagnostic that may catch such cases before
> `-Wtautological-constant-compare`, thus preventing
> `-Wtautological-constant-compare` from triggering on that completely?
"This warning triggers on some targets and not on others" is a far more
widespread problem than just -Wtautological-constant-compare. I don't think
your patch reasonably solves that problem, even for just this diagnostic. I
think a "strong typedef" analysis would address it, but that's going to require
a significant amount of work, even if you literally only apply it to this
warning, because you're going to have to implement a bunch of more careful
logic about inferring when to propagate typedefs through e.g. templates, as
well as when to consider a template to have "propagated" through arithmetic
promotion in the same way we propagate integer ranges.
Repository:
rL LLVM
https://reviews.llvm.org/D39462
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[libcxx] r318000 - Two more papers from Albuquerque
Author: marshall Date: Sun Nov 12 10:52:16 2017 New Revision: 318000 URL: http://llvm.org/viewvc/llvm-project?rev=318000&view=rev Log: Two more papers from Albuquerque Modified: libcxx/trunk/www/cxx2a_status.html Modified: libcxx/trunk/www/cxx2a_status.html URL: http://llvm.org/viewvc/llvm-project/libcxx/trunk/www/cxx2a_status.html?rev=318000&r1=317999&r2=318000&view=diff == --- libcxx/trunk/www/cxx2a_status.html (original) +++ libcxx/trunk/www/cxx2a_status.html Sun Nov 12 10:52:16 2017 @@ -69,6 +69,8 @@ https://wg21.link/P0616R0";>P0616R0LWGde-pessimize legacy algorithms with std::moveAlbuquerque https://wg21.link/P0653R2";>P0653R2LWGUtility to convert a pointer to a raw pointerAlbuquerque https://wg21.link/P0718R2";>P0718R2LWGAtomic shared_ptrAlbuquerque + https://wg21.link/P0767R1";>P0767R1CWGDeprecate PODAlbuquerque + https://wg21.link/P0768R1";>P0768R1CWGLibrary Support for the Spaceship (Comparison) OperatorAlbuquerque https://wg21.link/P0777R1";>P0777R1LWGTreating Unnecessary decayAlbuquerque ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[libcxx] r317996 - Updated C++2a status page with new features/defects approved in Albuquerque.
Author: marshall Date: Sun Nov 12 10:48:42 2017 New Revision: 317996 URL: http://llvm.org/viewvc/llvm-project?rev=317996&view=rev Log: Updated C++2a status page with new features/defects approved in Albuquerque. Modified: libcxx/trunk/www/cxx2a_status.html Modified: libcxx/trunk/www/cxx2a_status.html URL: http://llvm.org/viewvc/llvm-project/libcxx/trunk/www/cxx2a_status.html?rev=317996&r1=317995&r2=317996&view=diff == --- libcxx/trunk/www/cxx2a_status.html (original) +++ libcxx/trunk/www/cxx2a_status.html Sun Nov 12 10:48:42 2017 @@ -57,6 +57,20 @@ https://wg21.link/P0463R1";>P0463R1LWGEndian just EndianTorontoIn progress https://wg21.link/P0674R1";>P0674R1LWGExtending make_shared to Support ArraysToronto + + https://wg21.link/P0020R6";>P0020R6LWGFloating Point AtomicAlbuquerque + https://wg21.link/P0053R7";>P0053R7LWGC++ Synchronized Buffered OstreamAlbuquerque + https://wg21.link/P0202R3";>P0202R3LWGAdd constexpr modifiers to functions inand HeadersAlbuquerque + https://wg21.link/P0415R1";>P0415R1LWGConstexpr for std::complexAlbuquerque + https://wg21.link/P0439R0";>P0439R0LWGMake std::memory_order a scoped enumerationAlbuquerque + https://wg21.link/P0457R2";>P0457R2LWGString Prefix and Suffix CheckingAlbuquerque + https://wg21.link/P0550R2";>P0550R2LWGTransformation Trait remove_cvrefAlbuquerque + https://wg21.link/P0600R1";>P0600R1LWGnodiscard in the LibraryAlbuquerque + https://wg21.link/P0616R0";>P0616R0LWGde-pessimize legacy algorithms with std::moveAlbuquerque + https://wg21.link/P0653R2";>P0653R2LWGUtility to convert a pointer to a raw pointerAlbuquerque + https://wg21.link/P0718R2";>P0718R2LWGAtomic shared_ptrAlbuquerque + https://wg21.link/P0777R1";>P0777R1LWGTreating Unnecessary decayAlbuquerque + @@ -83,6 +97,34 @@ https://wg21.link/LWG2966";>2966Incomplete resolution of US 74TorontoNothing to do https://wg21.link/LWG2974";>2974Diagnose out of bounds tuple_element/variant_alternativeTorontoComplete + + https://wg21.link/LWG2779";>2779[networking.ts] Relax requirements on buffer sequence iteratorsAlbuquerque + https://wg21.link/LWG2870";>2870Default value of parameter theta of polar should be dependentAlbuquerque + https://wg21.link/LWG2935";>2935What should create_directories do when p already exists but is not a directory?Albuquerque + https://wg21.link/LWG2941";>2941[thread.req.timing] wording should apply to both member and namespace-level functionsAlbuquerqueNothing to do + https://wg21.link/LWG2944";>2944LWG 2905 accidentally removed requirement that construction of the deleter doesn't throw an exceptionAlbuquerqueNothing to do + https://wg21.link/LWG2945";>2945Order of template parameters in optional comparisonsAlbuquerqueComplete + https://wg21.link/LWG2948";>2948unique_ptr does not define operator<< for stream outputAlbuquerque + https://wg21.link/LWG2950";>2950std::byte operations are misspecifiedAlbuquerque + https://wg21.link/LWG2952";>2952iterator_traits should work for pointers to cv TAlbuquerque + https://wg21.link/LWG2953";>2953LWG 2853 should apply to deque::erase tooAlbuquerque + https://wg21.link/LWG2958";>2958Moves improperly defined as deletedAlbuquerque + https://wg21.link/LWG2964";>2964Apparently redundant requirement for dynamic_pointer_castAlbuquerque + https://wg21.link/LWG2965";>2965Non-existing path::native_string() in filesystem_error::what() specificationAlbuquerque + https://wg21.link/LWG2972";>2972What is is_trivially_destructible_v?AlbuquerqueComplete + https://wg21.link/LWG2976";>2976Dangling uses_allocator specialization for packaged_taskAlbuquerque + https://wg21.link/LWG2977";>2977unordered_meow::merge() has incorrect Throws: clauseAlbuquerque + https://wg21.link/LWG2978";>2978Hash support for pmr::string and friendsAlbuquerque + https://wg21.link/LWG2979";>2979aligned_union should require complete object typesAlbuquerqueComplete + https://wg21.link/LWG2980";>2980Cannot compare_exchange empty pointersAlbuquerque + https://wg21.link/LWG2981";>2981Remove redundant deduction guides from standard libraryAlbuquerque + https://wg21.link/LWG2982";>2982Making size_type consistent in associative container deduction guidesAlbuquerque + https://wg21.link/LWG2988";>2988Clause 32 cleanup missed one typenameAlbuquerque + https://wg21.link/LWG2993";>2993reference_wrapper conversion from T&&Albuquerque + https://wg21.link/LWG2998";>2998Requirements on function objects passed to {forward_,}list-specific algorithmsAlbuquerqueNothing to do + https://wg21.link/LWG3001";>3001weak_ptr::element_type needs remove_extent_tAlbuquerque + htt
[PATCH] D39944: [Sema] Stable sort OverloadCandidates to remove non-deterministic ordering
mgrang created this revision. mgrang added a project: clang. This fixes failure in Misc/diag-template-diffing.cpp uncovered by https://reviews.llvm.org/D39245. https://reviews.llvm.org/D39944 Files: lib/Sema/SemaOverload.cpp Index: lib/Sema/SemaOverload.cpp === --- lib/Sema/SemaOverload.cpp +++ lib/Sema/SemaOverload.cpp @@ -10516,7 +10516,7 @@ } } - std::sort(Cands.begin(), Cands.end(), + std::stable_sort(Cands.begin(), Cands.end(), CompareOverloadCandidatesForDisplay(S, OpLoc, Args.size(), Kind)); bool ReportedAmbiguousConversions = false; Index: lib/Sema/SemaOverload.cpp === --- lib/Sema/SemaOverload.cpp +++ lib/Sema/SemaOverload.cpp @@ -10516,7 +10516,7 @@ } } - std::sort(Cands.begin(), Cands.end(), + std::stable_sort(Cands.begin(), Cands.end(), CompareOverloadCandidatesForDisplay(S, OpLoc, Args.size(), Kind)); bool ReportedAmbiguousConversions = false; ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
