Deal with copies of a library

[stefnotch]

With package managers, it's somewhat easy to get two copies of the same library. Like assert@0.0.1 and assert@0.0.4.

This can very much affect name mangling. Mapping two separate libraries to the same name is clearly a bug. Should we have version numbers in the mangled name? Should we not expose a mangling system and instead adopt a different system for entry points and pipeline overridable constants. Those are the only places where name mangling is observable after all.

[ncthbrt]

Could we leverage semantic versioning in names somehow? Like only include the major version?

[stefnotch]

No, we cannot use semver for the names of the generated WGSL. While Cargo follows semver, npm does not always follow semver.

And even with Cargo, one can write

my_crate ="=1.2.3"

my_crate = { version = "=1.2.5" }

my_crate = { git = "https://github.com/example/my_crate.git" }

So at best we can include the full version in names. But even that doesn't quite cut it, because of things like git dependencies.

So the only thing that we can actually do is "get some unique identifier => put in names".

Rust actually does exactly that

A very similar disambiguation is needed for avoiding conflicts between crates of the same name but different versions. https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html

[mighdoll]

I'd suggest that separate versions of libraries be duplicated by default and that we provide metadata in wesl.json to allow linkers and language servers to track versions.

Each package should store its name and version number and the version number and name of every package that it directly imports. The main application doesn't need a name or version number, but it does need the name and version number of the packages it imports.

Linkers would use the version info to decide whether to share or duplicate any element imported from another package.

I'm assuming that host visible names like entry points from packages are not visible in mangled form. Instead host visible names would be explicitly exported by each package, and no package can export a duplicate name. That's worth discussing further elsewhere, but note some ideas for explicitly publishing via the root module, or annotation.

[mighdoll]

Discussed at 20-09-19 meeting, consensus agreed that:

• multiply-imported packages with the same version are not duplicated
• importing a package with different versions (or different parameterizations if those are allowed) are duplicated.
• semantic versioning issues can be handled by the package manager external to wesl tools. i.e. the package manager can decide if 1.0.1 is the same as 1.0.2 and gives the linker / language server one or two versions.

Noted two issues for further exploration:

• hashing / virtual hashing idea from @unconed, as a way to identify shared elements that don't need duplication even after parameterization
• review issues about granularity of duplication if we allow parameterized packages - duplicating an entire package in that case perhaps would duplicate too much.