Function generated for keyword methods does not have globally unique name

[yuyichao]

It's arguable whether gensym could be used for globally unique names but as of now, defining meta function in package can break Docs.

This currently happens for Tracy.jl. It just happens that the local function meta is defined such that the symbol it got for the keyword method helper function is exactly the same as the gensym symbol for Base.Docs's META.

Not sure if any generic guarantee can be provided here (it might be possible to guarantee between Base and other packages but it might be impossible between packages that has no explicit dependencies unless the UUID of the package being precompiled is incorporated into the result of gensym). It might be necessary to do manual namespacing when gensym is used this way.

[yuyichao]

Ironically, this happens to a package that uses the same META = gensym(:meta) trick but AFAICT, the use of this pattern is not directly responsible for the issue (other than the definition of the meta function).

[KristofferC]

I guess ref #59239

Manual gensym code often contains a lot of mistakes, either because the
user uses something like . or +, or because it combines code from
multiple modules (gensym is only unique within a pre-compile unit).

[vtjnash]

This is a bit different, since Docs.meta is explicitly using gensym to make a name that does collide everywhere (not hygienic) in a reproducible way. It is the same as Base.sync_varname = gensym(:sync) in that way.

[vtjnash]

This is a bit unexpected too though, since the gensym created by Base should be different from any gensym created by packages due to the jl_set_gs_ctr call. Only packages should collide with each other.

[yuyichao]

The symbol that Base.Docs.META is conflicting with isn't a gensym from the package. Rather it's the symbol lowered from keyword function definition. That one doesn't seem to go through gs_ctr but the two have the same format....

[vtjnash]

Ah, yeah that is bad, this seems unconnected to #53719 as well, right?

[yuyichao]

Not directly. Seems that both are using the same counter which never went through gs_ctr. It does seems that this would be the desired behavior according to #53719 though.

Like I said, I doubt any generic guarantee can be provided, though it might be good to avoid gensym from accidentally create symbols that can conflict with other symbols automatically generated during lowering. (on top of that, the use of gensym should probably be fixed.)