[clang] Remove rdar links; NFC

We have a new policy in place making links to private resources
something we try to avoid in source and test files. Normally, we'd
organically switch to the new policy

[clang] Remove rdar links; NFC

We have a new policy in place making links to private resources
something we try to avoid in source and test files. Normally, we'd
organically switch to the new policy rather than make a sweeping change
across a project. However, Clang is in a somewhat special circumstance
currently: recently, I've had several new contributors run into rdar
links around test code which their patch was changing the behavior of.
This turns out to be a surprisingly bad experience, especially for
newer folks, for a handful of reasons: not understanding what the link
is and feeling intimidated by it, wondering whether their changes are
actually breaking something important to a downstream in some way,
having to hunt down strangers not involved with the patch to impose on
them for help, accidental pressure from asking for potentially private
IP to be made public, etc. Because folks run into these links entirely
by chance (through fixing bugs or working on new features), there's not
really a set of problematic links to focus on -- all of the links have
basically the same potential for causing these problems. As a result,
this is an omnibus patch to remove all such links.

This was not a mechanical change; it was done by manually searching for
rdar, radar, radr, and other variants to find all the various
problematic links. From there, I tried to retain or reword the
surrounding comments so that we would lose as little context as
possible. However, because most links were just a plain link with no
supporting context, the majority of the changes are simple removals.

Differential Review: https://reviews.llvm.org/D158071

show more ...

[C23] Rename C2x->C23 in diagnostics

This renames C2x to C23 in diagnostic identifiers and messages. The
changes were made mechanically.

Revert "Remove rdar links; NFC"

This reverts commit d618f1c3b12effd0c2bdb7d02108d3551f389d3d.
This commit wasn't reviewed ahead of time and significant concerns were
raised immediately after it land

Revert "Remove rdar links; NFC"

This reverts commit d618f1c3b12effd0c2bdb7d02108d3551f389d3d.
This commit wasn't reviewed ahead of time and significant concerns were
raised immediately after it landed. According to our developer policy
this warrants immediate revert of the commit.

https://llvm.org/docs/DeveloperPolicy.html#patch-reversion-policy

Differential Revision: https://reviews.llvm.org/D155509

show more ...

Remove rdar links; NFC

This removes links to rdar, which is an internal bug tracker that the
community doesn't have visibility into.

See further discussion at:
https://discourse.llvm.org/t/code-rev

Remove rdar links; NFC

This removes links to rdar, which is an internal bug tracker that the
community doesn't have visibility into.

See further discussion at:
https://discourse.llvm.org/t/code-review-reminder-about-links-in-code-commit-messages/71847

show more ...

[C2x] Implement support for empty brace initialization (WG14 N2900 and WG14 N3011)

This implements support for allowing {} to consistently zero initialize
objects. We already supported most of this

[C2x] Implement support for empty brace initialization (WG14 N2900 and WG14 N3011)

This implements support for allowing {} to consistently zero initialize
objects. We already supported most of this work as a GNU extension, but
the C2x feature goes beyond what the GNU extension allowed.

The changes in this patch are:

* Removed the -Wgnu-empty-initializer warning group. The extension is
now a C2x extension warning instead. Note that use of
`-Wno-gnu-empty-initializer seems` to be quite low in the wild
(https://sourcegraph.com/search?q=context%3Aglobal+-file%3A.*test.*+%22-Wno-gnu-empty-initializer%22&patternType=standard&sm=1&groupBy=repo
which currently only gives 8 hits total), so this is not expected to
be an overly disruptive change. But I'm adding the clang vendors
review group just in case this expectation is wrong.
* Reworded the diagnostic wording to be about a C2x extension, added a
pre-C2x compat warning.
* Allow {} to zero initialize a VLA

This functionality is exposed as an extension in all older C modes
(same as the GNU extension was), but does *not* allow the extension for
VLA initialization in C++ due to concern about handling non-trivially
constructible types.

Differential Revision: https://reviews.llvm.org/D147349

show more ...

[Clang] Reword diagnostic for scope identifier with linkage

If the declaration of an identifier has block scope, and the identifier has
external or internal linkage, the declaration shall have no in

[Clang] Reword diagnostic for scope identifier with linkage

If the declaration of an identifier has block scope, and the identifier has
external or internal linkage, the declaration shall have no initializer for
the identifier.

Clang now gives a more suitable diagnosis for this case.
Fixes https://github.com/llvm/llvm-project/issues/57478

Signed-off-by: Jun Zhang <jun@junz.org>

Differential Revision: https://reviews.llvm.org/D133088

show more ...

Strengthen -Wint-conversion to default to an error

Clang has traditionally allowed C programs to implicitly convert
integers to pointers and pointers to integers, despite it not being
valid to do so

Strengthen -Wint-conversion to default to an error

Clang has traditionally allowed C programs to implicitly convert
integers to pointers and pointers to integers, despite it not being
valid to do so except under special circumstances (like converting the
integer 0, which is the null pointer constant, to a pointer). In C89,
this would result in undefined behavior per 3.3.4, and in C99 this rule
was strengthened to be a constraint violation instead. Constraint
violations are most often handled as an error.

This patch changes the warning to default to an error in all C modes
(it is already an error in C++). This gives us better security posture
by calling out potential programmer mistakes in code but still allows
users who need this behavior to use -Wno-error=int-conversion to retain
the warning behavior, or -Wno-int-conversion to silence the diagnostic
entirely.

Differential Revision: https://reviews.llvm.org/D129881

show more ...

Add prototypes to functions which need them; NFC

Recommit: Compress formatting of array type names (int [4] -> int[4])

Based on post-commit review discussion on
2bd84938470bf2e337801faafb8a67710f46429d with Richard Smith.

Other uses of forcing Ha

Recommit: Compress formatting of array type names (int [4] -> int[4])

Based on post-commit review discussion on
2bd84938470bf2e337801faafb8a67710f46429d with Richard Smith.

Other uses of forcing HasEmptyPlaceHolder to false seem OK to me -
they're all around pointer/reference types where the pointer/reference
token will appear at the rightmost side of the left side of the type
name, so they make nested types (eg: the "int" in "int *") behave as
though there is a non-empty placeholder (because the "*" is essentially
the placeholder as far as the "int" is concerned).

This was originally committed in 277623f4d5a672d707390e2c3eaf30a9eb4b075c

Reverted in f9ad1d1c775a8e264bebc15d75e0c6e5c20eefc7 due to breakages
outside of clang - lldb seems to have some strange/strong dependence on
"char [N]" versus "char[N]" when printing strings (not due to that name
appearing in DWARF, but probably due to using clang to stringify type
names) that'll need to be addressed, plus a few other odds and ends in
other subprojects (clang-tools-extra, compiler-rt, etc).

show more ...

Revert "Compress formatting of array type names (int [4] -> int[4])"

Looks like lldb has some issues with this - somehow it causes lldb to
treat a "char[N]" type as an array of chars (prints them ou

Revert "Compress formatting of array type names (int [4] -> int[4])"

Looks like lldb has some issues with this - somehow it causes lldb to
treat a "char[N]" type as an array of chars (prints them out
individually) but a "char [N]" is printed as a string. (even though the
DWARF doesn't have this string in it - it's something to do with the
string lldb generates for itself using clang)

This reverts commit 277623f4d5a672d707390e2c3eaf30a9eb4b075c.

show more ...

Compress formatting of array type names (int [4] -> int[4])

Based on post-commit review discussion on
2bd84938470bf2e337801faafb8a67710f46429d with Richard Smith.

Other uses of forcing HasEmptyPlac

Compress formatting of array type names (int [4] -> int[4])

Based on post-commit review discussion on
2bd84938470bf2e337801faafb8a67710f46429d with Richard Smith.

Other uses of forcing HasEmptyPlaceHolder to false seem OK to me -
they're all around pointer/reference types where the pointer/reference
token will appear at the rightmost side of the left side of the type
name, so they make nested types (eg: the "int" in "int *") behave as
though there is a non-empty placeholder (because the "*" is essentially
the placeholder as far as the "int" is concerned).

show more ...

[Sema] Put existing warning under -Wexcess-initializers

I have a follow-on patch that uses an alternative wording for
ext_excess_initializers in some cases. This patch puts it and
a couple of relat

[Sema] Put existing warning under -Wexcess-initializers

I have a follow-on patch that uses an alternative wording for
ext_excess_initializers in some cases. This patch puts it and
a couple of related warnings under their own -W option in order
to avoid a regression in Misc/warning-flags.c.

Differential Revision: https://reviews.llvm.org/D79244

show more ...

Switch C compilations to C11 by default.

This is long-since overdue, and matches GCC 5.0. This should also be
backwards-compatible, because we already supported all of C11 as an extension
in C99 mod

Switch C compilations to C11 by default.

This is long-since overdue, and matches GCC 5.0. This should also be
backwards-compatible, because we already supported all of C11 as an extension
in C99 mode.

llvm-svn: 220244

show more ...

Improved location for non-constant initializers diagnostics.

llvm-svn: 209466

Recognition of empty structures and unions is moved to semantic stage

Differential Revision: http://llvm-reviews.chandlerc.com/D586

llvm-svn: 183609

Fix assert if __extension__ or _Generic is used when initializing a char array from a string literal.

llvm-svn: 181174

PR13881: Add -Wzero-length-array for zero length array extension, and move it into -Wgnu.

llvm-svn: 164272

clang/test: [PR8833] Introduce the feature "LP64" to suppress LLP64-incompatible tests.

I think some of them could be rewritten to fit also LLP64.

llvm-svn: 163699

Improve some of the conversion warnings to fire on conversion to bool.

Moves the bool bail-out down a little in SemaChecking - so now
-Wnull-conversion and -Wliteral-conversion can fire when the tar

Improve some of the conversion warnings to fire on conversion to bool.

Moves the bool bail-out down a little in SemaChecking - so now
-Wnull-conversion and -Wliteral-conversion can fire when the target type is
bool.

Also improve the wording/details in the -Wliteral-conversion warning to match
the -Wconstant-conversion.

llvm-svn: 156826

show more ...

Enable warn_impcast_literal_float_to_integer by default.

This diagnostic seems to be production ready, it's just an oversight that it
wasn't turned on by default.

The test changes are a bit of a mi

Enable warn_impcast_literal_float_to_integer by default.

This diagnostic seems to be production ready, it's just an oversight that it
wasn't turned on by default.

The test changes are a bit of a mixed bag. Some tests that seemed like they
clearly didn't need to use this behavior have been modified not to use it.
Others that I couldn't be sure about, I added the necessary expected-warnings
to.

It's possible the diagnostic message could be improved to make it clearer that
this warning can be suppressed by using a value that won't lose precision when
converted to the target type (but can still be a floating point literal, such
as "bool b = 1.0;").

llvm-svn: 154068

show more ...

Don't warn about anonymous struct/union in C11.

Also, in C, call this a C11 extension rather than a GNU extension.

llvm-svn: 149695

The value of a const weak variable is not an integer constant.

llvm-svn: 147575

Change the diagnostics which said 'accepted as an extension' to instead say
'is an extension'. The former is inappropriate and confusing when building with
-Werror/-pedantic-errors.

llvm-svn: 147357

Add list initialization for complex numbers in C. Essentially, this allows "_Complex float x = {1.0f, 2.0f};". See changes to docs/LanguageExtensions.html for a longer description.

<rdar://problem

Add list initialization for complex numbers in C. Essentially, this allows "_Complex float x = {1.0f, 2.0f};". See changes to docs/LanguageExtensions.html for a longer description.

<rdar://problem/9397672>.

llvm-svn: 140090

show more ...

Implement the GNU C extension which permits the initialization of an
array from a constant array compound literal. Fixes PR9261.

llvm-svn: 126230