David Chisnall [Wed, 3 Feb 2010 02:09:30 +0000 (02:09 +0000)]
Numerous changes to selector handling:
- Don't use GlobalAliases with non-0 GEPs (GNU runtime) - this was unsupported and LLVM will be generating errors if you do it soon. This also simplifies the code generated by the GNU runtime a bit.
- Make GetSelector() return a constant (GNU runtime), not a load of a store of a constant.
- Add methods to GCObjCRuntime to emit selectors as constants (needed for using @selector() expressions as constants. These need implementing for the Mac runtimes - I couldn't figure out how to do this, they seem to require a load.
- Store an ObjCMethodDecl in an ObjCSelectorExpr so that we can get at the type information for the selector. This is needed for generating typed selectors from @selector() expressions (as GCC does). Ideally, this information should be stored in the Selector, but that would be an invasive change. We should eventually add checks for common uses of @selector() expressions. Possibly adding an attribute that can be applied to method args providing the types of a selector so, for example, you'd do something like this:
Then, any @selector() expressions passed to the method will be check to ensure that it conforms to this signature. We do this at run time on the GNU runtime already, but it would be nice to do it at compile time on all runtimes.
- Made @selector() expressions emit type info if available and the runtime supports it.
Someone more familiar with the Mac runtime needs to implement the GetConstantSelector() function in CGObjCMac. This currently just assert()s.
Douglas Gregor [Wed, 3 Feb 2010 00:27:59 +0000 (00:27 +0000)]
Implement the lvalue-to-rvalue conversion where needed. The
lvalue-to-rvalue conversion adjusts lvalues of qualified, non-class
type to rvalue expressions of the unqualified variant of that
type. For example, given:
const int i;
(void)(i + 17);
the lvalue-to-rvalue conversion for the subexpression "i" will turn it
from an lvalue expression (a DeclRefExpr) with type 'const int' into
an rvalue expression with type 'int'. Both C and C++ mandate this
conversion, and somehow we've slid through without implementing it.
We now have both DefaultFunctionArrayConversion and
DefaultFunctionArrayLvalueConversion, and which gets used depends on
whether we do the lvalue-to-rvalue conversion or not. Generally, we do
the lvalue-to-rvalue conversion, but there are a few notable
exceptions:
- the left-hand side of a '.' operator
- the left-hand side of an assignment
- a C++ throw expression
- a subscript expression that's subscripting a vector
Making this change exposed two issues with blocks:
- we were deducing const-qualified return types of non-class type
from a block return, which doesn't fit well
- we weren't always setting the known return type of a block when it
was provided with the ^return-type syntax
Fixes the current Clang-on-Clang compile failure and PR6076.
Ted Kremenek [Tue, 2 Feb 2010 22:38:47 +0000 (22:38 +0000)]
Remove RegionStoreSubRegionMap::iterator and RegionStoreSubRegionMap::begin_end(). This is a precursor to using DenseSet to represent region sets instead of ImmutableSet.
Douglas Gregor [Tue, 2 Feb 2010 20:10:50 +0000 (20:10 +0000)]
Implement promotion for enumeration types.
WHAT!?!
It turns out that Type::isPromotableIntegerType() was not considering
enumeration types to be promotable, so we would never do the
promotion despite having properly computed the promotion type when the
enum was defined. Various operations on values of enum type just
"worked" because we could still compute the integer rank of an enum
type; the oddity, however, is that operations such as "add an enum and
an unsigned" would often have an enum result type (!). The bug
actually showed up as a spurious -Wformat diagnostic
(<rdar://problem/7595366>), but in theory it could cause miscompiles.
In this commit:
- Enum types with a promotion type of "int" or "unsigned int" are
promotable.
- Tweaked the computation of promotable types for enums
- For all of the ABIs, treat enum types the same way as their
underlying types (*not* their promotion types) for argument passing
and return values
- Extend the ABI tester with support for enumeration types
Chris Lattner [Tue, 2 Feb 2010 17:32:27 +0000 (17:32 +0000)]
the declspec of a declaration can have storage-class specifiers,
type qualifiers and type specifiers in any order. For example,
this is valid: struct x {...} typedef y;
Daniel Dunbar [Tue, 2 Feb 2010 05:41:30 +0000 (05:41 +0000)]
XFAIL two tests on Win32 until some cares to investigate... the problem on
dyncast is just due to \r\n newline interaction w/ regexps. The remap-load.c
failure is a bit stranger (the end of the extent is on the next line), but I
don't care to investigate.
Daniel Dunbar [Tue, 2 Feb 2010 05:19:57 +0000 (05:19 +0000)]
CIndex: Respect TMPDIR/TEMP/TMP when making temporary files for remapping. As a
side effect, this also fixes some cases on Windows where the file would end up
on a different drive, because tmpnam doesn't include the drive component. PR3837
strikes again.
John McCall [Tue, 2 Feb 2010 02:21:27 +0000 (02:21 +0000)]
Implement C++ [temp.deduct.call]p6, template argument deduction for overloaded
arguments. Fix a bug where incomplete explicit specializations were being
passed through as legitimate. Fix a bug where the absence of an explicit
specialization in an overload set was causing overall deduction to fail.
Ted Kremenek [Tue, 2 Feb 2010 02:07:01 +0000 (02:07 +0000)]
Add a stop gap to Sema::CorrectTypo() to correct only up to 20 typos.
This is to address a serious performance problem observed when running
'clang -fsyntax-only' on really broken source files. In one case,
repeatedly calling CorrectTypo() caused one source file to be rejected
after 2 minutes instead of 1 second.
This patch causes typo correction to take neglible time on that file
while still providing correction results for the first 20 cases. I
felt this was a reasonable number for moderately broken source files.
I don't claim this is the best solution. Comments welcome. It is
necessary for us to address this issue because it is a serious
performance problem.
Ted Kremenek [Tue, 2 Feb 2010 02:01:51 +0000 (02:01 +0000)]
Fix bug in GRExprEngine::VisitSizeOfAlignOfExpr() where we do not add
'Pred' to 'Dst' for cases we currently don't handle. This fixes
<rdar://problem/7593875>.
Chris Lattner [Tue, 2 Feb 2010 01:23:29 +0000 (01:23 +0000)]
Implement PR6180, substantially improving the diagnostics we get from
forgetting a ';' at the end of a struct. For something like:
class c {
}
void foo() {}
we now produce:
t.cc:3:2: error: expected ';' after class
}
^
;
instead of:
t.cc:4:1: error: cannot combine with previous 'class' declaration specifier
void foo() {}
^
t.cc:2:7: error: 'class c' can not be defined in the result type of a function
class c {
^
GCC produces:
t.cc:4: error: new types may not be defined in a return type
t.cc:4: note: (perhaps a semicolon is missing after the definition of ‘c’)
t.cc:4: error: two or more data types in declaration of ‘foo’
I *think* I got the follow set right, but if I forgot anything, we'll start
getting spurious "expected ';' after class" errors, let me know if you see
any.
Chris Lattner [Tue, 2 Feb 2010 00:37:27 +0000 (00:37 +0000)]
improve diagnostics on missing ; in a struct. Before:
t.c:4:3: error: expected ';' at end of declaration list
int y;
^
t.c:4:8: warning: extra ';' inside a struct or union
int y;
^
t.c:6:1: warning: expected ';' at end of declaration list
};
^
After:
t.c:3:8: error: expected ';' at end of declaration list
int x // expected-error {{expected ';' at end of declaration list}}
^
;
t.c:5:8: warning: expected ';' at end of declaration list
int z
^
;
Douglas Gregor [Mon, 1 Feb 2010 23:46:27 +0000 (23:46 +0000)]
Make this fix-it test case actually fail when there is a problem; add
a test for access declarations and remove a (broken) test for removal
of default arguments.
Douglas Gregor [Mon, 1 Feb 2010 23:36:03 +0000 (23:36 +0000)]
Improve handling of enumerator values for C and C++, including:
- In C++, prior to the closing '}', set the type of enumerators
based on the type of their initializer. Don't perform unary
conversions on the enumerator values.
- In C++, handle overflow when an enumerator has no initializer and
its value cannot be represented in the type of the previous
enumerator.
- In C, handle overflow more gracefully, by complaining and then
falling back to the C++ rules.
- In C, if the enumerator value is representable in an int, convert the
expression to the type 'int'.
Chris Lattner [Mon, 1 Feb 2010 20:59:08 +0000 (20:59 +0000)]
Don't explicitly force utf strings into the __TEXT,__ustring
by setting the section of the generated global. This is an
optimization done by the code generator, and the code being
removed didn't handle the case when the string contained an
embedded nul (which the code generator does correctly
handle). This is rdar://7589850
Sebastian Redl [Mon, 1 Feb 2010 20:16:42 +0000 (20:16 +0000)]
In C++, an initializer on a variable doesn't necessarily mean it's the definition. With that in mind, rename getDefinition to getAnyInitializer (to distinguish it from getInit) and reimplement it in terms of isThisDeclarationADefinition. Update all code to use this new function.
Ted Kremenek [Mon, 1 Feb 2010 19:28:15 +0000 (19:28 +0000)]
Format string checking: selectively ignore implicit casts to 'int'
when checking if the format specifier matches the type of the data
argument and the length modifier indicates the data type is 'char' or
'short'.
John McCall [Mon, 1 Feb 2010 18:53:26 +0000 (18:53 +0000)]
Note that an overload candidate was non-viable because template argument
deduction failed. Right now there's a very vague diagnostic for most cases
and a good diagnostic for incomplete deduction.
Sebastian Redl [Sun, 31 Jan 2010 22:27:38 +0000 (22:27 +0000)]
Add VarDecl::isThisDeclarationADefinition(), which properly encapsulates the logic for when a variable declaration is a (possibly tentativ) definition. Add a few functions building on this, and shift C tentative definition handling over to this new functionality. This shift also kills the Sema::TentativeDefinitions map and instead simply stores all declarations in the renamed list. The correct handling for multiple tentative definitions is instead shifted to the final walk of the list.
Eli Friedman [Sun, 31 Jan 2010 20:58:15 +0000 (20:58 +0000)]
Switch expressions like T() and T(1,2) over to new-style initialization. I'm
not quite sure what we want to do about the AST representation; comments
welcome.
Chandler Carruth [Sun, 31 Jan 2010 10:01:20 +0000 (10:01 +0000)]
Fix PR6159 and several other problems with value-dependent non-type template
arguments. This both prevents meaningless checks on these arguments and ensures
that they are represented as an expression by the instantiation.
Cleaned up and added standard text to the relevant test case. Also started
adding tests for *rejected* cases. At least one FIXME here where (I think) we
allow something we shouldn't. More to come in the area of rejecting crazy
arguments with decent diagnostics. Suggestions welcome for still better
diagnostics on these errors!
Douglas Gregor [Sun, 31 Jan 2010 09:12:51 +0000 (09:12 +0000)]
Rework base and member initialization in constructors, with several
(necessarily simultaneous) changes:
- CXXBaseOrMemberInitializer now contains only a single initializer
rather than a set of initialiation arguments + a constructor. The
single initializer covers all aspects of initialization, including
constructor calls as necessary but also cleanup of temporaries
created by the initializer (which we never handled
before!).
- Rework + simplify code generation for CXXBaseOrMemberInitializers,
since we can now just emit the initializer as an initializer.
- Switched base and member initialization over to the new
initialization code (InitializationSequence), so that it
- Improved diagnostics for the new initialization code when
initializing bases and members, to match the diagnostics produced
by the previous (special-purpose) code.
- Simplify the representation of type-checked constructor initializers in
templates; instead of keeping the fully-type-checked AST, which is
rather hard to undo at template instantiation time, throw away the
type-checked AST and store the raw expressions in the AST. This
simplifies instantiation, but loses a little but of information in
the AST.
- When type-checking implicit base or member initializers within a
dependent context, don't add the generated initializers into the
AST, because they'll look like they were explicit.
- Record in CXXConstructExpr when the constructor call is to
initialize a base class, so that CodeGen does not have to infer it
from context. This ensures that we call the right kind of
constructor.
There are also a few "opportunity" fixes here that were needed to not
regress, for example:
- Diagnose default-initialization of a const-qualified class that
does not have a user-declared default constructor. We had this
diagnostic specifically for bases and members, but missed it for
variables. That's fixed now.
- When defining the implicit constructors, destructor, and
copy-assignment operator, set the CurContext to that constructor
when we're defining the body.
Chandler Carruth [Sun, 31 Jan 2010 07:09:11 +0000 (07:09 +0000)]
Handle instantiation of templates with non-type arguments expressed with an
explicit '&' by introducing an address-of operator prior to checking the
argument's type.
Daniel Dunbar [Sun, 31 Jan 2010 00:41:15 +0000 (00:41 +0000)]
cindex/Python: Turn off showing IDs by default, they are really slow to compute
pending a hash function. Also added a --max-depth argument, handy for timing and
limiting the volume of output.
Daniel Dunbar [Sat, 30 Jan 2010 23:31:40 +0000 (23:31 +0000)]
CIndex: Fix ReportSerializedDiagnostics to honor the DiagnosticClient contract
that diagnostics with a source location should occur inside
{Begin,End}SourceFile.
Note that code completion is currently passing in an invalid LangOptions object
due to its implementation, I need to sort this out with Doug.
projects / clang / log