On Mon, Feb 27, 2017 at 9:56 AM, Henri Sivonen <hsivo...@hsivonen.fi> wrote:
> On Mon, Feb 27, 2017 at 7:47 PM, Ted Mielczarek <t...@mielczarek.org> > wrote: > > On Mon, Feb 27, 2017, at 12:32 PM, Henri Sivonen wrote: > >> We don't seem to need such change control beyond hg logs for e.g. the > >> in-tree ICU or Skia, though. > > > > As someone who has maintained a vendored upstream C++ project (Breakpad) > > for a decade, I can say that this causes us headaches *all the time*. > > OK. > > > I'm sorry this is causing you pain, and we should figure out a way to > > make it less painful, but note that the intention is that things in > > `third_party/rust` should be actual third-party code, not things under > > active development by Mozilla. We don't currently have a great middle > > ground between "mozilla-central is the repository of record for this > > crate" and "this crate is vendored from crates.io". We're finding our > > way there with Servo, so we might have a better story for things like > > encoding-rs when we get that working well. > > Note that my problem at hand isn't with encoding_rs but with the > currently-vendored rust-encoding. That is, I indeed would like to add > a diagnostic panic!()/println!() to genuinely third-party code--not to > code I've written. > To be clear, I totally agree that local debugging-oriented edits to vendored crates should be painless. A 1-line mach command to add a cargo [replace] and update Cargo.lock (with a helpful message if somebody forgets to do that) seems like the right way to do that. > > That is, I'd like to experimentally understand what, if anything, > rust-encoding is currently used for. (My best current hypothesis from > reading things on SearchFox is that it's used in order to be able to > compile one Option<EncodingRef> that's always None in Gecko.) > FWIW, |cargo tree| is a very helpful tool to figure out who's pulling in a crate. > > -- > Henri Sivonen > hsivo...@hsivonen.fi > https://hsivonen.fi/ > _______________________________________________ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform > _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
