Well my specific usecase is for a personal project in which I have a set of *ast.Packages that I transform given some directives. Currently codegen is the way to go but I would like to be able to feed my ast to gc directly if possible.

This is too big for the standard library. See https://golang.org/doc/faq#x_in_std

We're still trying to clean up the compiler after the transition from C. Turning it into a library is quite a long way away yet.

what about just giving a very high level API so one can embed the whole go gc compiler into someone's pure-go binary?

we wouldn't commit to any gc API, just this very high-level API.
something along the lines of:

package toolchain // golang.org/x/exp/go/toolchain

import "go/build"

type Toolchain interface {
   Compile(pkg *build.Package) (ofile string, err error)
   Name() string // name of this toolchain (e.g. "gc", "gccgo")
}

// open a registered toolchain (a-la database/sql)
func Open(name string) (Toolchain , error)

Serious question: what is the real advantage of a high level API over simply exec.Command("go", "build", "x.go")?

it's all in the same binary, so you can scp my-binary fresh-box:/usr/bin/. w/o any Go installation.
well, at least that's what I'd envision.

"Compiler as a library" is intriguing and I have brought this idea up internally very early on in the Go project. That said, we're far off from such a reality as @bradfitz pointed out already, and there's a lot of details (many more then meets the eye at this point) that would have to be solved.

Let's consider this as what it is, a long-term vision. No need to expand this into a long-running thread that doesn't go anywhere.

I think this should be reconsidered in light of the new WASM architecture being introduced in 1.11. This kind of work would allow things like the Go playground to be built using WASM, and other cool stuff detailed in #26384 (package-level splitting of payloads, like https://jsgo.io).

It looks like this isn't going to happen any time soon, so for the last few days I've been working on a project to automatically modify the compiler codebase to turn it into a library.

The idea is that it'll wrap up all package level variables in a state object, and replace all filesystem os calls with a virtualisation layer. All these changes to the codebase will be performed by the tool, so as the compiler codebase is changed we can re-run the tool to update the output.

This is a huge project, but I've made some progress... and I haven't come across any terminal blockers yet. It should be noted that the output code won't be of a quality required to merge back into the Go compiler codebase, so further discussion in this issue probably isn't relevant.

I've summarized my progress so far: dave/forky#1 - best to post over there if you want to chat about it. I would love some help with the open issues!

This kind of work would allow things like the Go playground to be built using WASM

That's actually what https://github.com/ccbrown/go-web-gc is. And yes, it could be a lot less hacky if cmd/compile were a library, even if the "API" was just a version of gc.Main with alternatives to all the globals gc uses (i.e. no os.Args, objabi.GOARCH, global flag state, etc.).

go-interpreter/wagon is also using a fork of gc for JIT-ing WASM bytecode:

https://github.com/go-interpreter/wagon/blob/e49671cadc735db68fd1e18ea58ea7e40175257d/go.mod#L5

ie: https://github.com/twitchyliquid64/golang-asm

I imagine #28570 would be a prerequisite for this.

https://github.com/dotnet/roslyn is a working example of this idea that makes posible writing go code analysis tools in go and using go as an embeddable scripting lang. I am currently looking into goja and tengo for the second use case but would be nice to use go for both the container and the scripting glue.