18 で言った「多数のパッケージを一つのワークスペースで管理することでwarmupを不要にする」という話です。

Rustのワークスペースは同名のbinを含むことは非推奨でcargoコマンドの度にwarningが出ます。無視するにしてもrust-analyzer等のツールが将来にわたって動いてくれるとは限りません。ゆえにbinのリネームが必要だと考えます。

binをリネームするにあたってproblem-idとbin名の対応をどうするかですが、ユーザーの既存の環境の互換性を考えると単純に<bin> = <contest-id>-<problem-id>等と仮定するよりはリネームするタイミング(new時)でしっかりとメモするのが良いと思います。 Cargo.tomlにはpackage.metadataといううってつけのフィールドがあります。

この考えの下で以下の方法を提案したいと思います。どうでしょうか?

cargo atcoder new時にbinの名前は<contest-id>-<problem-id>と、ファイル名は従来のまま<problem-id>.rsとする。その際package.metadataにproblem-id → binの対応をメモする。
cargo atcoder new時に既存のworkspace下に追加されるなら、(cargo newする前に)そのworkspaceのmembersに追加する。 そうでないなら、従来通り1パッケージからなるworkspaceを新たに作り、そこにprofile.releaseを書く。
cargo atcoder new以外のコマンドでは、1.でメモした表があるならそれでproblem-id → binを得る。 そうでないなら、従来通りproblem_id = binとする。

# <workspace-root>/Cargo.toml

[workspace]
members = ["./abc126"]

# packageの方ではなくこちらに書く
[profile.release]
lto = true
panic = 'abort'

# <workspace-root>/abc126/Cargo.toml

[package]
name = "abc126"
version = "0.1.0"
authors = ["Ryo Yamashita <qryxip@gmail.com>"]
edition = "2018"

[package.metadata.cargo-atcoder.problems]
a = { bin = "abc126-a" }
b = { bin = "abc126-b" }
c = { bin = "abc126-c" }
d = { bin = "abc126-d" }
e = { bin = "abc126-e" }
f = { bin = "abc126-f" }

[[bin]]
name = "abc126-a"
path = "./src/bin/a.rs"

[[bin]]
name = "abc126-b"
path = "./src/bin/b.rs"

[[bin]]
name = "abc126-c"
path = "./src/bin/c.rs"

[[bin]]
name = "abc126-d"
path = "./src/bin/d.rs"

[[bin]]
name = "abc126-e"
path = "./src/bin/e.rs"

[[bin]]
name = "abc126-f"
path = "./src/bin/f.rs"

# こっちではなくroot manifestに書く
#[profile.release]
#lto = true
#panic = 'abort'

[dependencies]
proconio = { version = "0.4.1", features = ["derive"] }

(edit) 互換性を保とうとする理由ですが、Codeforces等にも参加している人なんかはstdしか使わないのでこの機能による恩恵がほぼゼロに等しく、そういう人にとっては煩わしさの方が勝ると思われるからです。実際Rustの提出をスクレイピングしてみると、2020年環境であってもproconioを含めクレートを使用している人はあまり多くはありません。

submissions

tanakh / cargo-atcoder

Support workspaces #35

18 で言った「多数のパッケージを一つのワークスペースで管理することでwarmupを不要にする」という話です。