After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 379466 - Improve C parser to handle TYPE\nVARIABLE in function prototypes
Improve C parser to handle TYPE\nVARIABLE in function prototypes
Status: RESOLVED FIXED
Product: gtk-doc
Classification: Platform
Component: general
1.7
Other Linux
: Normal enhancement
: 1.9
Assigned To: gtk-doc maintainers
gtk-doc maintainers
Depends on:
Blocks:
 
 
Reported: 2006-11-26 14:56 UTC by Simon Josefsson
Modified: 2007-09-22 19:12 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Simon Josefsson 2006-11-26 14:56:46 UTC
Hi!  In GnuTLS we have long function names, and after running 'indent' on the header file, it looks like:

  int gnutls_certificate_set_x509_trust_mem (gnutls_certificate_credentials_t
					     res, const gnutls_datum_t * CA,
					     gnutls_x509_crt_fmt_t type);

Specifically, the variable name is wrapped to the next line, after the type.  Gtk-doc doesn't seem to cope with this, and I get this:

WARNING: Parameter described in source code comment block but does not exist -
         FUNCTION: gnutls_certificate_set_x509_trust_mem Parameter: res.

If I change the line into:

  int gnutls_certificate_set_x509_trust_mem (gnutls_certificate_credentials_t res,
					     const gnutls_datum_t * CA,
					     gnutls_x509_crt_fmt_t type);

In other words, unwrap the 'res' variable name to the same line as the type.  It now works, but then the line becomes too long for 'indent'.  I'd like for the changes caused by 'indent' to be as small as possible in GnuTLS, therefor I'd like to request that gtk-doc handle this case as well.  In general, it seems like a good thing to support, because C allows this.

Maybe it is easy to fix this?  E.g., where a regexp now says [ \t]+ it could be changed into [ \t\n]+ or something.

Thanks for your consideration!
Comment 1 Yeti 2007-07-17 12:36:36 UTC
The parsing is unfortunately line-based.  Therefore this might not be so easy to fix as it seems, see also bug 411739, comment 2.
Comment 2 Stefan Sauer (gstreamer, gtkdoc dev) 2007-07-17 13:04:47 UTC
I started a testsuite to have regression testing when modifying the parsing. My plan for this is to try to join lines beforehand.
Comment 3 Yeti 2007-07-17 18:29:05 UTC
(In reply to comment #2)
> I started a testsuite to have regression testing when modifying the parsing.

Excellent.  One will no longer have to fear what unintended effects the changes he makes in the monstrous regular expressions can have...

Please send a note to gtk-doc-list once you have something.

> My plan for this is to try to join lines beforehand.

Do you mean to undef $/, slurp the whole file and use a m/\G.../gc loop?
\n matters for the preprocessor stuff, and `join lines' can mean many things.
Comment 4 Stefan Sauer (gstreamer, gtkdoc dev) 2007-07-17 19:22:50 UTC
I thought about more about the following:
* when hitting a function decl, join lines until one contains '{'
* parse the line
Comment 5 Yeti 2007-07-17 19:49:09 UTC
(In reply to comment #4)
> * when hitting a function decl, join lines until one contains '{'
> * parse the line

Well, this does not look like a well-invested effort to me.

The code would probably become even more convoluted and confusing than it already is.  And while such a workaround can help with this particular issue, it does not help with bug 411739 type issues.

On the other hand a m/\G.../gc parser would be more work, but it has a potential to be simpler at the end (see all the special cases detecting whether we are at the start of function declaration that your suggestion does not eliminate) and it should be possible to get there more or less gradually:
- change the matches to \G-style
- do not add /s flags yet, but add /m flags
- add ^ (with \s* where necessary) after all \Gs forcing line-wise matching
- test, test, test and fix typos

Now the parser emulates the current one and you can start lifting the limitations.
Comment 6 Stefan Sauer (gstreamer, gtkdoc dev) 2007-08-12 14:56:47 UTC
2007-08-12  Stefan Kost  <ensonic@users.sf.net>

	* gtkdoc-mkdb.in:
	  Handle newline in declarations better. Fixes #379466.