- Sep 13, 2011
-
-
Argyrios Kyrtzidis authored
llvm-svn: 139600
-
Argyrios Kyrtzidis authored
llvm-svn: 139599
-
Francois Pichet authored
In Microsoft mode, downgrade "goto into protected scope" from error to warning if we are jumping over a variable initialization via a goto. This fixes a few errors when parsing MFC code with clang. llvm-svn: 139595
-
Chandler Carruth authored
This deletes a bunch of crufty code, and allows more logic sharing between the analyzer and the warnings. llvm-svn: 139594
-
Chandler Carruth authored
CFGElement. This will allow greatly simplifying the logic in -Wreturn-type. llvm-svn: 139593
-
Chandler Carruth authored
location with a single comment rather than scattering it in three places. llvm-svn: 139592
-
John McCall authored
even on architectures that support unaligned access (which is the only way this is otherwise legal, given that ivars apparently do not honor alignment attributes). llvm-svn: 139590
-
Chandler Carruth authored
temporary objects and local variables. When detected, these split the block, marking the new one as having only the exit block as a successor. This prevents a large number of false positives in warnings sensitive to no-return constructs such as -Wreturn-type, and fixes the remainder of PR10063 along with several variations of this bug that had not been reported. The test cases are extended across the board to cover these patterns. This also checks in a stress test for these types of CFGs. The stress test declares some 32k variables, a mixture of no-return and normal destructors. Previously, this resulted in roughly 2500 CFG blocks, but didn't model any of the no-return destructors. With this patch, it results in over 33k blocks, many of them now unreachable. The nice thing about how the analyzer is set up? This causes *no* regression in performance of building the CFG. It actually in some cases makes it faster, as best I can benchmark. The analysis for -Wreturn-type (and any other that cares about no-return code paths) is technically slower now as it has to look at many more candidate blocks, but it computes the correct answer. I have more test cases to follow, I think they all work now. Also I have further work that should dramatically simplify analyses in the presence of no-return. llvm-svn: 139586
-
John McCall authored
llvm-svn: 139585
-
John McCall authored
atomic. This is probably something we should warn about. llvm-svn: 139584
-
John McCall authored
single code path. Use atomic loads and stores where necessary. Load and store anything of the appropriate size and alignment with primitive operations instead of going through the call. llvm-svn: 139580
-
Douglas Gregor authored
already provided. This required a little bit of clean-up in the way that VerifyDiagnosticsClient managed ownership of its underlying "primary" client, because now it will no longer always take ownership. llvm-svn: 139570
-
Douglas Gregor authored
but there is a corresponding umbrella header in a framework, build the module on-the-fly so it can be immediately loaded at the import statement. This is very much proof-of-concept code, with details to be fleshed out over time. llvm-svn: 139558
-
John McCall authored
modernization. No functionality change. llvm-svn: 139555
-
Caitlin Sadowski authored
llvm-svn: 139548
-
- Sep 12, 2011
-
-
Douglas Gregor authored
where the compiler will look for module files. Eliminates the egregious hack where we looked into the header search paths for modules. llvm-svn: 139538
-
Douglas Gregor authored
llvm-svn: 139523
-
Devang Patel authored
llvm-svn: 139521
-
Richard Trieu authored
llvm-svn: 139520
-
Douglas Gregor authored
llvm-svn: 139519
-
Devang Patel authored
llvm-svn: 139514
-
Argyrios Kyrtzidis authored
modifying directly for the preamble. This avoids an awful, hard to find, bug where "PreprocessorOpts.DisablePCHValidation = true" would be persistent for subsequent reparses of the translation unit which would result in defines, present in command-line but not in the PCH, being ignored. Fixes rdar://9615399. llvm-svn: 139512
-
Richard Trieu authored
llvm-svn: 139510
-
-
Anna Zaks authored
[analyzer] Fix a new failure encountered while building Adium exposed as a result of r138196(radar://10087620). ObjectiveC property of type int has a value of type ObjCPropRef, which is a Loc. llvm-svn: 139507
-
Devang Patel authored
llvm-svn: 139502
-
Douglas Gregor authored
llvm-svn: 139499
-
Douglas Gregor authored
declaration may be the first declaration, we want the ability to that declaration to be marked module-private. llvm-svn: 139497
-
Douglas Gregor authored
Only predefine the OBJC_ZEROCOST_EXCEPTIONS macro if Objective-C exceptions are turned on. Fixes PR10910. llvm-svn: 139496
-
Hans Wennborg authored
Fixes PR10898. The warning should be silent when there are parenthesis around the condition expression. llvm-svn: 139492
-
- Sep 10, 2011
-
-
Benjamin Kramer authored
llvm-svn: 139474
-
Fariborz Jahanian authored
test case having instancetype. Fix in rewriter is unrelated to using of instancetype. Test case uses other feature not yet supported in the rewriter. There is more work to do, but this is an ongoing task and not urgent at this time. llvm-svn: 139473
-
Chris Lattner authored
llvm-svn: 139472
-
John McCall authored
llvm-svn: 139470
-
John McCall authored
Use a more portable heuristic for deciding when to emit a single atomic store; it's possible that I've lost information here, but I'm not sure how much of the logic before was intentionally arch-specific and how much was just not quite consistent. llvm-svn: 139468
-
John McCall authored
llvm-svn: 139466
-
David Blaikie authored
llvm-svn: 139463
-
Richard Trieu authored
llvm-svn: 139461
-
John McCall authored
the lifetime of the block by copying it to the heap, or else we'll get a dangling reference because the code working with the non-block-typed object will not know it needs to copy. There is some danger here, e.g. with assigning a block literal to an unsafe variable, but, well, it's an unsafe variable. llvm-svn: 139451
-
Douglas Gregor authored
methods, and improve the diagnostic slightly along the way. Fixes <rdar://problem/10098695>. llvm-svn: 139446
-