On Mon, Feb 27, 2017, at 09:10 AM, Bobby Holley wrote: > On Sun, Feb 26, 2017 at 9:51 AM, Henri Sivonen <hsivo...@hsivonen.fi> > wrote: > > > I tried to add some panics to a vendored to create (rust-encoding) to > > see if the code in question runs. However, I didn't get to the running > > part, because the edited code failed to build. > > > > It turns out that each vendored crate has a .cargo-checksum.json file > > that contains hashes of all the files in the crate, and Cargo refuses > > to build the crate if the hashes don't match or the > > .cargo-checksum.json file is removed. > > > > This seems hostile not only to experimental local edits as in my case > > but also to use cases such as uplifting fixes to branches and shipping > > modified crates if the upstream is slow to accept patches or disagrees > > with the patches. > > > > As far as I can tell, there doesn't seem to be a way to ask cargo to > > regenerate the .cargo-checksum.json after edits. Also, adding a > > [replace] section to Cargo.toml of libgkrust pointing to the edited > > crate under third-party/rust or adding paths = [ "third-party/rust" ] > > to .cargo/config.in don't make Cargo happy. > > > > Can you elaborate on what goes wrong here? This worked for ted's > experiment > mentioned upthread, and for me on at least one occasion in > https://hg.mozilla.org/try/rev/18dc070e0308 (permalink: > https://pastebin.mozilla.org/8980438 ) > > You'll need to |cargo update| after adding the replace in Cargo.toml to > update Cargo.lock.
This workflow should really be automated via a mach command. Filed bug 1342815 [1] for that. [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1342815 - Xidorn _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
