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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@220244 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@156826 91177308-0d34-0410-b5e6-96231b3b80d8
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;").
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@154068 91177308-0d34-0410-b5e6-96231b3b80d8
'is an extension'. The former is inappropriate and confusing when building with
-Werror/-pedantic-errors.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@147357 91177308-0d34-0410-b5e6-96231b3b80d8
type..." with "initializing <type> with an expression of type...",
which reads better. Thanks to John for the improved wording.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@100873 91177308-0d34-0410-b5e6-96231b3b80d8
destination type for initialization, assignment, parameter-passing,
etc. The main issue fixed here is that we used rather confusing
wording for diagnostics such as
t.c:2:9: warning: initializing 'char const [2]' discards qualifiers,
expected 'char *' [-pedantic]
char *name = __func__;
^ ~~~~~~~~
We're not initializing a 'char const [2]', we're initializing a 'char
*' with an expression of type 'char const [2]'. Similar problems
existed for other diagnostics in this area, so I've normalized them all
with more precise descriptive text to say what we're
initializing/converting/assigning/etc. from and to. The warning for
the code above is now:
t.c:2:9: warning: initializing 'char *' from an expression of type
'char const [2]' discards qualifiers [-pedantic]
char *name = __func__;
^ ~~~~~~~~
Fixes <rdar://problem/7447179>.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@100832 91177308-0d34-0410-b5e6-96231b3b80d8
small bug fixes in SemaInit, switch over SemaDecl to use it more often, and
change a bunch of diagnostics which are different with the new initialization
code.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@91767 91177308-0d34-0410-b5e6-96231b3b80d8
- This is designed to make it obvious that %clang_cc1 is a "test variable"
which is substituted. It is '%clang_cc1' instead of '%clang -cc1' because it
can be useful to redefine what gets run as 'clang -cc1' (for example, to set
a default target).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@91446 91177308-0d34-0410-b5e6-96231b3b80d8
This patch isn't quite ideal in that it eliminates the warning for
constructs like "int a = {1};", where the braces are in fact redundant.
However, that would have required a bunch of refactoring, and it's
much less likely to cause confusion compared to redundant nested braces.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@71939 91177308-0d34-0410-b5e6-96231b3b80d8
braces. We now build the appropriate fully-structured initializer list
for such things. Per PR3618, verified that we're getting the right
code generation.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@67353 91177308-0d34-0410-b5e6-96231b3b80d8
extension. The interaction with designated initializers is a
bit... interesting... but we follow GNU's lead and don't permit too
much crazy code in this area.
Also, make the "excess initializers" error message a bit more
informative.
Addresses PR2561: http://llvm.org/bugs/show_bug.cgi?id=2561
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@63785 91177308-0d34-0410-b5e6-96231b3b80d8
error, since both C99 and C++ consider it an error. For reference, GCC
makes this a warning while G++ makes it an error.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@63435 91177308-0d34-0410-b5e6-96231b3b80d8
The approach I've taken in this patch is relatively straightforward,
although the code itself is non-trivial. Essentially, as we process
an initializer list we build up a fully-explicit representation of the
initializer list, where each of the subobject initializations occurs
in order. Designators serve to "fill in" subobject initializations in
a non-linear way. The fully-explicit representation makes initializer
lists (both with and without designators) easy to grok for codegen and
later semantic analyses. We keep the syntactic form of the initializer
list linked into the AST for those clients interested in exactly what
the user wrote.
Known limitations:
- Designating a member of a union that isn't the first member may
result in bogus initialization (we warn about this)
- GNU array-range designators are not supported (we warn about this)
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@63242 91177308-0d34-0410-b5e6-96231b3b80d8
is an array type not a pointer type. This requires updating some
diags that change and updating the code generator to handle the
proper form of strings.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@46941 91177308-0d34-0410-b5e6-96231b3b80d8
This is a modified version of a patch by Eli Friedman. This version passes all of the clang tests and supports vectors:-)
Note that Eli and I are still unsatisfied the implementation of CheckInitializerListTypes(). We'd like to find a more elegant implementation. Nevertheless, this is a complex part of the standard (and may be hard to simplify). Since the complexity is localized to this routine, we can iterate without too much disruption:-)
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@46339 91177308-0d34-0410-b5e6-96231b3b80d8
it from several places. This merges the diagnostics, making them more
uniform and fewer in number. This also simplifies and cleans up the code.
Some highlights:
1. This removes a bunch of very-similar diagnostics.
2. This renames AssignmentCheckResult -> AssignConvertType
3. This merges PointerFromInt + IntFromPointer which were always treated the same.
4. This updates a bunch of test cases that have minor changes to the produced diagnostics.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@45589 91177308-0d34-0410-b5e6-96231b3b80d8
unsigned char asso_values[] = { 34 };
int legal2() {
return asso_values[0];
}
The code that creates the new constant array type was operating on the original type.
As a result, the constant type being generated was "unsigned char [1][]" (which is wrong).
The fix is to operate on the element type - in this case, the correct type is "unsigned char [1]"
I added this case to array-init.c, which clearly didn't catch this bogosity...
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@43112 91177308-0d34-0410-b5e6-96231b3b80d8
Richard Smith