Disallow modification of existing table

[moorereason]

Describe the bug
Given:

[a]
x.y=0
[a.x]

go-toml accepts the input as valid:

$ echo "[a]\nx.y=0\n[a.x]" | gotoml-test-decoder
{
  "a": {
    "x": {
      "y": {
        "type": "integer",
        "value": "0"
      }
    }
  }
}

To Reproduce
https://go.dev/play/p/ta8fAwTBsRM

toml.Unmarshal([]byte("[a]\nx.y=0\n[a.x]"), &v)

Expected behavior
I expected to see an error since a.x is already defined in the first table section.

If you add a y=1 line to the end of the document, go-toml will complain that key y is already defined. This is correct, but the initial [a.x] line should trigger an error prior to that.

Versions

• go-toml: facb2b1
• go version go1.17.3 linux/amd64

Additional context
Found while doing differential fuzzing against toml-dart.

[pelletier]

Actually I think I'm still confused about the whole "create and define" thing for dotted keys. I don't understand why this should be an error:

[a]   # (1)
x.y=0 # (2)
[a.x] # (3)

The way I understand this:

• (1) defines an explicit table at a.
• (2) defines an implicit table at a.x, and a value at a.x.y.
• (3) defines an explicit table at a.x, which is fine because a.x was implicit until that point.

It seems like this example from the spec:

[fruit]
apple.color = "red"
[fruit.apple.texture]  # you can add sub-tables
smooth = true

[moorereason]

I can't say I'm completely confident in my understanding of the spec either, but...

I don't think an "implicit table" is the right way to think of this. My understanding is:

• (2) implicitly creates a table at a.x.
• (3) explicitly creates a table at a.x.
• (3) is invalid since a.x (key x of table a) already exists.
• You can create sub-tables (i.e. keys) under a.x; however, you can't recreate a.x.

The applicable example from the spec is the parts you left out:

[fruit]
apple.color = "red"
apple.taste.sweet = true

# [fruit.apple]  # INVALID        <----- HERE -----<<
# [fruit.apple.taste]  # INVALID

[fruit.apple.texture]  # you can add sub-tables

Hope this helps!

[pelletier]

Thanks! I think the missing piece for me was that the rule for dotted keys within a block (the set of keys between two successive [table], or [[array.table]], or EOF) are different than the rules of the dotted keys in a [table] expression. Within a block dotted keys are allowed to redefine tables (as long as they are not inline tables), but not in a header expression.

The change in #704 basically marks all tables created as a result of key/values as explicitly defined right before the next block starts. That should allow for redefinition within a block but not outside of it.

[pelletier]

Should be fixed in 696dd25. Thank you!