| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
constructing a lookup table.
Previously, buildLookup would add lookup table entries for each item lexically
within the DC, and adding the first entry with a given name would trigger the
external source to add all its entries with that name. Then buildLookup would
carry on and re-add those entries all over again.
Instead, follow a simple rule: a declaration from an external source is only
ever made visible by the external source. One exception to this: since we don't
usually build a lookup table for the TU in C, and we never serialize one, we
don't expect the external source to provide lookups in the TU in C, so we build
those ones ourselves.
llvm-svn: 184696
|
| |
|
|
|
|
|
|
|
|
| |
There's still a problem here - since we're not appropriately using the
signedness/range of the enum to chooset the encoding and emission of
enumerators, but GCC has some bugs around this too so I assume that's
not /such/ a high priority though I may get to it soon out of
completeness.
llvm-svn: 184695
|
| |
|
|
|
|
| |
The assembly generation testing has been moved to an LLVM test case.
llvm-svn: 184693
|
| |
|
|
| |
llvm-svn: 184689
|
| |
|
|
|
|
|
|
| |
Original patch by Fariborz Jahanian; extended by me.
Fixes rdar://14124644
llvm-svn: 184688
|
| |
|
|
|
|
|
| |
whether they replace any existing lookups in the context, rather than
accumulating a bunch of lookup results referring to the same entity.
llvm-svn: 184679
|
| |
|
|
|
|
| |
follow.
llvm-svn: 184678
|
| |
|
|
| |
llvm-svn: 184677
|
| |
|
|
|
|
|
| |
so that -Wdocumentation-unknown-command does not warn on these commands.
Fixes PR16092.
llvm-svn: 184676
|
| |
|
|
|
|
| |
Patch by Robert Wilhelm.
llvm-svn: 184675
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
when specifying --coverage (or related) flags.
The system for doing this was based on the old LLVM-hosted profile_rt
library, and hadn't been updated for Linux to use the new compiler-rt
library. Also, it couldn't possibly work on multiarch or biarch systems
in many cases. The whole thing now works much the same as the sanitizer
libraries that are built and used out of the compiler-rt repo.
Note that other target OSes haven't been updated because I don't know if
they're doing anything special with the installation path of profile_rt.
I suspect however that *all* of these are wrong and would encourage
maintainers of each target to take a hard look at how compiler-rt
runtime libraries are linked on their platforms.
llvm-svn: 184666
|
| |
|
|
|
|
|
|
|
|
|
| |
to build and one had grown out of sync. Put this list in a variable so
this doesn't happen again.
The whole thing here is somewhat suspicious as we don't support 32-bit
environments with a 64-bit bi-arch capable compiler, but none have
complained yet about this so I'm just leaving it alone.
llvm-svn: 184665
|
| |
|
|
| |
llvm-svn: 184663
|
| |
|
|
|
|
|
|
| |
verifies that we run the assembler and linker in the correct mode, and
that we can successfully use a bi-arch variant of a GCC installation in
a generic cross compilation invocation of Clang.
llvm-svn: 184662
|
| |
|
|
| |
llvm-svn: 184661
|
| |
|
|
|
|
|
| |
Allow the comments in the FriendObjectKind enumerator-list show up in
doxygen. Also, some small readability improvements in related functions.
llvm-svn: 184657
|
| |
|
|
|
|
|
|
|
| |
Remove unneeded member in CommentSema, add a test for the XML schema (the
schema already allowed multiple paragraphs in <ResultDiscussion>, but there
were no tests for that), fix HTML generation (it is not allowed to have <p>
inside <dl>).
llvm-svn: 184652
|
| |
|
|
|
|
| |
Patch by Ismail Pazarbasi!
llvm-svn: 184650
|
| |
|
|
| |
llvm-svn: 184648
|
| |
|
|
|
|
| |
and parameter packs
llvm-svn: 184644
|
| |
|
|
| |
llvm-svn: 184640
|
| |
|
|
|
|
| |
a typo that caused a runtime assertion after firing diagnosis for class definitions, with the 'template' keyword as template header, in friend declarations.
llvm-svn: 184634
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There are fundamentally two different things that were getting conflated
here.
1) A bi-arch GCC toolchain install. This is not a full blown cross
compiler, but it supports targetting both 32-bit and 64-bit variants
of the same architecture using multilib OS installs and runtimes.
2) A "multiarch" Debian OS/runtime layout that lays out the libraries,
headers, etc as-if there were going to be a full blown cross compiler
even when in reality it is just a bi-arch GCC targeting two variants.
Also, these tend to use oddly "canonicalized" triples without the
vendor in them unlike the typical cross compiler runtime library
search that vanilla GCC cross compilers perform.
Now, when we mean the bi-arch nature of GCC accomplished with just
a suffix or tweak to the GCC paths, we say 'Biarch' or something
related. When we mean the Debian layout of includes and libraries, we
say multiarch or reference the multiarch triple.
In the process of reading and often renaming stuff in all these places,
also reformat with clang-format. No functionality change should be going
on here, this is just tidying up.
llvm-svn: 184632
|
| |
|
|
|
|
|
|
|
|
|
|
| |
The problem with r183462 was that we assumed that a diagnostic id of
zero would be silent.
This small correction to CheckDerivedToBaseConversion changes it's
behavior to omit the diagnostic when given a diagnostic id of zero.
This fix passes the test case added in r184402.
llvm-svn: 184631
|
| |
|
|
| |
llvm-svn: 184629
|
| |
|
|
| |
llvm-svn: 184625
|
| |
|
|
|
|
|
|
|
|
|
| |
should be entered
This fixes false positives by allowing us to know that a loop is always entered if
the collection count method returns a positive value and vice versa.
Addresses radar://14169391.
llvm-svn: 184618
|
| |
|
|
|
|
|
|
| |
Add the back edge info by creating a basic block, marked as loop target. This is
consistent with how other loops are processed, but was omitted from
VisitObjCForCollectionStmt.
llvm-svn: 184617
|
| |
|
|
|
|
| |
types and function pointer arrays.
llvm-svn: 184616
|
| |
|
|
|
|
| |
No functionality change intended.
llvm-svn: 184614
|
| |
|
|
|
|
| |
Reviewed by Richard Smith.
llvm-svn: 184612
|
| |
|
|
| |
llvm-svn: 184611
|
| |
|
|
|
|
|
| |
commands. Render them properly in XML output.
// rdar://14207725
llvm-svn: 184610
|
| |
|
|
|
|
|
|
| |
Empty structs are ignored for parameter passing purposes, but va_arg was
incrementing the pointer anyway which could lead to va_list getting out of
sync.
llvm-svn: 184605
|
| |
|
|
|
|
|
|
|
|
|
|
| |
According to the Itanium ABI (3.1.1), types with non-trivial copy constructors
passed by value should be passed indirectly, with the caller creating a
temporary.
We got this mostly correct, but forgot that empty structs can have non-trivial
constructors too and passed them incorrectly. This simply reverses the order of
the check.
llvm-svn: 184603
|
| |
|
|
|
|
| |
even when the NVPTX target is not built
llvm-svn: 184601
|
| |
|
|
| |
llvm-svn: 184598
|
| |
|
|
| |
llvm-svn: 184596
|
| |
|
|
|
|
| |
given -disable-free. (Reviewed by John McCall over IRC.)
llvm-svn: 184595
|
| |
|
|
|
|
| |
later require definitions
llvm-svn: 184594
|
| |
|
|
|
|
| |
Fixes PR16292.
llvm-svn: 184581
|
| |
|
|
| |
llvm-svn: 184578
|
| |
|
|
| |
llvm-svn: 184577
|
| |
|
|
|
|
| |
Make that option the default for LLVM style.
llvm-svn: 184563
|
| |
|
|
|
|
|
|
|
|
| |
Per review from Anna, this really should have been two commits, and besides
it's causing problems on our internal buildbot. Reverting until these have
been worked out.
This reverts r184511 / 98123284826bb4ce422775563ff1a01580ec5766.
llvm-svn: 184561
|
| |
|
|
|
|
|
|
|
| |
a system module.
This prevents -pedantic from causing warnings in the system headers
used to create modules. Fixes <rdar://problem/14201171>.
llvm-svn: 184560
|
| |
|
|
| |
llvm-svn: 184559
|
| |
|
|
|
|
| |
the right polymorphic overload to use.
llvm-svn: 184558
|
| |
|
|
|
|
|
| |
MSVC's debug runtime prints assertion failures in wide characters, which
gtest doesn't understand.
llvm-svn: 184544
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Itanium destroys them in the caller at the end of the full expression,
but MSVC destroys them in the callee. This is further complicated by
the need to emit EH-only destructor cleanups in the caller.
This should help clang compile MSVC's debug iterators more correctly.
There is still an outstanding issue in PR5064 of a memcpy emitted by the
LLVM backend, which is not correct for C++ records.
Fixes PR16226.
Reviewers: rjmccall
Differential Revision: http://llvm-reviews.chandlerc.com/D929
llvm-svn: 184543
|