chore: Update toml to 0.9.7, toml_edit to 0.23.6

[torokati44]

This got unblocked by:
bkchr/proc-macro-crate#61
bkchr/proc-macro-crate#62

I hope the serde version requirement in Cargo.toml won't be left behind by Dependabot even though this bumps it in Cargo.lock. - it did.

[torokati44]

(The motivation was the dep duplication noticed in ruffle-rs/ruffle-android#560.)

[torokati44]

Hmm, should we:

• accept the new error message as expected output
• report the issue upstream as "invalid key no longer reported as invalid"
• change the test to something even more invalider

(@Dinnerbone?)

I don't think the TOML spec changed, even with 1.1.0, to allow keys with ~ in them.

For easier access:

    thread 'preferences::read::tests::invalid_toml' panicked at desktop/src/preferences/read.rs:112:9:
   assertion `left == right` failed
     left: "Invalid TOML: TOML parse error at line 1, column 1\n  |\n1 | ~~INVALID~~\n  | ^\ninvalid key\n"
    right: "Invalid TOML: TOML parse error at line 1, column 12\n  |\n1 | ~~INVALID~~\n  |            ^\nkey with no value, expected `=`\n"

Multi-line strings expanded:

Invalid TOML: TOML parse error at line 1, column 1
  |
1 | ~~INVALID~~
  | ^
invalid key

vs.

Invalid TOML: TOML parse error at line 1, column 12
  |
1 | ~~INVALID~~
  |            ^
key with no value, expected `=`

(And there's also a similar test in frontend-utils/src/bundle/info.rs, but with ??? as input.)

[torokati44]

Went with the first option for now, please do tell if any of you would prefer something else (as well).

[kjarosh]

What's the worst case scenario here? How Ruffle will behave if we cannot parse preferences?

[torokati44]

I guess it's just what the test change shows - not exactly the same error message as before, for preference and bundle files with various invalid/broken TOML content.

[kjarosh]

So will Ruffle crash in this case? I think it's important not to remove any user data in this case

[torokati44]

Just tested - if ~/.config/ruffle/preferences.toml contains borked nonsense (similar to the test case changed by this PR), it will be silently ignored, and if any preferences are changed, completely overwritten. Exactly the same way on master as with this PR.

[kjarosh]

Hmmm, we should probably change this behavior. Either backup the preferences or show a popup asking what to do.

I'm worried that changes in TOML parsing can cause such issues and lead to accidental user data deletion.

[torokati44]

I highly doubt that any config file written by Ruffle (being valid TOML, not edited by hand) will at any point be considered invalid, and overwritten. And in any case, this would be out of scope for this particular PR.

[kjarosh]

I would check if this key works with a value, it may be the case that just the order of validations changed. If it does, we should file an issue, if it doesn't this PR LGTM.

[moulins]

Changing the invalid TOML in the test to ~~INVALID~~ = 1 still gives an error:

Invalid TOML: TOML parse error at line 1, column 1
  |
1 | ~~INVALID~~ = 1
  | ^
invalid unquoted key, expected letters, numbers, `-`, `_`

so this looks indeed like the order of validations changed.

[torokati44]

Thank you for your testing and inputs!