| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
| |
type..." with "initializing <type> with an expression of type...",
which reads better. Thanks to John for the improved wording.
llvm-svn: 100873
|
|
|
|
|
|
|
|
|
| |
the implicit template instantiations we need to perform. Otherwise, we
end up erroneously diagnosing static functions as used if they were
only used within an implicit template instantiation. Fixes a bunch of
spurious failures when building Clang with Clang.
llvm-svn: 100872
|
|
|
|
|
|
| |
type isn't dependent. Fixes rdar://problem/7838962.
llvm-svn: 100871
|
|
|
|
|
|
| |
attr constructor or destructor. Patch by Jean-Daniel Dupas!
llvm-svn: 100870
|
|
|
|
|
|
|
|
| |
precompiled headers and/or when reading the contents of the file into
memory. These checks seem to be causing spurious regression-test
failures on Windows.
llvm-svn: 100866
|
|
|
|
|
|
| |
for objc.
llvm-svn: 100865
|
|
|
|
| |
llvm-svn: 100864
|
|
|
|
|
|
| |
valid instantiations.
llvm-svn: 100836
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>.
llvm-svn: 100832
|
|
|
|
|
|
|
|
| |
consistent across
platforms (for this test).
llvm-svn: 100827
|
|
|
|
|
|
|
| |
This is still not an ideal solution, but should disable the check for other
targets where the value of O_CREAT is different.
llvm-svn: 100818
|
|
|
|
|
|
| |
other diagnostics
llvm-svn: 100817
|
|
|
|
|
|
|
|
| |
buildbot. I'm
looking into an alternate fix right now.
llvm-svn: 100816
|
|
|
|
|
|
|
| |
warning. It's not harmful to have such pointless declarations, and GCC
does not diagnose this issue consistently.
llvm-svn: 100814
|
|
|
|
|
|
| |
of c-style arguments. Completes radar 7445205.
llvm-svn: 100813
|
|
|
|
| |
llvm-svn: 100810
|
|
|
|
|
|
| |
variable declarations.
llvm-svn: 100809
|
|
|
|
|
|
| |
Fixes PR6752.
llvm-svn: 100806
|
|
|
|
|
|
|
|
| |
control-flow has
automatic storage. This matches the corresponding check for 'dispatch_once()'.
llvm-svn: 100803
|
|
|
|
| |
llvm-svn: 100801
|
|
|
|
|
|
|
|
|
|
| |
inline' functions
unless they are used. I discussed this with Daniel Dunbar, and we agreed that this
provides an inconsistent warnings experience for the user and that there were
genuine cases where we wouldn't want to do this optimization.
llvm-svn: 100800
|
|
|
|
|
|
|
|
|
| |
<tr1/hashtable> header, where a friend class template
std::tr1::__detail::_Map_base is declared with the wrong template
parameters. GCC doesn't catch the problem, so Clang does a little
back-flip to avoid diagnosing just this one instance of the problem.
llvm-svn: 100790
|
|
|
|
|
|
| |
parameters list for encoding.
llvm-svn: 100788
|
|
|
|
| |
llvm-svn: 100786
|
|
|
|
| |
llvm-svn: 100785
|
|
|
|
|
|
|
|
| |
instead of scribbling over random memory. Maybe.
Hopefully this fixes the -vg buildbot.
llvm-svn: 100784
|
|
|
|
|
|
|
| |
Declarator that depends on it. This fixes several redundant errors and bad
recoveries.
llvm-svn: 100779
|
|
|
|
| |
llvm-svn: 100778
|
|
|
|
| |
llvm-svn: 100776
|
|
|
|
| |
llvm-svn: 100775
|
|
|
|
| |
llvm-svn: 100773
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
__cxxabiv1::__fundamental_type_info in every translation
unit. Previously, we would perform name lookup for
__cxxabiv1::__fundamental_type_info at the end of IRGen for a each
translation unit, to determine whether it was present. If so, we we
produce type information for all of the fundamental types. However,
this name lookup causes PCH deserialization of a significant part of the
translation unit, which has a woeful impact on performance.
With this change, we now look at each record type after we've
generated its vtable to see if it is
__cxxabiv1::__fundamental_type_info. If so, we generate type info for
all of the fundamental types. This works because
__cxxabiv1::__fundamental_type_info should always have a key function
(typically the virtual destructor), that will be defined once in the
support library. The fundamental type information will end up there.
Fixes <rdar://problem/7840011>.
llvm-svn: 100772
|
|
|
|
| |
llvm-svn: 100770
|
|
|
|
| |
llvm-svn: 100753
|
|
|
|
| |
llvm-svn: 100750
|
|
|
|
|
|
| |
-dump-record-layouts a bit that Sema honors.
llvm-svn: 100747
|
|
|
|
| |
llvm-svn: 100746
|
|
|
|
|
|
| |
bit-field LValues to just store the base address of object containing the bit-field.
llvm-svn: 100745
|
|
|
|
|
|
| |
methods. wip.
llvm-svn: 100734
|
|
|
|
| |
llvm-svn: 100733
|
|
|
|
| |
llvm-svn: 100732
|
|
|
|
| |
llvm-svn: 100730
|
|
|
|
|
|
|
| |
parameter, explicitly ask the user to give it arguments. We used to
complain that it wasn't a type and expect the user to figure it out.
llvm-svn: 100729
|
|
|
|
|
|
| |
isNotEmpty calls.
llvm-svn: 100722
|
|
|
|
| |
llvm-svn: 100718
|
|
|
|
|
|
|
| |
code won't actually get used yet because we don't handle non-type
parameter packs, but when we do, this code should jump in and work.
llvm-svn: 100716
|
|
|
|
| |
llvm-svn: 100711
|
|
|
|
| |
llvm-svn: 100708
|
|
|
|
| |
llvm-svn: 100707
|
|
|
|
| |
llvm-svn: 100704
|