On Wed, May 9, 2012 at 11:19 PM, Konrad Eisele <konrad@xxxxxxxxxxx> wrote: >> I was thinking that you can use the sym->parent to find out you are inside >> which macro's scope. If I change the sym->parent to the token type, which >> is the token initiated the macro expand. Then you should have all the >> information >> you need? > You dont get the point. Is there a pointer token.parent? No. How can > you know which macro expansion you _came from_, you only know Did you look at my patch? It save the top level expanding macro in parent variable and the macro expansion active maintains it. e.g. When you enter the macro, it save the current macro in parent. When you exit the macro during untainted, it will pop it from the symbol->parent. So during the macro expansion. It does remember the upper level macro and the macro above that all the way to the outside the macro expand. Where parent will be NULL. My test program demo part of it. > where you _end up_. How can you build the _branches_ of a tree? You can > only build _leafs_. > Funny thing is: When you _are_ a commiter you _can_ suddenly add > "sym.parent" when you think it is necessary? All this mess is originally > because you dont think that sym.token can replace sym.position... Please. Sparse carefully separate out the token from the AST is by design. So it does not need to carry the token baggage in the later part of the AST processing. That is a design and I want to keep it. It make the program run faster as well because it reduce the compiler foot print. > Wasnt adding new members a sin ? I guess it actually doesnt matter, > if you are a committer ...:-) Well, in case you did not notice. The place I add it is part of a union in side symbol. It will not expand the size of the symbol at all. Other part of the sparse use similar tricks. There is no extra memory expansion for that. It is not about I am the committer so I can do what I want. I did not commit my branch into the official repository do I? Why do you think I name the branch "unclean-xxxxx". It is putting it out for review just like your patches. So that I can receive critic comment like yours. The goal is find out the better way to incorporate this feature without much negative on other clients of sparse. e.g. your patch using token replacing pos will have such negative impact on other sparse client that don't care about the macro expand history. > Also: I dont see that you do anything with token.pos. Dont > you remember that you came up with token.pos encoding to avoid adding > a new member to token that my original patch did? > In the last patch I sent this idea is used, as described, I write > an unique id to token.pos.position that then shows the origin... > You seem to have forgotten what we started from. Of course I remember. That trick is done in the call back. In the client of the sparse library. I am currently focus on getting the right change for the core sparse library. Think sparse as a library. There are many client that use this library. The sparse checker, ctags and sparse-llvm are all client of the sparse library. I am trying to get the library support your dependency analyse without much negative impact of other client of sparse. Your patch is clear focus on getting your program to run. I have more constrains to consider. > This is all the same thing. It doenst matter how, just implement it. It doesn't matter to you. But the detail matters to me. > I dont understand: Here you think you can patch 1000 lines in the > original code (which your new idea would requite ) however you > insist of 2 callbacks (callbacks that normal code would ignore anyway) > because you dont want to grant me 4 extra lines (the begin-end > hooks+define+post). > This is greedy at least, I dont get it, I think I'm out of here... A change like that clearly needs more discussion and review process for feed back. My own patches will need to go through the same thing. And that is what I am doing. I am sorry. I understand your frustration trying submit a patch but haven't able to get it in as early as you hope. I am also frustrated because I haven't found the clean enough way to support it. That is why I am having discuss with you to work it through. Keeping the project clean and provide review feed backs is just one of the roles of the maintainer, including rejecting patches at times. The question I concern most is weather that is the right thing to do. A 6 call back API is obvious more complex than a 2 call back. No call back is obvious simpler than 2 call back. It is just part of the quest for finding the right interface. There is no need for such negative attitude. Chris -- To unsubscribe from this list: send the line "unsubscribe linux-sparse" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
