Remove owned string literal

[richo]

Had a quick stab at this with a sed macro.

Fixed a lot of strings, but there's a bunch of tidy errors because of the increased line lengths now, definitely some broken tests, and isn't complete.

Pushing purely so that there's state on this. /cc #13543

[richo]

So having played with this a little.. should I be using the str! macro instead, purely for brevity?

This upsets a LOT of checking because of how much longer it makes lines that include more than one string.

[brson]

@richo No, I think what you've done with to_owned is fine. Can you rebase so this can be merged? This looks a good start, and I think it's best to merge in pieces so to avoid clashing with @pcwalton.

[richo]

I broke a bunch of tests while I was doing this, I think (based on my make check) run last night. I think mostly to do with the repr of strings.

Regardless I'll rebase and push now.

[richo]

(FWIW rustc builds and does reasonable things with my stripe bindings after this patch)

[richo]

Rebased.

[brson]

@richo GitHub still says it can't merge. Maybe something landed that conflicted after you rebased (perhaps another good reason to do this type of change in small chunks).

[richo]

Entirely valid. Should I split this into per-file commits maybe?

[richo]

I just rebased again. Assuming noone pushes anything conflicting before you get a chance to look at it, this should be merge-able, but I'm open to the idea of splitting this up a bit.

My only real concern is the amount of merge bubbles I'll create by doing this one lib at a time. Totall appreciate you working with me on this though :)

[richo]

I'm getting this failure locally too:

/home/travis/build/mozilla/rust/src/libstd/tuple.rs:272:21: 272:35 error: type `&'static str` does not implement any method in scope named `to_owned`
/home/travis/build/mozilla/rust/src/libstd/tuple.rs:272 let a = (1, "2".to_owned());
^~~~~~~~~~~~~~

Is this a bootstrapping issue? eg, it's building a stage with a rustc too old to know about it?

[brson]

@richo No, probably not. The to_owned fn is defined by the std::str::StrSlice trait, which is typically imported by the prelude, so available everywhere. std though does not import the prelude, so all imports must be explicit. This code is probably just missing the import.

[richo]

Thanks, I was just about to push changes backing out of the change in those modules, but instead I'll fix it. I won't push again till the tests pass locally.

[richo]

That unused import warning is a bug, since StrSlice is used in both a #[cfg(test)] and a #cfg(not(test))].

[richo]

These test breakages are new to me (but consistent with my dev environment).

Any ideas @brson / @pcwalton ?

(Sorry for the delays in getting this in)

[flaper87]

This should be written as:

Err(...);
//~^ ERROR: cannot determine a type for this expression: unconstrained type

The line with the error should go right next to the statement that should fail. If there's a tidy error, you can do what I've done in the example above. That is, put the expected error in the line below and use a ^ to specify that the expected error should be raised by the line above the comment.

[richo]

Thanks for all the feedback! Updateing now.

[richo]

I think the tests all pass locally (I'm waiting on make clean && make -j4 check now), and I've rebased on master.

[richo]

And the tests pass!! \o/

/cc @brson

[brson]

Since I never get to this before it goes stale, I've rebased and pushed to my own branch to land: #13607

It should land today. Thanks for your patience!