is this going to negatively interact with any trace-processing tools we have?

why do we want this in the output?

Great observation. I think I did see some CI errors due to this comment when I had added the TPC-H trace (before I removed that trace from testing). Those should be easily fixable; I'll check.

Upstream, they are (for now) maintaining the idea that compilation traces are human-readable, which is why this is in the output. We could remove it locally if we're okay with diverging.

compilation traces are human-readable, which is why this is in the output

i wonder in what situations seeing the #= const-return =# comment is helpful?

I think we should be able to handle these trailing comments, but it's definitely a good idea to check 👍

julia> RAI_CompilationsCache.PrecompileStatementParsing.is_precompileable(Base, "#= 1.0 =# precompile(Tuple{typeof(Base.:+), Int, Int}) #= const-return =#")
pr_success::PrecompilationResult = 1

julia> RAI_CompilationsCache.PrecompileStatementParsing.run_precompile(Base, "#= 1.0 =# precompile(Tuple{typeof(Base.:+), Int, Int}) #= const-return =#")
pr_success::PrecompilationResult = 1

We could end up with duplicate traces though -- if on engine 1 we produced

#= 1.0 =# precompile(Tuple{typeof(Base.:+), Int, Int}) #= const-return =#

and on engine 2, which called the function in a different context, we'd get

#= 1.0 =# precompile(Tuple{typeof(Base.:+), Int, Int})

That could cause the precompile to take up 2 spots in the cache, so we probably need to augment the cache to strip any trailing comments.