- stability of command line options for --test generated binaries (pnkfelix) rust-lang/rust#24451
- IRC flooding/voiced only mode (steveklabnik/aturon)
- Servo rust update + RVO status? (larsberg)
- Semver RFC (aturon) rust-lang/rfcs#1105
acrichto, pcwalton, larsberg, huon, brson, steveklabnik, pnkfelix, aturon, nmatsakis
- brson: crater, minor 1.0 infrastructure tweaks, twir, swag
- pnkfelix: nonzeroing drop; GC
- acrichto: debugging windows, various cargo improvements
- larsberg: landed this morning a rust from april 29th. will start a new one. getting lots of reports of people refactoring the code and hitting random ice's. many ices during upgrade process. I'll try to log them. will try to upgrade to one from this morning to pick up more fixes.
- acrichto: which rust were you upgrading from?
- larsberg: we skipped the beta releases. somebody has been full-time on the upgrade for weeks. this one was brutal. we're hoping next will be better.
- larsberg: one issue haven't brought up in a while: return value optimization.
-
larsberg: talked about it before in context of 'box'. michael wu is about to upgrade spidermonkey, but he's running into values created on the stack being moved, doing a lot of 'return_address' annotations. he's interested in implementing in rust
-
nmatsakis: 'implementing in rust' requires knowing more about what 'it' is
-
brson: lars, you said he needed to make a lot of annotations. was that on the C side, not the rust side?
-
larsberg: not sure (missed).
-
nmatsakis: i assume this is about wanting to create linked lists up the stack?
-
larsberg: yes?
-
nmatsakis: doesn't sound like rvo
-
nmatsakis: i've been hoping to fix this by integrating tracing, but that won't work when integrating with a C library.
-
larsberg: somebody working on mp4 header decoder now to try to integrate into gecko. looks like rust-url integration will land behind a pref soon. challenge: rust-url is from servo, so matches the spec. question about whether it should match the spec or gecko. some would like it to match gecko. we're doing nothing though, gecko team is driving.
-
nmatsakis: in terms of the work week, i'm not aware of what meetings have been set up to discuss this. maybe we can talk about?
-
larsberg: i'll put on andrea's shared pad
- pnkfelix: test binaries have an option --nocapture. non-std because it's not 'no-capture'. raises question about stability of these options.
- acrichto: I do think this is a heavily used interface, so we should apply the backwards-compatibility guarantees and tread carefully if we break something
- brson: I agree, this is a late stage to make these changes
- pnkfelix: I did suggest that we should take a staged approach that allows people to use the old form -- I suggested deprecation. They've implemented that. Again, my overall concern is the policy here.
- brson: This has the added concern that people want to plug in alternate testing harnesses some day; we need to think about forward compatability. I think we are committed to whatever it happens to be doing right now
- aturon: I recently posted an RFC about the interaction of semver and the library APIs. I was hoping we could have similar RFCs for policies in other areas -- command-line arguments, lints, language features, etc.
- pnkfelix: I hadn't really thought about eventual test harness replacements. I could imagine an argument to --test. I guess the other question is, should we just commit to the current options? Or just deprecate? What should we do on this PR.
- acrichto: I'm a little uncomfortable with this -- we have a good deprecation story for the compiler itself, but the means of deprecation here is a little underdevelopment. It just prints to stderr unconditionally. So I worry about the specifics.
- brson: I agree with the step of making the argument consistent with other arguments and deprecating the existing format. IOW, I like the direction of the PR. I agree with acrichto that we may want some additional infrastucture here with deprecation.
- pnkfelix: The PR also makes some changes around environment variables.
- pnkfelix: Note that this PR would be cherry picked for beta
- nmatsakis: Why?
- pnkfelix: So that we could eventually remove the old option.
- nmatsakis: Hm, I'm not sure we ever want to do that -- aren't we going to have further deprecations like this over time? Won't we just always support these old options?
- acrichto: Same is true in std library... we're going to accumulate deprecated items after 1.0. I don't think we should rush, or cherry pick this change. Not sure when the formal policy for these changes will come out.
- pnkfelix: In that case, we can wait for better infrastructure before landing.
- pnkfelix: someone in #rust was spewing some foul paragraphs of text, kicked, rejoined. steveklabnik changed the channel mode to +r (registered). some questions that intent of channel is for anybody to join, but +r puts up barriers to entry. so turned on +r and some other option that redirects new users to #rust-unregistered. steve has suggested that everyone who is an administrator should join this channel to help newbies.
(missed)
- pnkfelix: any questions?
- aturon: main reason to bring this up to make everybody aware, but also to discuss whether this is a permanent change or not.
- brson: this has happened before and we did it on a temporary basis
- pnkfelix: seems to work, but not everybody knows how to do it (with +rf?)
- aturon: close to accepting governance rfc, which creates a moderation team. that group of people will probably be smaller than the ops, but they can hopefully set this policy and making sure ops understand it.
- aturon: another heads-up. rfc
(missed)
- aturon: the way rfc is set up, changes that are non-breaking but technically breaking have a specific form where you could have written the downstream code differently to avoid the breakage. you could imagine cargo automating this process, set cargo up so that when you compile your crate, in addition to generate lock file it generates elaborated form of the source. if you do that the breaking changes are no longer breaking. the way its written, this is explained as a step we could take in the future. some are arguing that this is an essential part of the rfc you have to be able to upgrade guaranteed without breakage.
- nmatsakis: how much does semver fall down if its not a true guarantee? the lockfile helps
- pcwalton: semver has traction in the node community but in javascript you can't add anything ever without causing breakage. should make clear that nobody really follows semver - there are too many ways to depend on a specific minor version.
- aturon: i haven't heard many people arguing for that level of guarantee, but with what we're talking about you can break code by implementing a trait. the way i wrote the rfc treats elaboration as a mitigation we can apply later. i see the RFC as setting a baseline of things that are definitely major changes, and things that are not. risk of iterative approach muddies stability message.
- acrichto: I'm curious to see what actually happens in the wild. Listing it all makes it look bad, but I'm hopeful we won't actually run into it often.
- brson: you've classified every breaking non-breaking change in a way that can be syntax-expanded to avoid?
- aturon: not all, e.g. a fn with type parameters and you want to add a new one, that's breaking, because people calling it with explicit type params could break.
- brson: sounds like it could be defined in a way to make that scenario work. not worth discussing now
- aturon: of changes that are allowed, they mostly have to do with globs, which can be desugared, or method dispatch, which can use UFCS.