Language record

TOML

A manifest is indexed as its dotted structure: the file is a module, every `[table]` is a namespace, every `key = value` is a property, and a symbol's name is its full path from the document root — so `[workspace.lints.rust]` is one symbol with exactly that name, not a leaf called `rust`.

.toml · 1 registry id · 4 of 14 relationship types

The registry row this page is generated from

Read at render time from the same family row the register reads, so nothing in this block can disagree with it.

Extensions: .toml
Registry names: toml
Recorded symbols: tables · keys · dotted paths

Relationship types this analyzer constructs

4 of 14 constructed, read from this analyzer's source and re-derived by the languages gate. Each row below is one of the engine's types, in the engine's own order.

Relationship type	Constructed
`calls`	ruled absent
`extends`	ruled absent
`implements`	ruled absent
`uses`	ruled absent
`imports`	constructed by this analyzer
`exports`	constructed by this analyzer
`contains`	constructed by this analyzer
`references`	constructed by this analyzer
`overrides`	ruled absent
`instantiates`	ruled absent
`decorates`	ruled absent
`renders`	ruled absent
`mixes_in`	ruled absent
`part_of`	ruled absent

4 constructed, 10 not constructed. All 10 absent types are recorded as ruled absent: the written reason and the corpus measurement behind each are in this family's completeness record. The register explains what each label means.

What this analyzer does not resolve

The relationship vocabulary is contains, and that is the whole truth — not a thin graph but the format's shape. TOML defines no include, no import and no reference: path = "src/main.rs" is a string, and treating path-shaped strings as links would import ecosystem knowledge about which keys are paths in which tool into a format that has none. So there is no uses edge here, and the other types are absent for the same reason they are absent from HTML: no TOML construct produces them.
An implied parent is recorded, not invented. [a.b.c] implies a and a.b whether or not the file writes them; the names land in the table's metadata and no symbol is fabricated for a header the document never declares, because an edge to a target that does not exist is the unresolvable-identity defect.
An inline table's keys are not symbols. x = { a = 1, b = "two" } makes x the symbol and the inner key names ride on it in its metadata — a Cargo.toml with 200 dependencies written that way would otherwise publish 600+ names that nothing can navigate to on its own. A value of any type publishes nothing either: it is data, recorded as a value kind on its key.

Every line above was written against TOML’s own analyzer module and is named against a construct in it, so it can be checked against the source. Nothing here is inherited from a template, or from another language’s page.

Where you meet it in a repository

Recognised by extension — .toml. Everything below is about where those files actually sit in a working repository.

Cargo.toml, pyproject.toml and rust-toolchain.toml are the same document shape, and the file's stem is the root: Cargo.toml is the module Cargo, because Cargo is what a person would search for rather than a filename.
[[bin]] and [[patch]] are arrays of tables. Each header opens a level the keys beneath it belong to, the second element takes a #2 suffix, and its keys are prefixed with the ALLOCATED name — so bin.name and bin#2.name cannot collide.
A lockfile is TOML as well: Cargo.lock is thousands of [[package]] entries, so a manifest and a lockfile are two very differently sized instances of one shape. Across cargo's 684 tracked files the analyzer published 6,409 symbols and 5,725 contains edges, with 0 duplicate names and 0 edge targets that resolve to nothing in the whole 835-file pool.

Questions this index answers

Phrased as retrievals, because that is what an index can honestly do: it holds the symbols and the edges between them, and hands them back with the evidence attached.

Which tables does this manifest declare, and how deep does the key path go?
Where is this key set, and which table owns it?
Which dependencies does this package declare?
Which ancestor tables are only implied by a deeper header?

What the analyzer sees in code like this

A table header, the full dotted path it becomes, and a key beneath it

[package]                 # bb records: table package
name = "acme"              # bb records: key package.name
version = "0.1.0"          # bb records: key package.version

[workspace.lints.rust]     # ONE symbol, named workspace.lints.rust — the whole dotted path
rust-version = "1.80"      # bb records: key workspace.lints.rust.rust-version

[dependencies]             # bb records: table dependencies
serde = "1"                # bb records: key dependencies.serde — and no edge to any file

Symbols are stored with the file they came from and the bytes they span, so a hit points at a line rather than at a guess. The annotations in the sample are commentary for the reader, not strings the index would store.

Languages that turn up in the same repository

Web, data & config — the count beside each name is how many relationship types that family’s analyzer constructs.

The extensions, registry names, recorded symbols and relationship types above are the parser registry row for TOML, read while the page rendered — the same row the register reads, so the two surfaces cannot tell two stories. Every relationship type listed as constructed appears in src/ast/real-*, the analyzer modules bb ships. bb 0.1.0 answers from a local store over 50 languages (53 registry ids, three of them aliases). There is no benchmark on this page: every claim here is one you can go and read in the source.

The whole register How the index is built The 16 tools that read it