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
@@ -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
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
@@ -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
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
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
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,
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
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
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
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
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
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
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
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
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
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
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@
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
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
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
@@ -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
@@ -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
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
@@ -1554,7 +1554,10 @@ def fstrict_flex_arrays_EQ : Joined<["-"],
"fstrict-flex-arrays=">, Group,
NormalizedValuesScope<"LangOptions::StrictFlexArraysLevelKind">,
NormalizedValues<["Default", "OneZeroOrIncomplete", "ZeroOrIncomplete",
"IncompleteOnly"]>,
- HelpText<"Enabl
@@ -1554,7 +1554,10 @@ def fstrict_flex_arrays_EQ : Joined<["-"],
"fstrict-flex-arrays=">, Group,
NormalizedValuesScope<"LangOptions::StrictFlexArraysLevelKind">,
NormalizedValues<["Default", "OneZeroOrIncomplete", "ZeroOrIncomplete",
"IncompleteOnly"]>,
- HelpText<"Enabl
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
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
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
@@ -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,
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
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
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
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
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
@@ -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
@@ -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
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
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-
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
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
@@ -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
@@ -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
@@ -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
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
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 `
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
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
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
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
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
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
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
@@ -243,10 +243,11 @@
// RUN: not %clang_cl /source-charset:utf-16 -### -- %s 2>&1 | FileCheck
-check-prefix=source-charset-utf-16 %s
// source-charset-utf-16: invalid value 'utf-16' in '/source-charset:utf-16'
-// /execution-charset: should warn on everything except UTF-8.
-
@@ -416,8 +416,7 @@ Builtin Macros
``__clang_literal_encoding__``
Defined to a narrow string literal that represents the current encoding of
narrow string literals, e.g., ``"hello"``. This macro typically expands to
- "UTF-8" (but may change in the future if the
- ``-fexe
@@ -491,6 +491,9 @@ class Triple {
/// For example, "fooos1.2.3" would return "1.2.3".
StringRef getEnvironmentVersionString() const;
+ /// getSystemCharset - Get the system charset of the triple.
+ StringRef getSystemCharset() const;
+
zygoloid wrote:
@@ -7245,6 +7245,11 @@ let Visibility = [CC1Option, CC1AsOption, FC1Option] in {
def tune_cpu : Separate<["-"], "tune-cpu">,
HelpText<"Tune for a specific cpu type">,
MarshallingInfoString>;
+def fexec_charset : Separate<["-"], "fexec-charset">, MetaVarName<"">,
+ HelpText
@@ -0,0 +1,35 @@
+// RUN: %clang_cc1 %s -emit-llvm -triple s390x-none-zos -fexec-charset
IBM-1047 -o - | FileCheck %s
zygoloid wrote:
Should there be tests here for wide (`L`-prefixed) character and string
literals too?
https://github.com/llvm/llvm-project/pul
https://github.com/zygoloid approved this pull request.
LGTM
https://github.com/llvm/llvm-project/pull/142713
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
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/
zygoloid wrote:
@PiotrZSL @5chmidti @HerrCai0907 Ping again. This has been waiting for review
for a few months, could someone take a look?
https://github.com/llvm/llvm-project/pull/130369
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https:/
@@ -143,3 +143,8 @@ namespace fold_initializer {
const float A::f = __builtin_is_constant_evaluated();
static_assert(fold(A::f == 1.0f));
}
+
+struct GH99680 {
+ static const int x = 1/(1-__builtin_is_constant_evaluated()); //
expected-error {{in-class initializer for sta
@@ -143,3 +143,8 @@ namespace fold_initializer {
const float A::f = __builtin_is_constant_evaluated();
static_assert(fold(A::f == 1.0f));
}
+
+struct GH99680 {
+ static const int x = 1/(1-__builtin_is_constant_evaluated()); //
expected-error {{in-class initializer for sta
@@ -143,3 +143,8 @@ namespace fold_initializer {
const float A::f = __builtin_is_constant_evaluated();
static_assert(fold(A::f == 1.0f));
}
+
+struct GH99680 {
+ static const int x = 1/(1-__builtin_is_constant_evaluated()); //
expected-error {{in-class initializer for sta
@@ -143,3 +143,8 @@ namespace fold_initializer {
const float A::f = __builtin_is_constant_evaluated();
static_assert(fold(A::f == 1.0f));
}
+
+struct GH99680 {
+ static const int x = 1/(1-__builtin_is_constant_evaluated()); //
expected-error {{in-class initializer for sta
https://github.com/zygoloid closed
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
zygoloid wrote:
> This will indeed break building the Linux kernel for x86_64 at least in my
> brief test
[...]
> ```
> In file included from arch/x86/kernel/acpi/wakeup_64.S:11:
> arch/x86/include/asm/nospec-branch.h:80:7: warning: '$' in identifier; did
> you mean to enable '-fdollars-in-iden
zygoloid wrote:
(I guess we could also warn if an object-like macro is expanded and the macro
name is preceded or followed by a `$` with no whitespace, since that would also
behave differently under `-fdollars-in-identifiers`, but I suspect that's not
worth worrying about in practice.)
https:
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/5] Switch misc-confusable-identifiers check to a faster
algori
@@ -181,42 +160,105 @@ void ConfusableIdentifierCheck::check(
if (!ND)
return;
- IdentifierInfo *NDII = ND->getIdentifier();
+ addDeclToCheck(ND, cast(ND->getDeclContext()
+->getNonTransparentContext()));
+
+ // Associate template p
@@ -181,42 +160,105 @@ void ConfusableIdentifierCheck::check(
if (!ND)
return;
- IdentifierInfo *NDII = ND->getIdentifier();
+ addDeclToCheck(ND, cast(ND->getDeclContext()
+->getNonTransparentContext()));
+
+ // Associate template p
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/6] Switch misc-confusable-identifiers check to a faster
algori
@@ -453,7 +450,7 @@ void ClassifyRefs::VisitCallExpr(CallExpr *CE) {
const auto *UO = dyn_cast(Ex);
if (UO && UO->getOpcode() == UO_AddrOf)
Ex = UO->getSubExpr();
- classify(Ex, Ignore);
+ classify(Ex, Use);
zygoloid wrote:
> Your
@@ -453,7 +450,7 @@ void ClassifyRefs::VisitCallExpr(CallExpr *CE) {
const auto *UO = dyn_cast(Ex);
if (UO && UO->getOpcode() == UO_AddrOf)
Ex = UO->getSubExpr();
- classify(Ex, Ignore);
+ classify(Ex, Use);
zygoloid wrote:
I beli
https://github.com/zygoloid requested changes to this pull request.
https://github.com/llvm/llvm-project/pull/147221
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -453,7 +450,7 @@ void ClassifyRefs::VisitCallExpr(CallExpr *CE) {
const auto *UO = dyn_cast(Ex);
if (UO && UO->getOpcode() == UO_AddrOf)
Ex = UO->getSubExpr();
- classify(Ex, Ignore);
+ classify(Ex, Use);
zygoloid wrote:
That s
https://github.com/zygoloid approved this pull request.
Thanks!
https://github.com/llvm/llvm-project/pull/147898
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/zygoloid approved this pull request.
https://github.com/llvm/llvm-project/pull/147898
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/zygoloid commented:
Thanks, LGTM
https://github.com/llvm/llvm-project/pull/147898
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -27,7 +27,7 @@ int const_use(const int i);
void f(int a) {
int i;
const_ref_use(i); // expected-warning {{variable 'i' is
uninitialized when passed as a const reference argument here}}
- int j = j + const_ref_use(j); // expected-warning {{variable 'j' is
u
@@ -1580,13 +1570,21 @@ class UninitValsDiagReporter : public
UninitVariablesHandler {
// guaranteed to produce them in line/column order, this will provide
// a stable ordering.
llvm::sort(*vec, [](const UninitUse &a, const UninitUse &b) {
+ /
https://github.com/zygoloid edited
https://github.com/llvm/llvm-project/pull/147898
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -14544,6 +14538,23 @@ EvaluateComparisonBinaryOperator(EvalInfo &Info, const
BinaryOperator *E,
(LHSValue.Base && isZeroSized(RHSValue)))
return DiagComparison(
diag::note_constexpr_pointer_comparison_zero_sized);
+ // A constexpr-unknown
https://github.com/zygoloid approved this pull request.
https://github.com/llvm/llvm-project/pull/148336
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/zygoloid approved this pull request.
https://github.com/llvm/llvm-project/pull/148337
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
4201 - 4285 of 4285 matches
Mail list logo
