Re: Fwd: dependency tee from c parser entities downto token

[Konrad Eisele <konrad@gaisler.com>]

Christopher Li wrote:
> On Sun, May 13, 2012 at 1:52 AM, Konrad Eisele<eiselekd@gmail.com>  wrote:
>> I have thought about how to implement empty expansion tracing without
>> introducing a new token type. I came up with a solution, however I need
>> one callback, I called it substitute_arg(), see patch attached.
>> What do you think, is it apply-able?
>>
>
> I am very sorry that my speed of absorbing patches is much slower than
> your speed of producing it :(
The last patch with mdep.c and test-mdep.c was also nothing to
apply, only a work in progress to go further...
One thing you can see is how I propagate the token sources
using:
137:            n->from = list->pos;
...
143:            list->pos.line = id;
144:            list->pos.stream = pps;

here you get an argument why it is better to have a
(1) ->macro_begin(a)
     ->macro_end(b)
instead of only one
(2) expand_macro(a,b)
If you want to use the preprocessorhooks to output human readable macro
expansion history line similar to LLVM you probably want a pointer
to the "pre-expanded" token location, that is in (a). In (1) you can buildup
the token-source-paths going from post-expand buffer (b) through the pre-expanded buffers (a)
in (2) you only have the paths going through the expanded buffers, can use (a) to reason
about where (b) came from, but  not in a simple way...

>
> About propagating the empty expansions, may I ask a silly question?
> Is that the goal is you are able to track that, after the recursive expansion,
> you are able to tell in the result stream, there is an macro expand to nothing
> in the this location?
>
> Obviously, if the empty expansion is happen in the top level macro expand,
> you can always keep track of where is the original location of the expand using
> macro token->pos. The tricky part is the, if the empty expansion happen inside
> a multi-level macro expand. Then it is hard to keep track of where that empty
> macro should have been landed if it is not empty. Is that the problem you are
> trying to solve?

Kindof something like this:
#define E1
#define E2
#define S1(a) struct a { E1 int d1; };
#define S2(a) struct a { E2 int d2; };
#define xdef S1(sx) S2(sy)
xdef
main() {
	struct sx v;
}

The xdef expands in one-line to "struct sx { int d1; }; struct sy { int d1; };"
main() only uses "struct sx". Therefore the dependency analysis should not
have "E2 and S2" as dependencies. I think you need the location of empty expansions...

>
> About the two example usage you give. The first one is using the html
> to show how macro expand recursively. I like that demo. It only need to remember
> at which level the macro expand to empty. It don't need to remember where
> the empty macro need to land in the result stream.
Do you mean http://cfw.sourceforge.net/htmltag/init_32.c.pinfo.html ? This
is a gcc-based patch even there you need to trace empty expansion positions.

>
> For the second usage example, the shrinking program. I think it only need to
> remember empty macro expand at the top level. Which is easy because you
> have the macro token->pos pointing to where this macro used in the source
> stream. For the empty macro expand inside another macro, you only need
> to remember it is a dependent of the the top level macro. Because when you
> trim the source code, you can't split a top level macro.

See above example.

>
> I think a lot of the complexity is introduced try to remember where that empty
> macro will land, if it is not being empty. However, exactly because the macro
> is being empty, it will not show up in the result token list. So where it should
> land is actually not very useful information, the parser never see it any way.
> We can relax the requirement a little bit, only need to remember where the
> empty macro will land in the top level case. That will greatly
> simplify the solution.

I'm not shure if it works...

>
> Is my understanding correct?
>
> Thanks
>
> Chris
> --
> To unsubscribe from this list: send the line "unsubscribe linux-sparse" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
>