summaryrefslogtreecommitdiffstats
path: root/clang/lib/Sema/CodeCompleteConsumer.cpp
diff options
context:
space:
mode:
authorDouglas Gregor <dgregor@apple.com>2010-08-31 00:26:14 +0000
committerDouglas Gregor <dgregor@apple.com>2010-08-31 00:26:14 +0000
commit4afc236cee0cea69412bfe334f6c62d4920f1c2b (patch)
tree34e070fe14d8c52485572889a5434cd4972acf06 /clang/lib/Sema/CodeCompleteConsumer.cpp
parentb58b3c0dda0dd151610b02a75b242b98662a59c6 (diff)
downloadbcm5719-llvm-4afc236cee0cea69412bfe334f6c62d4920f1c2b.tar.gz
bcm5719-llvm-4afc236cee0cea69412bfe334f6c62d4920f1c2b.zip
When instantiating a function type, instantiate the return type before
instantiating the parameters. In a perfect world, this wouldn't matter, and compilers are free to instantiate in any order they want. However, every other compiler seems to instantiate the return type first, and some code (in this case, Boost.Polygon) depends on this and SFINAE to avoid instantiating something that shouldn't be instantiated. We could fight this battle, and insist that Clang is allowed to do what it does, but it's not beneficial: it's more predictable to instantiate this way, in source order. When we implement late-specified return types, we'll need to instantiate the return type last when it was late-specified, hence the FIXME. We now compile Boost.Polygon properly. llvm-svn: 112561
Diffstat (limited to 'clang/lib/Sema/CodeCompleteConsumer.cpp')
0 files changed, 0 insertions, 0 deletions
OpenPOWER on IntegriCloud