On Sun, Feb 12, 2017 at 11:03 PM, Luc Van Oostenryck <luc.vanoostenryck@xxxxxxxxx> wrote: > OK, I've look at this. > The difference between your patch and mine is that yours share/ > migrate the methods for all symbols while mine purposely did that > for builtins only. The reasons I did this way was to avoid to share That to me is actually not the main difference. Yes, the one line patch is simple and apply op to all symbol has the same name. If we need, we can make that migrate code into a function and do some special handing for builtin etc. I just don't see the need for that right now. The big difference I see is the solve the problem at symbol creating side rather than symbol usage side. In the future, we can make migrate symbol only return symbol are new (and has incremental difference). Totally drop the symbol which is the exact same abstract declare as the previous one. > methods between things that don't need to, for example if someone > define a function that have the same name as one of the numerous > attributes (which are not reserved keywords and aren't necessarily > protected by leading double underscore). But having look at this now, > I see that it should never be a problem when this happen (but is it > a good idea?). Even if that became a problem, we can add some code to deal with it. E.g. conditionally migrate some symbol information. 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
