Commit Graph

7 Commits

Author SHA1 Message Date
John McCall 85f9055955 When pretty-printing tag types, only print the tag if we're in C (and
therefore not creating ElaboratedTypes, which are still pretty-printed
with the written tag).

Most of these testcase changes were done by script, so don't feel too
sorry for my fingers.

llvm-svn: 98149
2010-03-10 11:27:22 +00:00
Daniel Dunbar 8fbe78f6fc Update tests to use %clang_cc1 instead of 'clang-cc' or 'clang -cc1'.
- This is designed to make it obvious that %clang_cc1 is a "test variable"
   which is substituted. It is '%clang_cc1' instead of '%clang -cc1' because it
   can be useful to redefine what gets run as 'clang -cc1' (for example, to set
   a default target).

llvm-svn: 91446
2009-12-15 20:14:24 +00:00
Douglas Gregor 2e0757f319 Give Type::getDesugaredType a "for-display" mode that can apply more
heuristics to determine when it's useful to desugar a type for display
to the user. Introduce two C++-specific heuristics:

  - For a qualified type (like "foo::bar"), only produce a new
    desugred type if desugaring the qualified type ("bar", in this
    case) produces something interesting. For example, if "foo::bar"
    refers to a class named "bar", don't desugar. However, if
    "foo::bar" refers to a typedef of something else, desugar to that
    something else. This gives some useful desugaring such as
    "foo::bar (aka 'int')".
  - Don't desugar class template specialization types like
    "basic_string<char>" down to their underlying "class
    basic_string<char, char_traits<char>, allocator<char>>, etc.";
    it's better just to leave such types alone. 

Update diagnostics.html with some discussion and examples of type
preservation in C++, showing qualified names and class template
specialization types.

llvm-svn: 68207
2009-04-01 15:47:24 +00:00
Daniel Dunbar a45cf5b6b0 Rename clang to clang-cc.
Tests and drivers updated, still need to shuffle dirs.

llvm-svn: 67602
2009-03-24 02:24:46 +00:00
Douglas Gregor 975e6d0ccd Print the context of tag types as part of pretty-printing, e.g.,
struct N::M::foo

llvm-svn: 67284
2009-03-19 04:25:59 +00:00
Douglas Gregor e177b7254d Extend the use of QualifiedNameType to the creation of class template
specialization names. This way, we keep track of sugared types like

  std::vector<Real>

I believe we are now using QualifiedNameTypes everywhere we can. Next
step: QualifiedDeclRefExprs.

llvm-svn: 67268
2009-03-19 00:39:20 +00:00
Douglas Gregor 5253768ada Introduce a representation for types that we referred to via a
qualified name, e.g., 

  foo::x

so that we retain the nested-name-specifier as written in the source
code and can reproduce that qualified name when printing the types
back (e.g., in diagnostics). This is PR3493, which won't be complete
until finished the other tasks mentioned near the end of this commit.

The parser's representation of nested-name-specifiers, CXXScopeSpec,
is now a bit fatter, because it needs to contain the scopes that
precede each '::' and keep track of whether the global scoping
operator '::' was at the beginning. For example, we need to keep track
of the leading '::', 'foo', and 'bar' in
 
  ::foo::bar::x

The Action's CXXScopeTy * is no longer a DeclContext *. It's now the
opaque version of the new NestedNameSpecifier, which contains a single
component of a nested-name-specifier (either a DeclContext * or a Type
*, bitmangled). 

The new sugar type QualifiedNameType composes a sequence of
NestedNameSpecifiers with a representation of the type we're actually
referring to. At present, we only build QualifiedNameType nodes within
Sema::getTypeName. This will be extended to other type-constructing
actions (e.g., ActOnClassTemplateId).

Also on the way: QualifiedDeclRefExprs will also store a sequence of
NestedNameSpecifiers, so that we can print out the property
nested-name-specifier. I expect to also use this for handling
dependent names like Fibonacci<I - 1>::value.

llvm-svn: 67265
2009-03-19 00:18:19 +00:00