Re: [CEDET-devel] tag bounds of macro definition, macro again...

Hi,
Macros are part of the C preprocessor, and not part of the general
parser. Since semantic tries to combine the pre-processor and the
lexical analyzer together, odd little hacks show up. The lexical
analyzer identifies macros (like ABC) and creates a lexical token for
the whole thing. The parser gets this token, and needs a name, so the
text representation of the macro is just the name without the other
stuff. The value of the macro is stored as part of the preprocessor and
not a value for the more general parser. As such, all the positional
information in the area is lost, gobbled up by the lexical
analyzer/preprocessor thing.
Since the parser is in charge of the overlay boundary setting, it can't
really be done.
The right solution is to create a real preprocessor with a parser to
feed tokens to the C/C++ parser. Even there, something will probably
get lost along the way.
The best we could do at this time would be to "fake it out", and when
that token type is seen, extend the overlay, but that feels kind of
hacky to me.
Eric
On 03/26/2011 03:57 PM, Darren Hoo wrote:
>
> As to function definition like
>
> void func() { -!- /* ... */ }
>
> the 'semantic overlay starts from the beginning to the end
> So if the point is at position !, semantic-current-tag
> will return tag func.
>
> but for a macro definition like this:
>
> #define ABC 1
>
> the 'semantic overlay ends at point immediately after C, So if
> the current point stays after C, calling semantic-current-tag will
> return nil. This will cause semantic-symref-result-get-tags stops
> working:
>
> code snippet from semantic-symref-result-get-tags
>
> ---------- semantic-symref.el ----------------
> ...
> ;; Too much baggage in goto-line
> ;; (goto-line line)
> (goto-char (point-min))
> (forward-line (1- line))
>
> ;; Search forward for the matching text
> (re-search-forward (regexp-quote txt)
> (point-at-eol)
> t)
>
> (setq tag (semantic-current-tag)) * got nil tag here *
> ...
> ---------- semantic-symref.el ----------------
>
>
> is it the right fix to create 'semantic overlay of macro defintion from
> beginning-of-macro to end-of-macro so that semantic-current-tag will not
> return nil if point stays in between?

Thread view

As to function definition like
void func() { -!- /* ... */ }
the 'semantic overlay starts from the beginning to the end
So if the point is at position !, semantic-current-tag
will return tag func.
but for a macro definition like this:
#define ABC 1
the 'semantic overlay ends at point immediately after C, So if
the current point stays after C, calling semantic-current-tag will
return nil. This will cause semantic-symref-result-get-tags stops
working:
code snippet from semantic-symref-result-get-tags
---------- semantic-symref.el ----------------
...
;; Too much baggage in goto-line
;; (goto-line line)
(goto-char (point-min))
(forward-line (1- line))
;; Search forward for the matching text
(re-search-forward (regexp-quote txt)
(point-at-eol)
t)
(setq tag (semantic-current-tag)) * got nil tag here *
...
---------- semantic-symref.el ----------------
is it the right fix to create 'semantic overlay of macro defintion from
beginning-of-macro to end-of-macro so that semantic-current-tag will not
return nil if point stays in between?

Hi,
Macros are part of the C preprocessor, and not part of the general
parser. Since semantic tries to combine the pre-processor and the
lexical analyzer together, odd little hacks show up. The lexical
analyzer identifies macros (like ABC) and creates a lexical token for
the whole thing. The parser gets this token, and needs a name, so the
text representation of the macro is just the name without the other
stuff. The value of the macro is stored as part of the preprocessor and
not a value for the more general parser. As such, all the positional
information in the area is lost, gobbled up by the lexical
analyzer/preprocessor thing.
Since the parser is in charge of the overlay boundary setting, it can't
really be done.
The right solution is to create a real preprocessor with a parser to
feed tokens to the C/C++ parser. Even there, something will probably
get lost along the way.
The best we could do at this time would be to "fake it out", and when
that token type is seen, extend the overlay, but that feels kind of
hacky to me.
Eric
On 03/26/2011 03:57 PM, Darren Hoo wrote:
>
> As to function definition like
>
> void func() { -!- /* ... */ }
>
> the 'semantic overlay starts from the beginning to the end
> So if the point is at position !, semantic-current-tag
> will return tag func.
>
> but for a macro definition like this:
>
> #define ABC 1
>
> the 'semantic overlay ends at point immediately after C, So if
> the current point stays after C, calling semantic-current-tag will
> return nil. This will cause semantic-symref-result-get-tags stops
> working:
>
> code snippet from semantic-symref-result-get-tags
>
> ---------- semantic-symref.el ----------------
> ...
> ;; Too much baggage in goto-line
> ;; (goto-line line)
> (goto-char (point-min))
> (forward-line (1- line))
>
> ;; Search forward for the matching text
> (re-search-forward (regexp-quote txt)
> (point-at-eol)
> t)
>
> (setq tag (semantic-current-tag)) * got nil tag here *
> ...
> ---------- semantic-symref.el ----------------
>
>
> is it the right fix to create 'semantic overlay of macro defintion from
> beginning-of-macro to end-of-macro so that semantic-current-tag will not
> return nil if point stays in between?

"Eric M. Ludlam" <eric@...> writes:
> Hi,
>
> Macros are part of the C preprocessor, and not part of the general
> parser. Since semantic tries to combine the pre-processor and the
> lexical analyzer together, odd little hacks show up. The lexical
> analyzer identifies macros (like ABC) and creates a lexical token for
> the whole thing. The parser gets this token, and needs a name, so the
> text representation of the macro is just the name without the other
> stuff. The value of the macro is stored as part of the preprocessor and
> not a value for the more general parser. As such, all the positional
> information in the area is lost, gobbled up by the lexical
> analyzer/preprocessor thing.
>
> Since the parser is in charge of the overlay boundary setting, it can't
> really be done.
>
> The right solution is to create a real preprocessor with a parser to
> feed tokens to the C/C++ parser. Even there, something will probably
> get lost along the way.
>
> The best we could do at this time would be to "fake it out", and when
> that token type is seen, extend the overlay, but that feels kind of
> hacky to me.
One year passed, and I found I am bugged by this again, so I wanna bring
it up again.
How about search-backwards in semantic-symref.el? there are better ways
as you've said, but for now I can only think of the following to evade.
=== modified file 'semantic/symref/semantic-symref.el'
--- semantic/symref/semantic-symref.el 2012-03-12 22:18:37 +0000
+++ semantic/symref/semantic-symref.el 2012-04-01 19:11:36 +0000
@@ -382,10 +382,11 @@
;; (goto-line line)
(goto-char (point-min))
(forward-line (1- line))
+ (end-of-line)
- ;; Search forward for the matching text
- (re-search-forward (regexp-quote txt)
- (point-at-eol)
+ ;; Search backward for the matching text
+ (re-search-backward (regexp-quote txt)
+ (point-at-bol)
t)
(setq tag (semantic-current-tag))
> Eric
>
> On 03/26/2011 03:57 PM, Darren Hoo wrote:
>>
>> As to function definition like
>>
>> void func() { -!- /* ... */ }
>>
>> the 'semantic overlay starts from the beginning to the end
>> So if the point is at position !, semantic-current-tag
>> will return tag func.
>>
>> but for a macro definition like this:
>>
>> #define ABC 1
>>
>> the 'semantic overlay ends at point immediately after C, So if
>> the current point stays after C, calling semantic-current-tag will
>> return nil. This will cause semantic-symref-result-get-tags stops
>> working:
>>
>> code snippet from semantic-symref-result-get-tags
>>
>> ---------- semantic-symref.el ----------------
>> ...
>> ;; Too much baggage in goto-line
>> ;; (goto-line line)
>> (goto-char (point-min))
>> (forward-line (1- line))
>>
>> ;; Search forward for the matching text
>> (re-search-forward (regexp-quote txt)
>> (point-at-eol)
>> t)
>>
>> (setq tag (semantic-current-tag)) * got nil tag here *
>> ...
>> ---------- semantic-symref.el ----------------
>>
>>
>> is it the right fix to create 'semantic overlay of macro defintion from
>> beginning-of-macro to end-of-macro so that semantic-current-tag will not
>> return nil if point stays in between?
>

Hi Darren,
Thanks for poking at this some more. I just tweaked your patch to first
find the symbol with re-search-forward, then go to match-beginning.
That has roughly the same effect as your patch. I did that because I
was worried about tags where the name is on line 2, but then I realized
that was irrelevant. Oh well.
Anyway, the fix is in, and I added a test for your macro case.
Thanks
Eric
On 04/01/2012 03:28 PM, Darren Hoo wrote:
> "Eric M. Ludlam"<eric@...> writes:
>> Hi,
>>
>> Macros are part of the C preprocessor, and not part of the general
>> parser. Since semantic tries to combine the pre-processor and the
>> lexical analyzer together, odd little hacks show up. The lexical
>> analyzer identifies macros (like ABC) and creates a lexical token for
>> the whole thing. The parser gets this token, and needs a name, so the
>> text representation of the macro is just the name without the other
>> stuff. The value of the macro is stored as part of the preprocessor and
>> not a value for the more general parser. As such, all the positional
>> information in the area is lost, gobbled up by the lexical
>> analyzer/preprocessor thing.
>>
>> Since the parser is in charge of the overlay boundary setting, it can't
>> really be done.
>>
>> The right solution is to create a real preprocessor with a parser to
>> feed tokens to the C/C++ parser. Even there, something will probably
>> get lost along the way.
>>
>> The best we could do at this time would be to "fake it out", and when
>> that token type is seen, extend the overlay, but that feels kind of
>> hacky to me.
>
> One year passed, and I found I am bugged by this again, so I wanna bring
> it up again.
>
> How about search-backwards in semantic-symref.el? there are better ways
> as you've said, but for now I can only think of the following to evade.
>
> === modified file 'semantic/symref/semantic-symref.el'
> --- semantic/symref/semantic-symref.el 2012-03-12 22:18:37 +0000
> +++ semantic/symref/semantic-symref.el 2012-04-01 19:11:36 +0000
> @@ -382,10 +382,11 @@
> ;; (goto-line line)
> (goto-char (point-min))
> (forward-line (1- line))
> + (end-of-line)
>
> - ;; Search forward for the matching text
> - (re-search-forward (regexp-quote txt)
> - (point-at-eol)
> + ;; Search backward for the matching text
> + (re-search-backward (regexp-quote txt)
> + (point-at-bol)
> t)
>
> (setq tag (semantic-current-tag))
>
>> Eric
>>
>> On 03/26/2011 03:57 PM, Darren Hoo wrote:
>>>
>>> As to function definition like
>>>
>>> void func() { -!- /* ... */ }
>>>
>>> the 'semantic overlay starts from the beginning to the end
>>> So if the point is at position !, semantic-current-tag
>>> will return tag func.
>>>
>>> but for a macro definition like this:
>>>
>>> #define ABC 1
>>>
>>> the 'semantic overlay ends at point immediately after C, So if
>>> the current point stays after C, calling semantic-current-tag will
>>> return nil. This will cause semantic-symref-result-get-tags stops
>>> working:
>>>
>>> code snippet from semantic-symref-result-get-tags
>>>
>>> ---------- semantic-symref.el ----------------
>>> ...
>>> ;; Too much baggage in goto-line
>>> ;; (goto-line line)
>>> (goto-char (point-min))
>>> (forward-line (1- line))
>>>
>>> ;; Search forward for the matching text
>>> (re-search-forward (regexp-quote txt)
>>> (point-at-eol)
>>> t)
>>>
>>> (setq tag (semantic-current-tag)) * got nil tag here *
>>> ...
>>> ---------- semantic-symref.el ----------------
>>>
>>>
>>> is it the right fix to create 'semantic overlay of macro defintion from
>>> beginning-of-macro to end-of-macro so that semantic-current-tag will not
>>> return nil if point stays in between?
>>
>
>
> ------------------------------------------------------------------------------
> This SF email is sponsosred by:
> Try Windows Azure free for 90 days Click Here
> http://p.sf.net/sfu/sfd2d-msazure
> _______________________________________________
> Cedet-devel mailing list
> Cedet-devel@...
> https://lists.sourceforge.net/lists/listinfo/cedet-devel
>