-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 06/24/2011 01:06 PM, Dan McCabe wrote: > On 06/20/2011 03:34 PM, Ian Romanick wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> On 06/17/2011 05:43 PM, Dan McCabe wrote: >>> We now tie the grammar to the ctors of the ASTs they reference. >>> >>> This requires that we actually have definitions of the ctors. >>> >>> In addition, we also need to define "print" and "hir" methods for the >>> AST >>> classes. At this stage of the development, we simply stub out the >>> "print" >>> and "hir" methods and flesh them out later. >>> >>> Also, since actual class instances get returned by the productions in >>> the >>> grammar, we also need to designate the type of the productions that >>> reference those instances. >>> + void *ctx = state; >>> + $$ = new(ctx) ast_switch_statement($3, $5); >> In this instance (and the similar ones below), I'd just do 'new(state)'. >> After most of the parser was written we started always calling the >> memory context mem_ctx. > Will do. It wasn't clear to me what the rhyme or reason was behind using > state vs. ctx. Apparently, my usage matched that rationale.
A bunch of that code originates from when we first started using talloc (now ralloc). There had previously been more to it than this, but there was a big search-and-replace change. My recollection is that's what left a bunch of the "void *ctx = state" business hanging around. In general, - If there's an anonymous memory context that gets passed into a function or held in an object, call it mem_ctx. - If some piece of IR or other ralloc tracked object is used as the memory context, just use the object handle itself. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAk4I9xQACgkQX1gOwKyEAw8bKACghIjmkoRziSbkIffr9Kn3HyMG 2EMAniW7Nm8KcEoebvpgxuaYs3QtqGiQ =WmDm -----END PGP SIGNATURE----- _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
