llvm-svn: 172697

This is inspired by a number of false positives in real code, including
PR14968. I've added test cases reduced from these false positives to
test/Sema/unused-expr.c, as well as corresponding test cases that pass the
offending expressions as arguments to a no-op macro to ensure that we do warn
there.

This also removes my previous tweak from r166522/r166534, so that we warn on
unused cast expressions in macro arguments.

There were several test cases that were using -Wunused-value to test general
diagnostic emission features; I changed those to use other warnings or warn on
a macro argument expression. I stared at the test case for PR14399 for a while
with Richard Smith and we believe the new test case exercises the same
codepaths as before.

llvm-svn: 172696

llvm-svn: 172695

literals. As suggested by Sean Silva.

llvm-svn: 172694

llvm-svn: 172693

in the LangRef).

llvm-svn: 172692

it apart from [[gnu::noreturn]] / __attribute__((noreturn)), since their
semantics are not equivalent (for instance, we treat [[gnu::noreturn]] as
affecting the function type, whereas [[noreturn]] does not).

llvm-svn: 172691

expressions which have undefined behavior due to multiple unsequenced
modifications or an unsequenced modification and use of a variable.

llvm-svn: 172690

llvm-svn: 172689

Let targets use it.

llvm-svn: 172688

Move the early if-conversion pass into this group.

ILP optimizations usually need to find the right balance between
register pressure and ILP using the MachineTraceMetrics analysis to
identify critical paths and estimate other costs. Such passes should run
together so they can share dominator tree and loop info analyses.

Besides if-conversion, future passes to run here here could include
expression height reduction and ARM's MLxExpansion pass.

llvm-svn: 172687

undefined, and don't find methods or protocols within those protocol
definitions. This completes <rdar://problem/10634711>.

llvm-svn: 172686

but I cannot reproduce the problem and have scrubed my sources and
even tested with llvm-lit -v --vg.

The Mips RDHWR (Read Hardware Register) instruction was not 
tested for assembler or dissassembler consumption. This patch
adds that functionality.

Contributer: Vladimir Medic
 
llvm-svn: 172685

llvm-svn: 172684

produce more inline layout metadata. // rdar://12752901

llvm-svn: 172683

llvm-svn: 172682

llvm-svn: 172681

ambiguous term 'legal'.

Suggested by Andrew Booker. Thanks Andrew!

llvm-svn: 172680

if we can see the elements of the arrays.

for example:

 NSDictionary *dict = [NSDictionary dictionaryWithObjects:[NSArray arrayWithObjects:@"1", @"2", nil] forKeys:[NSArray arrayWithObjects:@"A", @"B", nil]];

-->

 NSDictionary *dict = @{ @"A" : @"1", @"B" : @"2" };

rdar://12428166

llvm-svn: 172679

llvm-svn: 172678

Reported on IRC by _savage

llvm-svn: 172677

llvm-svn: 172676

llvm-svn: 172675

llvm-svn: 172674

llvm-svn: 172673

echristo already fixed this in r172649, but I'll leave the reformatting in
since I'm in the blame history for it now anyway.

llvm-svn: 172672

vector<bool> is specialized and the existing general summary for vectors would lie to the user.
Tackling libstdc++ and synthetic children is the following, less critical, part of this task

llvm-svn: 172671

llvm-svn: 172670

llvm-svn: 172669

Rewrapping courtesy of clang-format.

llvm-svn: 172668

This fixes pr14946. The problem was that the linkage computation was done too
early, so things like "extern int a;" would be given external linkage, even if
a previous declaration was static.

llvm-svn: 172667

Several of the intrinsic headers were using plain non-reserved identifiers.
C++11 17.6.4.3.2 [global.names] p1 reservers names containing a double
begining with an underscore followed by an uppercase letter for any use.

I think I got them all, but open to being corrected. For the most part I
didn't bother updating function-like macro parameter names because I don't
believe they're subject to any such collission - though some function-like
macros already follow this convention (I didn't update them in part because
the churn was more significant as several function-like macros use the double
underscore prefixed version of the same name as a parameter in their
implementation)

llvm-svn: 172666

consider (sub)module visibility.

The bulk of this change replaces myriad hand-rolled loops over the
linked list of Objective-C categories/extensions attached to an
interface declaration with loops using one of the four new category
iterator kinds:

  visible_categories_iterator: Iterates over all visible categories
  and extensions, hiding any that have their "hidden" bit set. This is
  by far the most commonly used iterator.

  known_categories_iterator: Iterates over all categories and
  extensions, ignoring the "hidden" bit. This tends to be used for
  redeclaration-like traversals.

  visible_extensions_iterator: Iterates over all visible extensions,
  hiding any that have their "hidden" bit set.

  known_extensions_iterator: Iterates over all extensions, whether
  they are visible to normal name lookup or not.

The effect of this change is that any uses of the visible_ iterators
will respect module-import visibility. See the new tests for examples.

Note that the old accessors for categories and extensions are gone;
there are *Raw() forms for some of them, for those (few) areas of the
compiler that have to manipulate the linked list of categories
directly. This is generally discouraged.

Part two of <rdar://problem/10634711>.
 

llvm-svn: 172665

llvm-svn: 172664

Changing the Python reference document to be more explicit in discouraging usage of lldb.{debugger,...} convenience variables for formatters and other non-interactive Python extensions

llvm-svn: 172663

llvm-svn: 172662

llvm-svn: 172661

llvm-svn: 172660

llvm-svn: 172659

Moving the X86CostTable to a common place, so that other back-ends
can share the code. Also simplifying it a bit and commoning up
tables with one and two types on operations.

llvm-svn: 172658