- removing
#[unsafe_destructor](pnkfelix) rust-lang/rust#22196 (comment) - elem drop order "ugh, again?" (pnkfelix) rust-lang/rust#23222
- libtest and stabilization (acrichto)
steveklabnik, acrichto, nmatsakis, huonw, pnkfelix, nrc, brson, aturon, pcwalton, pnkfelix
- brson: Make rustup work with beta. taskcluster-crater
- acrichto: rollups, stabilization holes, cargo PRs
- nrc: coercions and casts, unqualified assoc types
- pnkfelix: will remove #[unsafe_destructor] after PR 23638 lands
BurntSushi is an individual who practically needs no introduction. He's written many of the world's most popular crates, including docopt.rs, regex, quickcheck, cbor, and [byteorder]. Don't forget his CSV swiss-army-knife, xsv, built on rust-csv. Feedback from his early work on libraries helped informed the evolution of Rust during a critical time in its development, and BurntSushi continues to churn out the kind of Rust gems that can only come from someone who is a skilled friendofthetree.
rust-lang/rust#22196 (comment)
- pnkfelix: For a while, wasn't sure if this would happen, but as of last night, I think we can do it. The last piece has a PR that's ready to land.
- pnkfelix: So how do people feel about removing the attribute and seeing how it works out? Versus waiting for the beta period.
- pcwalton: I say kill it, it's a big wart.
- nmatsakis: Kill it.
- brson: Where does the confidence come from?
- pnkfelix: Reason :P The system seems to bootstrap, known flaws are addressed. We don't have a formal proof, but then again, we don't ahve that for the type system either.
- pnkfelix: The other big thing I was worried about was things in std like libarena where the arena type was using destructors in an unsound way. I fixed that, but thought we should audit libstd. But nmatsakis pointed out that a lot of cases where that would be the case are unstable anyway.
- nmatsakis: Did you have specific cases in mind?
- pnkfelix: Not really.
- nmatsakis: The property that made arena unsafe was running drop for an unbounded set of types. TypedArena is safe by the rule.
- pnkfelix: Right. No constraint on the lifetime of the thigns you allocated with it, so you could make cyclic structures where the order was not defined.
- nmatsakis: And you couldn't use phantom data to explain to the compiler. Seems fairly unique to this case, but we may be missing PhantomData in a few places.
- pnkfelix: Yeah, so I feel like a once-over could happen during beta.
- nmatsakis: Agreed.
- brson: What's the impact on users?
- pnkfelix: They have to remove it, but we could keep it as a no-op for now with a warning.
- brson: Basically they just have to remove this feature, no other changes. So if there's breakage, we'll hear because of crashing.
- acrichto: They should already be crashing. The semantics has already been changed.
- pnkfelix: The Drop implementation bound didn't have to match up with the actual type bounds. So you could create mismatches. Can't assume that would be caught.
- nmatsakis: But the presence or lack thereof of the unsafe_destructor doesn't change things. Once the PR fixing this lands, people will immediately see breakage. You may still have to have unsafe_destructor just to get generic type params at all. But you shouldn't see problems from dropping it.
- pnkfelix: Right, the analyses are supposed to prevent this kind of thing from arising.
- brson: How many crates would this make stable?
- pnkfelix: Not sure. All: Let's do it
-
pnkfelix: This is a longstanding thing. The issue is that our drop order isn't always consistent, and in this particular instance, if you're in the midst of constructing an array and panic, it will drop the elements you've made so far in reverse order. But if you finish construction, then it will drop IN ORDER. Pretty weird!
-
nmatsakis: You should review the struct case. That affects my opinion.
-
pnkfelix: There's data in the issue. The struct case is currently in-order.
-
nmatsakis: That's not the whole story. If you have a struct literal, you can put the fields in any order, and if it's partially destructed midway, we go inside-out, in the order you wrote them in the literal. In some sense, this is consistent: things that aren't fully built go inside-out, and finished things go in-order. It seems plausible. Though we could easily change it to go back to front in all cases.
-
pnkfelix: Right, so what's the motivation?
-
nmatsakis: I don't care. C++ always does back-to-front, maybe we should just do that.
-
pcwalton: Agreed.
-
pnkfelix: kballard points out that Swift goes front-to-back.
-
pcwalton: Is that intended/documented?
-
nmatsakis: We should probably just match C++
-
pnkfelix: OK. I will post an RFC on this topic, then.
-
acrichto: We do have an issue, I think huon opened it, about eval order. We closed that. We haven't tended to strictly define that, don't know that we have to be so formal.
-
nmatsakis: I disagree, it's important that the eval order is well known.
-
acrichto: I'm thinking of rust-lang/rust#15300
-
acrichto: Just not sure it's the time to lay this out formally right now.
-
nmatsakis: Right, could just file a bug on this. It's borderline.
-
pnkfelix: in the past, pcwalton has argued that this should be unstable for 1.0 but that was a while ago
-
pcwalton: I still feel that way. There are some things that are unspec'ed right now. We shouldn't rush into it. E.g., I'm not sure of the exact rationale for C++'s design here, and I'd like to understand better before committing.
-
nmatsakis: I think it's pretty clear.
-
pcwalton: Sure, it matches the stack discipline.
-
nmatsakis: We probably have some freedom. But being able to run CI against the ecosystem would be important to make changes -- people could start relying on it.
-
pnkfelix: Is CI happening?
-
brson: Yes!
-
pcwalton: Definitely good to do during beta. Ideal 1.0 polish.
- acrichto: Talking about moving to stable rust: it's currently not possible to use #[bench] on stable rust, because you have to do
extern crate testand use theBencherstruct. I had an attempt to stabilize in the past, but it didn't work out. - acrichto: I wanted to bring it up again as, this is an area with no stabilization plans for 1.0. It seems a little different from other cases -- I can build and people can use my crate on stable rust, but to bench it I need a nightly.
- acrichto: Does anyone have ideas here? Not sure I want to invest a lot of time here.
- aturon: What's the actual blocker to stabilization here?
- acrichto: I moved the benchmarking infra into rustc_bench, which was stable. It just had one stable thing in it. So to write a benchmark, you'd have to use this crate. brson had some concerns that anyone creating their own rustc implementation has to deal with this random crate.
- aturon: Isn't this similar to serialization?
- acrichto: The ideal is a pluggable bench framework. That's quite a distance from what the PR was proposing.
- brson: I hate things called rustc_blah. Also, are you concerned about taking up the name "test"?
- acrichto: Yes. Our libtest is pretty skimpy. I'd rather have this name for a richer framework.
- brson: We're talking about exposing only a couple of things. So you could imagine expanding to a much richer framework in the future. Seems likely that we would always provide some test infrastructure. Or you could provide it in std.
- acrichto: Yeah, but that would stick out as a sore thumb.
- steveklabnik: I personally prefer using an external crate and drop-in replacement there. Basically then you could put our crate up on crates.io.
- acrichto: Right, a plausible thing would be to keep #[bench] and then somehow it calls a top-level fn in some crate. I want pluggable test frameworks like that.
- brson: Is there an out-of-tree framework? Just take a closure.
- acrichto: But you don't get #[bench]. This does affect Cargo somewhat, since it has a bench mode.
- aturon: I feel fine with punting. This is really different from e.g. serialialize, for two main reasons. One, as you said, you can still build/use the crate on stable. Two, we're much closer to having the ideal (pluggable) infrastructure, since it doesn't seem to need plugins/extensions etc. We should make a FAQ about gaps and works-in-progress like this so people understand what's coming and how to deal with stability issues
- acrichto: Coming next week! [all: look at milestoned issues]