diff options
author | Douglas Gregor <dgregor@apple.com> | 2010-02-03 00:27:59 +0000 |
---|---|---|
committer | Douglas Gregor <dgregor@apple.com> | 2010-02-03 00:27:59 +0000 |
commit | b92a1565c37194cee915249eb1330c05cbef6c7e (patch) | |
tree | 397b65e6bc396e81b2857b16fd4d472d893c1b33 /llvm/lib | |
parent | d111bd518da772f2743c142cd21a0032d27caf99 (diff) | |
download | bcm5719-llvm-b92a1565c37194cee915249eb1330c05cbef6c7e.tar.gz bcm5719-llvm-b92a1565c37194cee915249eb1330c05cbef6c7e.zip |
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.
llvm-svn: 95167
Diffstat (limited to 'llvm/lib')
0 files changed, 0 insertions, 0 deletions