chromatic helped me with some debugging last week, but we didn't get to a resolution. something about a CPointer PMC pointing to bad data. it's really hard to trace through the MMD stuff with gdb, I'm not familiar with that code at all.

(I can certainly get farther by updating certain bits from "a::b" to "a"; "b", but at some point there are no obvious conversions left to make, and partcl still fails. Is this a problem with TGE or partcl? I have no clue.

pmichaud: we drag this topic up every six months or so. I don't see the utility of including codingstd tests in make test at all. There's a very small class of people running make test for whom that makes sense as a default.

Now we *could* have someone set up a dedicated 'make codetest' Smolder box, which would seem to satisfy everyone's concerns, but you're going to have to argue very well to convince me that even those two codingstd tests are so important that they're worth spending 130% of the time we spend on coretests.

it looks to me like you all agree that they are too slow to be run every time you run make test, the only concern is that they DO get run before people commit (or at least regularly), but i've only spent a couple of hours in this channel, so take that with a grain of salt

pmichaud: at the time we're creating new parsegrammar and parseaction objects, where do we get the hll namespace from if pa or pg is a string? Do we go digging around in the call stack the? earlier and store it, or get it explicitly and store it?

: [GC] Investigating RT#46187. There was a lone "TODO" comment with no explanation. I've determined that there's nothing of interest to be done here, so I'm removing the offending comment and closing the ticket.

: [PMC] RT#46663 pointed to a comment with a question asking whether a particular sequence would cause problems with --gc-debug. The ticket is over 1 year old with no problems exposed by this sequence, and I don't see any way this could cause a problem as-is. Removing the offending comment.