Commit Graph

20 Commits

Author SHA1 Message Date
David Blaikie aee4925507 Recommit: Compress formatting of array type names (int [4] -> int[4])
Based on post-commit review discussion on
2bd8493847 with Richard Smith.

Other uses of forcing HasEmptyPlaceHolder to false seem OK to me -
they're all around pointer/reference types where the pointer/reference
token will appear at the rightmost side of the left side of the type
name, so they make nested types (eg: the "int" in "int *") behave as
though there is a non-empty placeholder (because the "*" is essentially
the placeholder as far as the "int" is concerned).

This was originally committed in 277623f4d5

Reverted in f9ad1d1c77 due to breakages
outside of clang - lldb seems to have some strange/strong dependence on
"char [N]" versus "char[N]" when printing strings (not due to that name
appearing in DWARF, but probably due to using clang to stringify type
names) that'll need to be addressed, plus a few other odds and ends in
other subprojects (clang-tools-extra, compiler-rt, etc).
2021-10-21 11:34:43 -07:00
David Blaikie f9ad1d1c77 Revert "Compress formatting of array type names (int [4] -> int[4])"
Looks like lldb has some issues with this - somehow it causes lldb to
treat a "char[N]" type as an array of chars (prints them out
individually) but a "char [N]" is printed as a string. (even though the
DWARF doesn't have this string in it - it's something to do with the
string lldb generates for itself using clang)

This reverts commit 277623f4d5.
2021-10-14 14:49:25 -07:00
David Blaikie 277623f4d5 Compress formatting of array type names (int [4] -> int[4])
Based on post-commit review discussion on
2bd8493847 with Richard Smith.

Other uses of forcing HasEmptyPlaceHolder to false seem OK to me -
they're all around pointer/reference types where the pointer/reference
token will appear at the rightmost side of the left side of the type
name, so they make nested types (eg: the "int" in "int *") behave as
though there is a non-empty placeholder (because the "*" is essentially
the placeholder as far as the "int" is concerned).
2021-10-14 14:23:32 -07:00
Richard Smith 5030928d60 [c++20] Implement semantic restrictions for C++20 designated
initializers.

This has some interesting interactions with our existing extensions to
support C99 designated initializers as an extension in C++. Those are
resolved as follows:

 * We continue to permit the full breadth of C99 designated initializers
   in C++, with the exception that we disallow a partial overwrite of an
   initializer with a non-trivially-destructible type. (Full overwrite
   is OK, because we won't run the first initializer at all.)

 * The C99 extensions are disallowed in SFINAE contexts and during
   overload resolution, where they could change the meaning of valid
   programs.

 * C++20 disallows reordering of initializers. We only check for that for
   the simple cases that the C++20 rules permit (designators of the form
   '.field_name =' and continue to allow reordering in other cases).
   It would be nice to improve this behavior in future.

 * All C99 designated initializer extensions produce a warning by
   default in C++20 mode. People are going to learn the C++ rules based
   on what Clang diagnoses, so it's important we diagnose these properly
   by default.

 * In C++ <= 17, we apply the C++20 rules rather than the C99 rules, and
   so still diagnose C99 extensions as described above. We continue to
   accept designated C++20-compatible initializers in C++ <= 17 silently
   by default (but naturally still reject under -pedantic-errors).

This is not a complete implementation of P0329R4. In particular, that
paper introduces new non-C99-compatible syntax { .field { init } }, and
we do not support that yet.

This is based on a previous patch by Don Hinton, though I've made
substantial changes when addressing the above interactions.

Differential Revision: https://reviews.llvm.org/D59754

llvm-svn: 370544
2019-08-30 22:52:55 +00:00
Charles Li 85dec55989 [Lit Test] Updated 20 Lit tests to be C++11 compatible.
This is the 5th Lit test patch.
Expanded expected diagnostics to vary by C++ dialect.
Expanded RUN line to: default, C++98/03 and C++11.

llvm-svn: 255196
2015-12-10 01:07:17 +00:00
John McCall 5fb5df9c83 Restructure how the driver communicates information about the
target Objective-C runtime down to the frontend:  break this
down into a single target runtime kind and version, and compute
all the relevant information from that.  This makes it
relatively painless to add support for new runtimes to the
compiler.  Make the new -cc1 flag, -fobjc-runtime=blah-x.y.z,
available at the driver level as a better and more general
alternative to -fgnu-runtime and -fnext-runtime.  This new
concept of an Objective-C runtime also encompasses what we
were previously separating out as the "Objective-C ABI", so
fragile vs. non-fragile runtimes are now really modelled as
different kinds of runtime, paving the way for better overall
differentiation.

As a sort of special case, continue to accept the -cc1 flag
-fobjc-runtime-has-weak, as a sop to PLCompatibilityWeak.

I won't go so far as to say "no functionality change", even
ignoring the new driver flag, but subtle changes in driver
semantics are almost certainly not intended.

llvm-svn: 158793
2012-06-20 06:18:46 +00:00
Patrick Beard acfbe9e1f2 Added a new attribute, objc_root_class, which informs the compiler when a root class is intentionally declared.
The warning this inhibits, -Wobjc-root-class, is opt-in for now. However, all clang unit tests that would trigger
the warning have been updated to use -Wno-objc-root-class. <rdar://problem/7446698>

llvm-svn: 154187
2012-04-06 18:12:22 +00:00
John McCall 9b0a7cea0f Make -fobjc-nonfragile-abi the -cc1 default, since it's the
increasingly prevailing case to the point that new features
like ARC don't even support the fragile ABI anymore.

This required a little bit of reshuffling with exceptions
because a check was assuming that ObjCNonFragileABI was
only being set in ObjC mode, and that's actually a bit
obnoxious to do.

Most, though, it involved a perl script to translate a ton
of test cases.

Mostly no functionality change for driver users, although
there are corner cases with disabling language-specific
exceptions that we should handle more correctly now.

llvm-svn: 140957
2011-10-02 01:16:38 +00:00
Douglas Gregor aec93c6bbe Ensure that the result type of an Objective-C class message send is
complete. However, if it returns a reference type, don't require the
type it refers to to be complete. Fixes <rdar://problem/8807070>.

llvm-svn: 123214
2011-01-11 03:23:19 +00:00
Douglas Gregor 1ba435f0f9 When we have two identifiers in a row in Objective-C, make sure to
verify that we aren't in a message-send expression before digging into
the identifier or looking ahead more tokens. Fixes a regression
(<rdar://problem/8483253>) I introduced with bracket insertion.

llvm-svn: 114968
2010-09-28 17:48:56 +00:00
Chris Lattner 53fa04909c make clang print types as "const int *" instead of "int const*",
which is should have done from the beginning.  As usual, the most
fun with this sort of change is updating all the testcases.

llvm-svn: 113090
2010-09-05 00:04:01 +00:00
Gabor Greif e6523ea915 suppress annoying textual repetition as 'aka'
llvm-svn: 112365
2010-08-28 10:40:52 +00:00
Douglas Gregor f7d7771812 Fix the recently-added warning about 'typename' and 'template'
disambiguation keywords outside of templates in C++98/03. Previously,
the warning would fire when the associated nested-name-specifier was
not dependent, but that was a misreading of the C++98/03 standard:
now, we complain only when we're outside of any template.

llvm-svn: 106161
2010-06-16 22:31:08 +00:00
Douglas Gregor c9d2682df3 Warn when a 'typename' or a 'template' keyword refers to a
non-dependent type or template name, respectively, in C++98/03. Fixes
PR7111 and <rdar://problem/8002682>.

llvm-svn: 105968
2010-06-14 22:07:54 +00:00
Douglas Gregor 4f4946aaaa Whenever we complain about a failed initialization of a function or
method parameter, provide a note pointing at the parameter itself so
the user does not have to manually look for the function/method being
called and match up parameters to arguments. For example, we now get:

t.c:4:5: warning: incompatible pointer types passing 'long *' to
parameter of
      type 'int *' [-pedantic]
  f(long_ptr);
    ^~~~~~~~
t.c:1:13: note: passing argument to parameter 'x' here
void f(int *x);
            ^

llvm-svn: 102038
2010-04-22 00:20:18 +00:00
Douglas Gregor 6b7f12c039 Switch the initialization of Objective-C message parameters (as occurs
during message sends) over to the new initialization code and away
from the C-only CheckSingleAssignmentConstraints. The enables the use
of C++ types in method parameters and message arguments, as well as
unifying more initialiation code overall.

llvm-svn: 102035
2010-04-21 23:24:10 +00:00
Douglas Gregor 8d4de67e1d Implement parsing for message sends in Objective-C++. Message sends in
Objective-C++ have a more complex grammar than in Objective-C
(surprise!), because

  (1) The receiver of an instance message can be a qualified name such
  as ::I or identity<I>::type.
  (2) Expressions in C++ can start with a type.

The receiver grammar isn't actually ambiguous; it just takes a bit of
work to parse past the type before deciding whether we have a type or
expression. We do this in two places within the grammar: once for
message sends and once when we're determining whether a []'d clause in
an initializer list is a message send or a C99 designated initializer.

This implementation of Objective-C++ message sends contains one known
extension beyond GCC's implementation, which is to permit a
typename-specifier as the receiver type for a class message, e.g.,

  [typename compute_receiver_type<T>::type method];

Note that the same effect can be achieved in GCC by way of a typedef,
e.g.,

  typedef typename computed_receiver_type<T>::type Computed;
  [Computed method];

so this is merely a convenience.

Note also that message sends still cannot involve dependent types or
values.

llvm-svn: 102031
2010-04-21 22:36:40 +00:00
Douglas Gregor 0c78ad9665 Rework the Parser-Sema interaction for Objective-C message
sends. Major changes include:

  - Expanded the interface from two actions (ActOnInstanceMessage,
    ActOnClassMessage), where ActOnClassMessage also handled sends to
    "super" by checking whether the identifier was "super", to three
    actions (ActOnInstanceMessage, ActOnClassMessage,
    ActOnSuperMessage). Code completion has the same changes.
  - The parser now resolves the type to which we are sending a class
    message, so ActOnClassMessage now accepts a TypeTy* (rather than
    an IdentifierInfo *). This opens the door to more interesting
    types (for Objective-C++ support).
  - Split ActOnInstanceMessage and ActOnClassMessage into parser
    action functions (with their original names) and semantic
    functions (BuildInstanceMessage and BuildClassMessage,
    respectively). At present, this split is onyl used by
    ActOnSuperMessage, which decides which kind of super message it
    has and forwards to the appropriate Build*Message. In the future,
    Build*Message will be used by template instantiation.
  - Use getObjCMessageKind() within the disambiguation of Objective-C
    message sends vs. array designators.

Two notes about substandard bits in this patch:
  - There is some redundancy in the code in ParseObjCMessageExpr and
  ParseInitializerWithPotentialDesignator; this will be addressed
  shortly by centralizing the mapping from identifiers to type names
  for the message receiver.
  - There is some #if 0'd code that won't likely ever be used---it
  handles the use of 'super' in methods whose class does not have a
  superclass---but could be used to model GCC's behavior more
  closely. This code will die in my next check-in, but I want it in
  Subversion.

llvm-svn: 102021
2010-04-21 19:57:20 +00:00
Douglas Gregor 337caf9e3e Implement C++ name lookup for instance variables of Objective-C classes
from an instance method. Previously, we were following the Objective-C
name lookup rules for ivars, which are of course completely different
from and incompatible with the Objective-C++ rules.

For the record, the Objective-C++ rules are the sane ones.

This is another part of <rdar://problem/7660386>.

llvm-svn: 96677
2010-02-19 16:08:35 +00:00
Douglas Gregor cfd70242ca Make Sema::ActOnClassMessage robust when name lookup for the receiver
name finds something other than a TypedefDecl or an
ObjCInterfaceDecl. This is a small part of <rdar://problem/7660386>.

llvm-svn: 96676
2010-02-19 15:18:45 +00:00