Fix some errors in c-display-defun-name when the type is "struct {..}", etc.

Also fix some errors with c-display-defun-name when there are nested classes.

* lisp/progmodes/cc-cmds.el (c-in-function-trailer-p): Deal with a struct {..}
being merely the type of a function.
(c-where-wrt-brace-construct): Deal with a struct {..} being merely the type
of a function.  Rearrange the order of some Lisp forms.  Insert a check for
c-protection-key ("private", etc.) alongside the checking for a label.
(c-defun-name-1): New function extracted form c-defun-name, which works within
the existing restriction.  Don't regard 'at-function-end as being within the
defun any more.  Recognize "struct", etc., with the new
c-defun-type-name-decl-key rather than c-type-prefix-key.  Make the
recognition of a normal function more accurate.
(c-defun-name): Part left after extracting the above function.  It now just
widens and calls c-defun-name-1.
(c-declaration-limits-1): New function extracted from c-declaration-limits,
which works within the existing restriction.  Move LIM back one block to
account for the possibility of struct {..} as a function type.  Check we're
not inside a declaration without braces.
(c-declaration-limits): Part left after extracting the above function.  It now
just narrows to an enclosing decl block and calls c-declaration-limits-1.
(c-defun-name-and-limits): New function which identifies the name and limits
of the most nested enclosing declaration or macro.
(c-display-defun-name): Use c-defun-name-and-limits rather than two separate
functions (which didn't always agree on which function).

* lisp/progmodes/cc-engine.el (c-beginning-of-statement-1): If we have struct
{..} as the type of a function, go back over this, too.

* lisp/progmodes/cc-langs.el (c-defun-type-name-decl-kwds)
(c-defun-type-name-decl-key): New lang const/var.

0 files changed, 0 insertions, 0 deletions