Only exported paths need to be here, right? You talk about local defs
not being stable, but we recompile a crate at a time, so any local use
of a local def becomes a "pointer".

Also, these table contains only constant and functions, right? Types are
in the table you describe afterwards.

In order to use the regular system linker, the exported functions and
constants have to be listed as mangled symbol names. Since we are
already paying the cost of having a mangled symbol, we can probably use
that to find the metadata about that symbol. Having our table be indexed
by a hash of the symbol name for example.

Invitation to comment on a wiki page (crate file format stuff)

(Heh. It looks like discussing on a Wiki isn't something this team is
used to. Graydon discussed this on irc, you over e-mail. Oh well.)

> Only exported paths need to be here, right?

Right.

> You talk about local defs not
> being stable, but we recompile a crate at a time, so any local use of a
> local def becomes a "pointer".

By local def ids I meant the second number in a def_id pair -- the
things the parser assigns to defs. If they were stable, we could
directly refer to a def_id in another crate, but minor syntactic
changes can change them, so we must use full names.

> Also, these table contains only constant and functions, right? Types are in
> the table you describe afterwards.

No, types are also indexed by name here. The type table maps from ids
to types. This may seem needlessly indirect, but it maps precisely to
the resolve pass being separate from the typecheck/translate passes.

> In order to use the regular system linker, the exported functions and
> constants have to be listed as mangled symbol names. Since we are already
> paying the cost of having a mangled symbol, we can probably use that to find
> the metadata about that symbol. Having our table be indexed by a hash of the
> symbol name for example.

As I understood it, these hashes will also contain type info. The
resolver doesn't know anything beyond a path when it is resolving
something, so we need to have raw paths as keys (I think).

Invitation to comment on a wiki page (crate file format stuff)

On 11-03-15 11:28 AM, Marijn Haverbeke wrote:
> (Heh. It looks like discussing on a Wiki isn't something this team is
> used to. Graydon discussed this on irc, you over e-mail. Oh well.)

Well, I like email mostly because it creates a very easy to index record
of the conversation.

> No, types are also indexed by name here. The type table maps from ids
> to types. This may seem needlessly indirect, but it maps precisely to
> the resolve pass being separate from the typecheck/translate passes.

...
>
> As I understood it, these hashes will also contain type info. The
> resolver doesn't know anything beyond a path when it is resolving
> something, so we need to have raw paths as keys (I think).

Ah, I think I see what you are trying. My original idea was that we
would handle metadata only things (like types) a bit more efficiently by
not mangling them at all. They would use something like a hash for each
module.

Resolve doesn't know what the types are, but it knows if something is a
type or not.

I guess it is OK if you want to mangle all paths the same for now, but
there are some things that can be done more efficiently for paths that
the native linker doesn't needs to see:

*) They can be local
*) Being local they don't need the hash prefix
*) We don't even need to make them real symbols, we could have a
internal more efficient representation.

Invitation to comment on a wiki page (crate file format stuff)

> I guess it is OK if you want to mangle all paths the same for now,

Actually, I wouldn't be mangling them at all. The path table only
stores crate-local paths, which are already unambiguous. The linker
symbols will be mangled, but those will only be generated for actually
linkable things like exported functions and consts.