Douglas Gregor [Fri, 27 Mar 2009 06:00:30 +0000 (06:00 +0000)]
If the user is trying to apply the -> or . member reference operator
to a function or function pointer, it's probably because the user
forgot to put in parentheses () to call the function.
Douglas Gregor [Fri, 27 Mar 2009 05:10:56 +0000 (05:10 +0000)]
Remove the code insertion hint for implicit int. Too often, we're wrong about this hint, so it loses its usefulness. Maybe some day we can make the hint smart enough to be useful.
Ted Kremenek [Fri, 27 Mar 2009 05:06:10 +0000 (05:06 +0000)]
BugReporter:
- Added an internal helper class 'PathDiagnosticBuilder' which now bundles the
'ExecutionContinues' methods.
- Added preliminary diagnostics for short-circuit '&&' and '||'
Chris Lattner [Fri, 27 Mar 2009 04:18:06 +0000 (04:18 +0000)]
Fix rdar://6719156 - clang should emit a better error when blocks are disabled but are used anyway
by changing blocks from being disabled in the parser to being disabled
in Sema.
Ted Kremenek [Fri, 27 Mar 2009 02:22:03 +0000 (02:22 +0000)]
- Fix thinko in implementation of PathDiagnosticLocation::asStmt(). Thanks to
Anders Johnsen for pointing this out.
- Have PathDiagnosticControlFlowPiece take PathDiagnosticLocation for the
arguments to its constructors.
Douglas Gregor [Thu, 26 Mar 2009 23:50:42 +0000 (23:50 +0000)]
Revamp our representation of C++ nested-name-specifiers. We now have a
uniqued representation that should both save some memory and make it
far easier to properly build canonical types for types involving
dependent nested-name-specifiers, e.g., "typename T::Nested::type".
This approach will greatly simplify the representation of
CXXScopeSpec. That'll be next.
Ted Kremenek [Thu, 26 Mar 2009 21:21:35 +0000 (21:21 +0000)]
PathDiagnostics (analyzer):
- Added a new class, 'PathDiagnosticLocation', that is a variant for
SourceLocation, SourceRange, or Stmt*. This will be used soon by
PathDiagnosticPieces to describe locations for targets of branches, locations
of events, etc.
- Did some prep. refactoring of PathDiagnosticPieces to prepare them for
adopting the new PathDiagnosticLocation
- Minor change to dump of ivar layout map.
- Temporarily undef'ed __OBJC2__ in nonfragile objc abi mode
as it was forcing ivar synthesis in a certain project which clang
does not yet support.
Steve Naroff [Thu, 26 Mar 2009 16:01:08 +0000 (16:01 +0000)]
Fix <rdar://problem/6697053> instance variable is protected.
Treat @package the same as @public. The documentation for @package says it is analogous to private_extern for variables/functions. Fully implementing this requires some kind of linker support (so access is denied to code outside the classes executable image). I don't believe GCC fully implements this semantic. Will discuss with Fariborz offline.
Ted Kremenek [Thu, 26 Mar 2009 03:35:11 +0000 (03:35 +0000)]
analyzer infrastructure: make a bunch of changes to symbolic expressions that
Zhongxing and I discussed by email.
Main changes:
- Removed SymIntConstraintVal and SymIntConstraint
- Added SymExpr as a parent class to SymbolData, SymSymExpr, SymIntExpr
- Added nonloc::SymExprVal to wrap SymExpr
- SymbolRef is now just a typedef of 'const SymbolData*'
- Bunch of minor code cleanups in how some methods were invoked (no functionality change)
This changes are part of a long-term plan to have full symbolic expression
trees. This will be useful for lazily evaluating complicated expressions.
Douglas Gregor [Thu, 26 Mar 2009 00:10:35 +0000 (00:10 +0000)]
The injected-class-name of class templates and class template
specializations can be treated as a template. Finally, we can parse
and process the first implementation of Fibonacci I wrote!
Note that this code does not handle all of the cases where
injected-class-names can be treated as templates. In particular,
there's an ambiguity case that we should be able to handle (but
can't), e.g.,
Douglas Gregor [Wed, 25 Mar 2009 21:17:03 +0000 (21:17 +0000)]
Instantiation for member classes of class templates. Note that only
the declarations of member classes are instantiated when the owning
class template is instantiated. The definitions of such member classes
are instantiated when a complete type is required.
This change also introduces the injected-class-name into a class
template specialization.
Chris Lattner [Wed, 25 Mar 2009 21:01:40 +0000 (21:01 +0000)]
remove some dead code. ArgTokens can never be empty, because it is always
terminated with an EOF token. The condition it is trying to check for is
handled by this code above.
// Empty arguments are standard in C99 and supported as an extension in
// other modes.
if (ArgTokens.empty() && !Features.C99)
Diag(Tok, diag::ext_empty_fnmacro_arg);
Daniel Dunbar [Wed, 25 Mar 2009 06:58:31 +0000 (06:58 +0000)]
Driver: Implement Darwin_X86 tool chain level argument translation.
- This is really gross, but its the easiest way to match gcc. Once we
are confident in the driver, we can try and push these translations
down into tools.
- No test cases for this yet, it's hard to see the effects of these
translations before the gcc tool argument translation is pulled
over.
- Interaction with "unused argument" warning hasn't been worked out
yet.
- <rdar://problem/6717359> [driver] implement toolchain specific
argument translation.
Daniel Dunbar [Wed, 25 Mar 2009 06:12:34 +0000 (06:12 +0000)]
Driver: Handle -Xarch_, including warning for nasty -Xarch_ use cases
we aren't going to support. For example:
clang -Xarch_i386 -S -Xarch_i386 -o -Xarch_i386 myi386asm.s ...
Zhongxing Xu [Wed, 25 Mar 2009 05:58:37 +0000 (05:58 +0000)]
This patch adds two more SymbolData subclasses: SymIntExpr and SymSymExpr, for
representing symbolic expressions like 'x'+3 and 'x'+'y'. The design is
subjected to change later when we fix the class hierarchy of symbolic
expressions.
Daniel Dunbar [Wed, 25 Mar 2009 04:13:45 +0000 (04:13 +0000)]
Driver: Prep for tool chain specific argument translation.
- Lift ArgList to a base class for InputArgList and DerivedArgList.
- This is not a great decomposition, but it does embed the
translation into the type system, and keep things efficient for
tool chains that don't want to do any translation.
- No intended functionality change.
Eventually I hope to get rid of tool chain specific translation and
have each tool do the right thing, but for now this is the easiest way
to match gcc precisely (which is good for testing).
Douglas Gregor [Wed, 25 Mar 2009 00:13:59 +0000 (00:13 +0000)]
In Parser::ParseClassSpecifier, don't conflate a NULL declaration with
failure to perform a declaration. Instead, explicitly note semantic
failures that occur during template parsing with a DeclResult. Fixes
PR3872.
Douglas Gregor [Tue, 24 Mar 2009 20:32:41 +0000 (20:32 +0000)]
Type::isObjectType now implements the (more sensible) C++ definition
of "object type" rather than the C definition of "object type". The
difference is that C's "object type" excludes incomplete types such as
struct X;
However, C's definition also makes it far too easy to use isObjectType
as a means to detect incomplete types when in fact we should use other
means (e.g., Sema::RequireCompleteType) that cope with C++ semantics,
including template instantiation.
I've already audited every use of isObjectType and isIncompleteType to
ensure that they are doing the right thing for both C and C++, so this
is patch does not change any functionality.
Douglas Gregor [Tue, 24 Mar 2009 19:52:54 +0000 (19:52 +0000)]
Make sure to use RequireCompleteType rather than testing for
incomplete types. RequireCompleteType is needed when the type may be
completed by instantiating a template.
Daniel Dunbar [Tue, 24 Mar 2009 19:02:31 +0000 (19:02 +0000)]
Driver: Change default use of "clang" compiler.
- Don't default to using clang for C++ (use -ccc-clang-cxx to
override).
- Default to only using clang on i386 and x86_64 (use
-ccc-clang-archs "" to override).
- <rdar://problem/6712350> [driver] clang should not be used on
powerpc by default
- <rdar://problem/6705767> driver should default to -ccc-no-clang-cxx
I plan to add a warning that we are not using the clang compiler for
the given compilation so that users do not think clang is being used
in situations it isn't.
This change is motivated by the desire to be able to drop clang into a
build and have things "just work", even if it happens to get used to
compile C++ code or code for an architecture we don't support yet.
projects / clang / log