Cargo-edit: Algum cargo.toml fica embaralhado ao executar a atualização de carga

Ei @Eijebong , sim, é uma limitação conhecida da biblioteca toml subjacente que usamos atualmente no cargo-edit. Seria corrigido quando / se mudarmos para tom .

Claro, falei com @killercup, que me disse para abrir isso para verificar se o switch resolveria esses casos

Eu estava conversando com o mantenedor de combine (que é usado por cargo_edit ) no gitter, e acho que se armazenarmos uma lista de posições inicial + final para cada tabela na árvore, então poderíamos serializar tabelas / fragmentos de tabela não modificados de volta em sua forma + posição original. Isso poderia ser feito potencialmente sem substituir o cargo-edit.

Você ainda teria essa classe de bug se tentar editar uma tabela fragmentada, mas deve ser possível emitir um aviso (ou falha total e exigir um sinalizador --regroup) nesse caso, devido à necessidade de editar programaticamente tais tabelas seriam muito raras.

Isso soa como uma ideia sensata?

Enquanto eu estava ocupado procrastinando, na verdade, para começar com o plano acima, eu clonei rust-lang / rust-repos e fui procurar exemplos de Cargo.toml no github. Encontrei 80164 arquivos Cargo.toml nas raízes dos repositórios git. Eu limpei os finais de linha do DOS e as novas linhas finais perdidas manualmente.

Em seguida, usei cargo add para adicionar uma dependência.

Das 80.164 amostras que encontrei:

• 2310 eram manifestos virtuais
• 54 eram sintaxe inválida
• 69455 (87%) acabou de adicionar uma única linha (como esperado)
• 6889 (9%) também adicionou uma seção de [dependências] (ainda bem)
• 1457 (2%) também fez outra coisa (principalmente mover seções do arquivo, mas ~ 10 também fez alterações nos espaços em branco, como remover espaços dos cabeçalhos das seções)

Descarreguei uma lista de links para os arquivos 1457 em https://raw.githubusercontent.com/alsuren/rust-repos/cargo.toml-samples/largest-diffs-last.urls . Os arquivos com as menores diferenças estão no topo, e as maiores diferenças estão na parte inferior. O caso de uso que produz regularmente grandes diffs é ter uma seção [package.metadata.deb] ou [package.metadata.release] ou [package.metadata.bootimage] no final do arquivo.

Eu tenho um dia de folga na quarta-feira, então posso tentar resolver isso então. Alternativamente, eu poderia resolver o # 217 primeiro, porque provavelmente é mais fácil, embora eu só tenha encontrado 191 arquivos onde há mais instâncias de = *' que = *" .

Acredito que isso seja resolvido em # 312. Sinta-se à vontade para reabrir se não for o caso.