[clang-tools-extra] [clang-tidy] Switch misc-confusable-identifiers check to a faster algorithm. (PR #130369)

zygoloid wrote: Ping x8 @PiotrZSL Any chance you'll find time to look at this soon, or should I look for other reviewers? https://github.com/llvm/llvm-project/pull/130369 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/

[clang] Include [[clang::require_explicit_initialization]] warnings in system headers (PR #141133)

zygoloid wrote: > Its more that we assume/like to assume that the Standard Library always 'does > the right thing', even if it does so in ways that look 'wrong'. So we > suppress warnings in the standard library headers, since they are assumed to > all be false-positives. > > This of course i

[clang] Include [[clang::require_explicit_initialization]] warnings in system headers (PR #141133)

zygoloid wrote: I don't think this concern is specific to system headers. I don't think we have precedent for disabling a warning in a SFINAE context. We do suppress warnings produced while substituting into a function template specialization during deduction if we end up not selecting that ov

[clang] Include [[clang::require_explicit_initialization]] warnings in system headers (PR #141133)

zygoloid wrote: There are [techniques](https://github.com/carbon-language/carbon-lang/blob/69ab97d7167146ae1deea662126af66f8f5523a2/common/struct_reflection.h#L74) for determining the number of fields in an aggregate type `T` by attempting to initialize with `T{}` then `T{arg}` then `T{arg, ar

[clang-tools-extra] [clang-tidy] Switch misc-confusable-identifiers check to a faster algorithm. (PR #130369)

zygoloid wrote: Ping x7 https://github.com/llvm/llvm-project/pull/130369 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [Clang] Implement P2280R4 Using unknown pointers and references in constant expressions (PR #95474)

zygoloid wrote: > > If that mode doesn't already permit using unknown pointers and references > > in all language modes, then we should change it so that it does. > > `__builtin_object_size` is best-effort, but we should produce a constant > > value for it that's not the `-1` or `0` fallback v

[clang] [Clang] Implement P2280R4 Using unknown pointers and references in constant expressions (PR #95474)

zygoloid wrote: > Should `foo` in the following code return 4 when `-fstrict-flex-arrays` is 2 > or 3 (but not when it's 0 or 1) only when the target is `-std=c++23` or > newer? Or should it return 4 for older standards too? We evaluate the operand of `__builtin_object_size` in `EM_IgnoreSideE

[clang] [Serialization] Fix lazy template loading (PR #133057)

zygoloid wrote: Conversion function templates might be a special case here because of how conversion function template specializations are found by deduction as part of class member name lookup. Maybe we're doing something different in that deduction in particular that means we're not properly

[clang] [Clang] Add `noalias` to `this` pointer in C++ constructors (PR #136792)

zygoloid wrote: > @zygoloid Can you explain in your example why `a.n == 2` must be true, when > your interpretation (which I understood in the same manner) of the standard's > wording does indicate that the object's state is unspecified? My reading is that the standard says that the value of `

[clang-tools-extra] [clang-tidy] Switch misc-confusable-identifiers check to a faster algorithm. (PR #130369)

zygoloid wrote: Ping x6 https://github.com/llvm/llvm-project/pull/130369 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [ObjC] Stop hard-coding the list of keywords that are allowed in selectors (PR #138952)

@@ -1095,75 +1095,8 @@ IdentifierInfo *Parser::ParseObjCSelectorPiece(SourceLocation &SelectorLoc) { } case tok::identifier: - case tok::kw_asm: - case tok::kw_auto: - case tok::kw_bool: - case tok::kw_break: - case tok::kw_case: - case tok::kw_catch: - case tok::k

[clang] [clang] Document -fstrict-flex-arrays option (PR #138388)

https://github.com/zygoloid approved this pull request. Thank you! https://github.com/llvm/llvm-project/pull/138388 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang] Document -fstrict-flex-arrays option (PR #138388)

@@ -1554,7 +1554,10 @@ def fstrict_flex_arrays_EQ : Joined<["-"], "fstrict-flex-arrays=">, Group, NormalizedValuesScope<"LangOptions::StrictFlexArraysLevelKind">, NormalizedValues<["Default", "OneZeroOrIncomplete", "ZeroOrIncomplete", "IncompleteOnly"]>, - HelpText<"Enabl

[clang] [clang] Document -fstrict-flex-arrays option (PR #138388)

@@ -1554,7 +1554,10 @@ def fstrict_flex_arrays_EQ : Joined<["-"], "fstrict-flex-arrays=">, Group, NormalizedValuesScope<"LangOptions::StrictFlexArraysLevelKind">, NormalizedValues<["Default", "OneZeroOrIncomplete", "ZeroOrIncomplete", "IncompleteOnly"]>, - HelpText<"Enabl

[clang] [Clang] Implement P2280R4 Using unknown pointers and references in constant expressions (PR #95474)

zygoloid wrote: Looks like a bug to me. This warning presumably ought to be checking whether it's valid to read / write to the given location using something like [`isUserWritingOffTheEnd`](https://github.com/llvm/llvm-project/blob/b2e2ae8702e9fbbe0ef0eb5929aa2d5dc867b1c5/clang/lib/AST/ExprCons

[clang] [Clang] Implement P2280R4 Using unknown pointers and references in constant expressions (PR #95474)

zygoloid wrote: > Is the warning valid? Is the change in clang's behavior intentional? What do you have `-fstrict-flex-arrays` set to? Per [the documentation](https://releases.llvm.org/15.0.0/tools/clang/docs/ClangCommandLineReference.html#cmdoption-clang-fstrict-flex-arrays) (which weirdly se

[clang] [C] Diagnose use of C++ keywords in C (PR #137234)

zygoloid wrote: For what it's worth, the existing "keyword from language you're not using" warnings [already fire for analogous Objective-C++ cases](https://godbolt.org/z/3K6835PPK)... which in those cases is correct, since Clang does *not* accept C++11-onwards keywords as selector names in th

[clang] [C] Diagnose use of C++ keywords in C (PR #137234)

@@ -6118,6 +6120,10 @@ void Sema::warnOnReservedIdentifier(const NamedDecl *D) { Diag(D->getLocation(), diag::warn_reserved_extern_symbol) << D << static_cast(Status); } + // Diagnose use of C++ keywords in C as being incompatible with C++. + if (const Identifie

[clang] [C] Diagnose use of C++ keywords in C (PR #137234)

@@ -258,8 +283,13 @@ static void AddKeyword(StringRef Keyword, const LangOptions &LangOpts, IdentifierTable &Table) { KeywordStatus AddResult = getKeywordStatus(LangOpts, Flags); - // Don't add this keyword if disabled in this language. - if (AddResu

[clang-tools-extra] [clang-tidy] Switch misc-confusable-identifiers check to a faster algorithm. (PR #130369)

zygoloid wrote: Ping x5. https://github.com/llvm/llvm-project/pull/130369 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [BPF] Fix issues with external declarations of C++ structor decls (PR #137079)

https://github.com/zygoloid approved this pull request. https://github.com/llvm/llvm-project/pull/137079 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [Clang] Add `noalias` to `this` pointer in C++ constructors (PR #136792)

zygoloid wrote: > * I'm not sure this matches the requirements for C++ semantics; noalias is > very aggressive, so we might end up with undefined behavior in unintended > cases. I'd like someone familiar with the relevant standard bits to comment > on the requirements here. CC @zygoloid The

[clang] [ConstEval] Fix crash when comparing strings past the end (PR #137078)

zygoloid wrote: Yeah. I agree that using the overlap diagnostic only in the case where there's at least one byte of potential overlap (as this PR does) is best. https://github.com/llvm/llvm-project/pull/137078 ___ cfe-commits mailing list cfe-commits@

[clang] [ConstEval] Fix crash when comparing strings past the end (PR #137078)

https://github.com/zygoloid approved this pull request. Thanks for the fix! I was wondering if the new code paths should actually return `true` not `false`, but I think it makes sense that for a comparison like `"hello" + 6 == "world"`, we say that the strings are *not* potentially-overlapping

[clang] [Clang] Make the result type of sizeof/pointer subtraction/size_t lit… (PR #136542)

zygoloid wrote: > If the type is an extension, we can define its compatibility rules, can't we? Well, the type `size_t` is not an extension, and we can't make strictly conforming C programs observably use a compatibility rule that the C standard doesn't permit. I think we *could* make the clai

[clang] [Clang] Add support for GCC bound member functions extension (PR #135649)

zygoloid wrote: > We don't know which function is called until the object `p` is provided. See > case 2 in > https://discourse.llvm.org/t/rfc-implement-gcc-bound-pmf-in-clang/85951. Perhaps we could provide a builtin function that takes an object pointer and a pointer-to-member-function and r

[clang] [Clang] Add support for GCC bound member functions extension (PR #135649)

zygoloid wrote: > Not sure if anyone has mentioned this elsewhere, but there's a significant > problem with the type of the returned function pointer: a normal function > pointer doesn't necessarily have the correct calling convention. In practice, > this is likely to cause problems on Windows

[clang] [Clang] Make the result type of sizeof/pointer subtraction/size_t lit… (PR #136542)

zygoloid wrote: Another possibility would be to add a new kind of type sugar for these cases that has the same canonical type but knows that it should print as `size_t` / `ptrdiff_t` etc. That'd allow you to produce an identical AST regardless of whether the typedefs are included, which seems

[clang] Make the `-disable-free` flag more full featured (PR #136213)

@@ -7889,9 +7889,13 @@ def code_completion_with_fixits : Flag<["-"], "code-completion-with-fixits">, def skip_function_bodies : Flag<["-"], "skip-function-bodies">, HelpText<"Skip function bodies when possible">, MarshallingInfoFlag>; -def disable_free : Flag<["-"], "disab

[clang] Make the `-disable-free` flag more full featured (PR #136213)

https://github.com/zygoloid approved this pull request. https://github.com/llvm/llvm-project/pull/136213 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] Make the `-disable-free` flag more full featured (PR #136213)

@@ -7889,9 +7889,13 @@ def code_completion_with_fixits : Flag<["-"], "code-completion-with-fixits">, def skip_function_bodies : Flag<["-"], "skip-function-bodies">, HelpText<"Skip function bodies when possible">, MarshallingInfoFlag>; -def disable_free : Flag<["-"], "disab

[clang-tools-extra] [clang-tidy] Switch misc-confusable-identifiers check to a faster algorithm. (PR #130369)

zygoloid wrote: Ping x4. https://github.com/llvm/llvm-project/pull/130369 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] Disable -fdollars-in-identifiers by default (PR #135407)

https://github.com/zygoloid edited https://github.com/llvm/llvm-project/pull/135407 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] Disable -fdollars-in-identifiers by default (PR #135407)

@@ -1,5 +1,5 @@ // REQUIRES: x86-registered-target -// RUN: %clang_cc1 %s -triple i386-apple-darwin10 -fasm-blocks -emit-llvm -o - | FileCheck %s +// RUN: %clang_cc1 %s -triple i386-apple-darwin10 -fdollars-in-identifiers -fasm-blocks -emit-llvm -o - | FileCheck %s

[clang] Disable -fdollars-in-identifiers by default (PR #135407)

@@ -119,7 +119,7 @@ LANGOPT(WChar , 1, 0, "wchar_t keyword") LANGOPT(Char8 , 1, 0, "char8_t keyword") LANGOPT(IEEE128 , 1, 0, "__ieee128 keyword") LANGOPT(DeclSpecKeyword , 1, 0, "__declspec keyword") -BENIGN_LANGOPT(DollarIdents , 1, 1, "'

[clang] Disable -fdollars-in-identifiers by default (PR #135407)

https://github.com/zygoloid approved this pull request. LGTM, thanks! https://github.com/llvm/llvm-project/pull/135407 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [C99] Remove the tgmath.h header (PR #135236)

zygoloid wrote: > > For some reason, WG21 has trampled over that meaning of "freestanding" and > > we no longer have such a separation for C++, but it still exists for C > > See #132232. Sigh. So we can't use "freestanding" as the line between compiler and standard library anywhere any more,

[clang] [C99] Remove the tgmath.h header (PR #135236)

zygoloid wrote: A few datapoints: * uClibc [uses `__builtin_classify_type`](https://git.uclibc.org/uClibc/tree/include/tgmath.h) and it looks like that'd work fine for us. * newlib [uses `__builtin_choose_expr`](https://sourceware.org/git/?p=newlib-cygwin.git;a=blob;f=newlib/libc/include/tgmat

[clang] [C99] Remove the tgmath.h header (PR #135236)

zygoloid wrote: I see. The glibc header comment gives an idea of what's going on here: ```c /* There are two variant implementations of type-generic macros in this file: one for GCC 8 and later, using __builtin_tgmath and where each macro expands each of its arguments only once, and one

[clang] No longer add enumeration constants to the wrong scope (PR #134998)

zygoloid wrote: > > I thought CWG's preferred direction on this was to reject entirely? > > What do they wish to reject? Defining an enum in a different declaration > context than its primary context? That seems odd. > > Do you have an idea of the CWG DR? We looked but couldn't find anything t

[clang] Support '-fmodule-file-home-is-cwd' for C++ modules. (PR #135147)

zygoloid wrote: > But if we want relocatable modules without using `-fmodules-embed-all-files` > though, is there a solution for that? Do you use `-no-canonical-prefixes`? https://github.com/llvm/llvm-project/pull/135147 ___ cfe-commits mailing list

[clang] [C99] Remove the tgmath.h header (PR #135236)

zygoloid wrote: > > I wonder if we can put it into an AIX-only (plus whatever other targets > > still need it) include directory, though, so we only find and use it on the > > targets where it's necessary? > > That, or, generally `#include_next` except for certain platforms (like AIX)? Possib

[clang] [C99] Remove the tgmath.h header (PR #135236)

zygoloid wrote: > Background: it's not clear to me which C Standard Library headers Clang > should or should not provide, Historically, the easiest line to draw has been that we aim to provide the freestanding headers. This matches GCC's [documented position](https://gcc.gnu.org/onlinedocs/gc

[clang] No longer add enumeration constants to the wrong scope (PR #134998)

zygoloid wrote: This came up on the core reflector again just yesterday; would be worth asking there. https://github.com/llvm/llvm-project/pull/134998 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listi

[clang] No longer add enumeration constants to the wrong scope (PR #134998)

zygoloid wrote: I thought CWG's preferred direction on this was to reject entirely? https://github.com/llvm/llvm-project/pull/134998 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] Reject invalid integer constants in unevaluated preprocessor operands (PR #134884)

https://github.com/zygoloid approved this pull request. LGTM. I suppose if people complain, we can make the non-live value case a warning rather than an error, but given no other implementation does, I think it makes sense not to do that speculatively. https://github.com/llvm/llvm-project/pul

[clang-tools-extra] [clang-tidy] Switch misc-confusable-identifiers check to a faster algorithm. (PR #130369)

zygoloid wrote: Ping. https://github.com/llvm/llvm-project/pull/130369 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [Clang][RFC] Bypass TAD during overload resolution if a perfect match exists (PR #133426)

https://github.com/zygoloid commented: I think we should do this. Even if WG21 decides that they only want to allow this and not require it, it seems like a good change that we stand a decent chance of reaching implementation consensus on. https://github.com/llvm/llvm-project/pull/133426 _

[clang] [Clang][RFC] Bypass TAD during overload resolution if a perfect match exists (PR #133426)

@@ -10230,9 +10307,15 @@ Sema::AddArgumentDependentLookupCandidates(DeclarationName Name, /*AllowExplicit=*/true, ADLCallKind::UsesADL); if (CandidateSet.getRewriteInfo().shouldAddReversed( *this, Args, FTD->getTemplatedDecl())) { + +// As

[clang] [Clang][RFC] Bypass TAD during overload resolution if a perfect match exists (PR #133426)

@@ -8455,11 +8524,17 @@ void Sema::AddNonMemberOperatorCandidates( if (FunTmpl) { AddTemplateOverloadCandidate(FunTmpl, F.getPair(), ExplicitTemplateArgs, FunctionArgs, CandidateSet); - if (CandidateSet.getRewriteInfo().shouldAd

[clang-tools-extra] [clang-tidy] Switch misc-confusable-identifiers check to a faster algorithm. (PR #130369)

zygoloid wrote: Ping. https://github.com/llvm/llvm-project/pull/130369 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [Clang] Force expressions with UO_Not to not be non-negative (PR #126846)

zygoloid wrote: > But still I feel generate a warning for this case went too far. Yeah, that's probably right. Maybe for `-` on a signed operand, we should just return the original range with the `NonNegative` flag cleared out, and shouldn't add the extra bit for the `-128 -> 128` edge case. T

[clang] [Sema] Diagnose by-value copy constructors in template instantiations (PR #130866)

zygoloid wrote: This error is [produced for the following code](https://github.com/carbon-language/carbon-lang/pull/5170): ```c++ template class SetView { SetView(SetView, KeyContextT> other_view) requires(!std::same_as>); }; ``` ... which is never an eligible copy constructor. Is that in

[clang] [Clang] Force expressions with UO_Not to not be non-negative (PR #126846)

zygoloid wrote: > > But still I feel generate a warning for this case went too far. > > Yeah, that's probably right. Maybe for `-` on a signed operand, we should > just return the original range with the `NonNegative` flag cleared out, and > shouldn't add the extra bit for the `-128 -> 128` ed

[clang] [Clang] Force expressions with UO_Not to not be non-negative (PR #126846)

zygoloid wrote: > Would it be possible to provide better fine grained control over the > `-Wsign-compare` so the clang could still flag the the cases like the one in > the summary but ignore the cases where implicit conversion has no side > effects or UB? The warning being produced is a `-Wim

[clang] [clang-tools-extra] Suppress pedantic diagnostic for a file not ending in EOL (PR #131794)

@@ -127,8 +127,10 @@ C2y Feature Support that ``_Generic`` selection associations may now have ``void`` type, but it also removes UB with code like ``(void)(void)1;``. - Implemented `WG14 N3411 `_ - which allows

[clang] [clang-tools-extra] Suppress pedantic diagnostic for a file not ending in EOL (PR #131794)

https://github.com/zygoloid commented: LG https://github.com/llvm/llvm-project/pull/131794 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang-tools-extra] Suppress pedantic diagnostic for a file not ending in EOL (PR #131794)

https://github.com/zygoloid edited https://github.com/llvm/llvm-project/pull/131794 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang-tools-extra] Suppress pedantic diagnostic for a file not ending in EOL (PR #131794)

@@ -627,8 +627,6 @@ buildPreamble(PathRef FileName, CompilerInvocation CI, return DiagnosticsEngine::Ignored; switch (Info.getID()) { case diag::warn_no_newline_eof: -case diag::warn_cxx98_compat_no_newline_eof: -case diag::ext_no_newline_eof: // If

[clang] [C++20][Modules] Prevent premature call to PassInterestingDeclsToConsumer() within FinishedDeserializing(). (PR #129982)

zygoloid wrote: Thank you! I can imagine figuring out what was wrong here was not easy! https://github.com/llvm/llvm-project/pull/129982 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [C++20][Modules] Prevent premature call to PassInterestingDeclsToConsumer() within FinishedDeserializing(). (PR #129982)

https://github.com/zygoloid approved this pull request. https://github.com/llvm/llvm-project/pull/129982 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [C++20][Modules] Prevent premature call to PassInterestingDeclsToConsumer() within FinishedDeserializing(). (PR #129982)

https://github.com/zygoloid commented: Thanks, the explanation and code change makes sense to me. Should this bugfix have a release note? https://github.com/llvm/llvm-project/pull/129982 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://

[clang-tools-extra] [clang-tidy] Switch misc-confusable-identifiers check to a faster algorithm. (PR #130369)

https://github.com/zygoloid created https://github.com/llvm/llvm-project/pull/130369 Optimizations: - Only build the skeleton for each identifier once, rather than once for each declaration of that identifier. - Only compute the contexts in which identifiers are declared for identifiers that

[clang-tools-extra] [clang-tidy] Switch misc-confusable-identifiers check to a faster algorithm. (PR #130369)

https://github.com/zygoloid updated https://github.com/llvm/llvm-project/pull/130369 >From 78c9d5da85723040c30f00cb53e77c9dd4cc14b8 Mon Sep 17 00:00:00 2001 From: Richard Smith Date: Fri, 7 Mar 2025 22:49:37 + Subject: [PATCH 1/3] Switch misc-confusable-identifiers check to a faster algori

[clang] [Clang] Force expressions with UO_Not to not be non-negative (PR #126846)

zygoloid wrote: Can you update the first comment on this PR to reflect what you want to be in the commit message? I notice that it doesn't describe what you're doing with negation yet. Thanks! https://github.com/llvm/llvm-project/pull/126846 ___ cfe-

[clang] [Clang] Force expressions with UO_Not to not be non-negative (PR #126846)

https://github.com/zygoloid approved this pull request. https://github.com/llvm/llvm-project/pull/126846 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang][diagnostics] add '-Wundef-true' warning option (PR #128265)

@@ -257,7 +257,10 @@ static bool EvaluateValue(PPValue &Result, Token &PeekTok, DefinedTracker &DT, // preprocessor keywords and it wasn't macro expanded, it turns // into a simple 0 if (ValueLive) { - PP.Diag(PeekTok, diag::warn_pp_undef_ident

[clang] [clang][diagnostics] add '-Wundef-true' warning option (PR #128265)

https://github.com/zygoloid edited https://github.com/llvm/llvm-project/pull/128265 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang][diagnostics] add '-Wundef-true' warning option (PR #128265)

@@ -791,6 +791,8 @@ def ReservedIdAsMacroAlias : DiagGroup<"reserved-id-macro", [ReservedIdAsMacro]> def ReservedAttributeIdentifier : DiagGroup<"reserved-attribute-identifier">; def RestrictExpansionMacro : DiagGroup<"restrict-expansion">; def FinalMacro : DiagGroup<"final-ma

[clang] [clang][diagnostics] add '-Wundef-true' warning option (PR #128265)

https://github.com/zygoloid commented: Thanks! https://github.com/llvm/llvm-project/pull/128265 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang][diagnostics] add '-Wundef-true' warning option (PR #128265)

@@ -393,6 +393,9 @@ def pp_macro_not_used : Warning<"macro is not used">, DefaultIgnore, def warn_pp_undef_identifier : Warning< "%0 is not defined, evaluates to 0">, InGroup>, DefaultIgnore; +def warn_pp_undef_true_identifier : Warning< + "'true' is not defined, evaluate

[clang] [clang][diagnostics] add '-Wundef-true' warning option (PR #128265)

@@ -260,7 +260,8 @@ static bool EvaluateValue(PPValue &Result, Token &PeekTok, DefinedTracker &DT, PP.Diag(PeekTok, diag::warn_pp_undef_identifier) << II; const DiagnosticsEngine &DiagEngine = PP.getDiagnostics(); - // If 'Wundef' is enabled, do n

[clang-tools-extra] [clang-tidy] warn when `true` is used as a preprocessor keyword in C (PR #128265)

zygoloid wrote: > > 2. Create check that forbids usage of true/false in processor as an > > non-portable thing (could be in portability category) > > 3. Extracting 'true' case from -Wundef into separate warning like > > -Wundef-true > > I like both of these approaches, though I prefer the 2. o

[clang-tools-extra] [clang-tidy] warn when `true` is used as a preprocessor keyword in C (PR #128265)

zygoloid wrote: > 1. Not adding check if -Wundef is sufficient > 2. Create check that forbids usage of true/false in processor as an > non-portable thing (could be in portability category) > 3. Extracting 'true' case from -Wundef into separate warning like -Wundef-true Option 3 seems best to me

[clang-tools-extra] [clang-tidy] warn when `true` is used as a preprocessor keyword in C (PR #128265)

zygoloid wrote: Perhaps we could split off a warning from `-Wundef` for the specific case where the undefined macro name is `true`, and enable it by default? Doing this in a clang-tidy check seems like the wrong place -- this check is much better suited to being implemented as a compiler warni

[clang] [Clang] Force expressions with UO_Not to not be non-negative (PR #126846)

@@ -10069,6 +10069,17 @@ static std::optional TryGetExprRange(ASTContext &C, const Expr *E, case UO_AddrOf: // should be impossible return IntRange::forValueOfType(C, GetExprType(E)); +case UO_Not: { + std::optional SubRange = TryGetExprRange( + C,

[clang] [clang] print correct context for diagnostics suppressed by deduction (PR #125453)

zygoloid wrote: Thank you for tackling this longstanding issue! How much does saving this extra state add to the runtime and memory usage on a template-heavy compilation? If the cost is concerning, one other option we could consider here would be performing pending local instantiations eagerly

[clang] [AArch64] Match GCC behaviour for zero-size structs (PR #124760)

zygoloid wrote: Also, is it worth adding `-fclang-abi-compat=` support to control this change? https://github.com/llvm/llvm-project/pull/124760 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-

[clang] [Clang][Sema] Reject declaring an alias template with the same name as its template parameter. (PR #123533)

https://github.com/zygoloid edited https://github.com/llvm/llvm-project/pull/123533 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [Clang][Sema] Reject declaring an alias template with the same name as its template parameter. (PR #123533)

https://github.com/zygoloid commented: This change looks good to me. https://github.com/llvm/llvm-project/pull/123533 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [Clang][Sema] Reject declaring an alias template with the same name as its template parameter. (PR #123533)

@@ -65,7 +65,8 @@ namespace InFunctions { template struct S3 { // expected-note {{template parameter is declared here}} template using T = int; // expected-error {{declaration of 'T' shadows template parameter}} }; - template using Z = Z; + template // expected-note

[clang] [Clang][P1061] Add stuctured binding packs (PR #121417)

@@ -4213,8 +4226,35 @@ class DecompositionDecl final static DecompositionDecl *CreateDeserialized(ASTContext &C, GlobalDeclID ID, unsigned NumBindings); - ArrayRef bindings() const { -return llvm::ArrayRef(getTrailingObject

[clang] [Clang][P1061] Add stuctured binding packs (PR #121417)

@@ -951,28 +959,124 @@ Sema::ActOnDecompositionDeclarator(Scope *S, Declarator &D, return New; } +// CheckBindingsCount +// - Checks the arity of the structured bindings +// - Creates the resolved pack expr if there is +//one +static bool CheckBindingsCount(Sema &S, D

[clang] [Clang][P1061] Add stuctured binding packs (PR #121417)

@@ -951,28 +959,124 @@ Sema::ActOnDecompositionDeclarator(Scope *S, Declarator &D, return New; } +// CheckBindingsCount zygoloid wrote: We [don't start function comments with the function name](https://llvm.org/docs/CodingStandards.html#commenting:~:text=

[clang] [Clang][Sema] Reject declaring an alias template with the same name as its template parameter. (PR #123533)

@@ -13464,6 +13464,14 @@ Decl *Sema::ActOnAliasDeclaration(Scope *S, AccessSpecifier AS, } TemplateParameterList *TemplateParams = TemplateParamLists[0]; +// Check shadowing of a template parameter name +for (NamedDecl *TP : TemplateParams->asArray()) { +

[clang] [Clang][P1061] Add stuctured binding packs (PR #121417)

@@ -951,28 +959,124 @@ Sema::ActOnDecompositionDeclarator(Scope *S, Declarator &D, return New; } +// CheckBindingsCount +// - Checks the arity of the structured bindings +// - Creates the resolved pack expr if there is +//one +static bool CheckBindingsCount(Sema &S, D

[clang] [Clang][P1061] Add stuctured binding packs (PR #121417)

@@ -1099,6 +1099,13 @@ def err_lambda_capture_misplaced_ellipsis : Error< "the name of the capture">; def err_lambda_capture_multiple_ellipses : Error< "multiple ellipses in pack capture">; +def err_binding_multiple_ellipses : Error< + "multiple ellipses in structured bind

[clang] [Clang][P1061] Add stuctured binding packs (PR #121417)

@@ -5321,6 +5321,59 @@ class BuiltinBitCastExpr final } }; +// Represents an unexpanded pack where the list of expressions are +// known. These are used when structured bindings introduce a pack. +class ResolvedUnexpandedPackExpr final zygoloid wrote: This

[clang] [llvm] [Clang] restrict use of attribute names reserved by the C++ standard (PR #106036)

zygoloid wrote: Oh, I see, you're suggesting we remove the `getStdNamespace` check from this PR. Yeah, I think that's reasonable. But I'd somewhat question whether this PR and warning really has anything to do with the attribute names being "reserved" at that point -- we're not checking wheth

[clang] [C++20] Destroying delete and deleted destructors (PR #118800)

@@ -2855,6 +2855,11 @@ class CXXDestructorDecl : public CXXMethodDecl { return getCanonicalDecl()->OperatorDeleteThisArg; } + /// Will this destructor ever be called when considering which deallocation + /// function is associated with the destructor? Can optionally be

[clang] [C++20] Destroying delete and deleted destructors (PR #118800)

https://github.com/zygoloid approved this pull request. LG other than the function name. https://github.com/llvm/llvm-project/pull/118800 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commit

[clang] [C++20] Destroying delete and deleted destructors (PR #118800)

https://github.com/zygoloid edited https://github.com/llvm/llvm-project/pull/118800 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [Clang] Add "extend lifetime" flags and release note (PR #110000)

https://github.com/zygoloid commented: New flag name LGTM. https://github.com/llvm/llvm-project/pull/11 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [Clang] Add "extend lifetime" flags and release note (PR #110000)

@@ -412,6 +412,20 @@ New Compiler Flags only for thread-local variables, and none (which corresponds to the existing ``-fno-c++-static-destructors`` flag) skips all static destructors registration. +- The ``-fextend-variable-liveness`` flag has been added to allow for imp

[clang] [Clang] Add "extend lifetime" flags and release note (PR #110000)

https://github.com/zygoloid edited https://github.com/llvm/llvm-project/pull/11 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [C++20] Destroying delete and deleted destructors (PR #118800)

@@ -1200,21 +1200,35 @@ CanThrowResult Sema::canThrow(const Stmt *S) { case Expr::CXXDeleteExprClass: { auto *DE = cast(S); -CanThrowResult CT; +CanThrowResult CT = CT_Cannot; QualType DTy = DE->getDestroyedType(); if (DTy.isNull() || DTy->isDependentTy

[clang] [C++20] Destroying delete and deleted destructors (PR #118800)

https://github.com/zygoloid edited https://github.com/llvm/llvm-project/pull/118800 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [C++20] Destroying delete and deleted destructors (PR #118800)

https://github.com/zygoloid edited https://github.com/llvm/llvm-project/pull/118800 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] Resolving issue #119101 (PR #119143)

zygoloid wrote: Did you mean a different issue than #119101? It's not clear to me what connection this PR has to that issue. It's not clear to me that there's an issue to be solved here. Under `-pedantic-errors`, clang [already produces an error](https://godbolt.org/z/h6oKarex9) on examples l

[clang] Switch builtin strings to use string tables (PR #118734)

https://github.com/zygoloid approved this pull request. LGTM too. I do wonder if we can make tablegen generate the data directly in the desired format here (perhaps with some additional `.td` files to define exactly which files we want to include in which targets and to define the placeholder

  1   2   3   4   5   6   7   8   9   10   >