#[should_{fail,panic}](acrichto) rust-lang/rust#21824- irc channels (nrc)
- three/four intermingled error code diagnostic lists? (pnkfelix) rust-lang/rust#19624
- triage meeting (nrc, could be postponed to the actual triage meeting)
- Servo's next rustup plans and random Cargo workarounds and https://bugzilla.mozilla.org/show_bug.cgi?id=1135640 (larsberg)
- type ascription/coercions heads up (nrc) http://internals.rust-lang.org/t/call-for-attention-changes-in-proposed-coercion-rules/1651
brson, pcwalton, steveklabnik, acrichto, nmatsakis, larsberg, nrc, huon, pnkfelix
- brson: nursing buildbots, cargo ci
- pnkfelix; landing stuff delayed for post 1.0; dropck; nonzeroing drop
- nrc: DST coercions
- acrichto: migrating crates.io libs + cargo to std::{io, path}, std::stdio, etc
- acrichto merge rust-lang/rust#21824
- acrichto: Right now, when a test should fail, you mark it should_fail. Was left out of fail->panic renaming. Steve brought up concerns that if a test is still failing, but panicing, method of failure? There may be a deprecation path here. Should we change to should_panic?
- steve: Not in the RFC or discussed, I implemented fail -> panic and made an executive decision
- brson: I was about to make the same patch, but then thought that this was the REAL meaning of fail (i.e., the test fails). More consistent as panic, but maybe less intuitive?
- acrichto: Makes me want to reconsider designing a test infra. I also think of panic as one type of failure. So, should_panic should mean it must be a panic (not some other kind of failure). But doesn't matter too much.
- pnkfelix: I was viewing this as the reason to call it should_panic becasue it's a test success if it panics and it was should_panic.
- brson: That's persuasive.
- acrichto: Convcining.
- nrc: I agree.
- steve: All justifiable. Would love pluggable test frameworks. Happy with whatever.
- brson: Does the patch have a deprecation path for should_fail?
- acrichto: Should.
- nrc: Should have more IRC channels. Having rust-compiler, rust-language, rust-libs, rust-docs... the current rust-internals is too noisy for conversations. That encourages people to have private conversations. More space might help have more convos in public. Downside is more fragmentation. Opinions?
- nmatsakis: Hard to have a conversation on rust-internals
- steve: trying to squash offtopic in #rust. Maybe do that in rust-internals?
- nrc: Not off-topic stuff, mainly on-topic stuff. Fits and spurts.
- pnkfelix: How confident these will be distributed?
- larsberg: Little worried it's already hard to track down servo issues with rust crashes and issues about redesign stuff.
- pnkfelix: Would just be nice to have someplace to take a conversation.
- nrc: Never seen one-off channels work. When I've seen #gfx discussions try to move to, say, #layout, half move but half stay and end up with two conversations.
- brson: Maybe libs and compiler? What's left in internals?
- nrc: Language design! Maybe just leave internals for cross-cutting stuff.
- brson: Maybe this aligns with a hypothetical module system of the future.
- nmatsakis: I like the idea, though also a little wary.
- brson: In a year, those channels will be too full, and we'll have this conversation again. Always running from the crowd. Maybe a role for invite-only channels? Or will just keeping things focused prevent too many conversations at once?
- nrc: My motivation is to make things more public, so opposed to invite-only channels.
- nmatsakis: Not necessary to be invite-only. I do feel like I frequently can't participate in #rust-internals. OTOH, it's possible that we'd have three channels and that would still be true. I could wait and see how things go or we could try the split.
- steve: Had lots of channels that don't have much discussion that I left. Rust-apidesign, etc.
- nmatsakis: Too fine-grained, people don't know what to use in the first place.
- nrc: Cargo is successful, right?
- pcwalton: Sometimes have to poke people on other channels to get answers.
- larsberg: A substantial number of the questions in #cargo do not get answered.
- pcwalton: Have to know whom to CC or nobody pays attention. I usually ask there, then ping acrichto if it doesn't.
- brson: Expect people to come ask for help about cargo there. These channels are not for support desk.
- nrc: Same on other areas. Have #developers for general discussion then #dom, etc. for each area. Maybe gecko's more modular? I'm thinking - let's try it. If it doesn't work, shut them down.
- nmatsakis: Certainly can make a few.
- pnkfelix: Protocol to start in internals and move them? Or do people have to monitor a bunch of different channels all the time? Too much?
- nrc: Yeah, too much.
- nmatsakis: I might try to keep tabs on #rust-compilerinternals but maybe not #rust-libinternals. Depends how much you care to read the backscroll.
- brson: Let's do the experiment - compiler & lib.
- pnkfelix: Need logging.
- brson: Mail the botbot folks. nrc, can you set that up and post an announcement?
- acrichto: If you are mailing anyway, could you add #cargo?
- nrc: What names? #rust-compiler?
- pcwalton: maybe #rustc? Shorter IRC names better.
- nrc: and #rust-libs
- nmatsakis: #std ... nah, #rust-libs
- nrc: OK.
- pnkfelix: Used to have one error code list. Now split into 3 or 4. Intermingled, need to look at them all. Understanding is that it's checked by tidy, but this is surprising. Ticket has some ideas for big infra changes, but are there some smaller solutions that involve not having separate lists? Or do we do this to avoid crate rebuilding?
- brson: Architectural. Refactoring required to merge them. Is the problem that you get merge conflicts? Or just hard to get the next number?
- pnkfelix: Annoying because I didn't know how to get them.
- brson: There's a build command to get the current high number.
tidy-errors - pnkfelix: I'm happy with that for now. Still have a merge conflict issue...
- nrc: Tidy script works?
- brson: I rehabbed it a month ago.
- pnkfelix: If there are gaps in the range, it complains?
- brson: No.
- pnkfelix: Otherwise, we could use the high digits and allocate ranges to crates to avoid the merge conflict issues.
- brson: Could have the script spit out a random 4-digit number that fits in the gaps.
- pnkfelix: Can't tell if you're joking or not :-)
- nmatsakis: It's just meant to be an opaque thing to google for.
- steve: Be nice to have the web pages back online. Then if you have error #18 and it goes away, we don't want it to be reused.
- brson: Not supposed to remove a number if it appears in the list.
- nrc: oops.
- brson: Gaps are partially from removed numbers and partially from skipping.
- nmatsakis: Warning if there's a gap.
- nrc: Sounds like we want more infra if they are to be permanent.
- nmatsakis: I like random numbers! Though we do have to track them forever.
- pnkfelix: I guess I don't see a problem with the random number idea.
- brson: Nothing actionable, though. Is that OK?
- pnkfelix: The build command is great. The other stuff can wait.
- larsberg: waiting for rustup until we merge more pr's and the io changes land. didn't want a half-migration on io.
- acrichto: io hasn't propagated around community yet. tempdirs/files missing, stdio/out/err not converted. done this week.
- larsberg: places where we use old io with our own hooks to call 'cuddle' (?) in gonk
- larsberg: servo is gated on b2s gonk build. mainly because we kept bitrotting the b2g stuff.
- larsberg: now a bugzilla bug for rust support in gecko build https://bugzilla.mozilla.org/show_bug.cgi?id=1135640
http://internals.rust-lang.org/t/call-for-attention-changes-in-proposed-coercion-rules/1651
- nrc: It's come to a consensus position, but changes the coercions RFC. Minor change that brings us closer to what we have today. Implicit coercions are not currently valid casts, so you can't use
asfor them now. We're changing that so that you can in coercions. But in the ascriptions RFC, that change breaks things. So, my proposal is that there is now a lint that warns by default about those casts. So, integer widening could then become a cast. Before I try to get the type ascription RFC approved/merged, I wanted to let people know about it. - acrichto: Warning on unnecessary casts?
- nrc: Yes, casts.
- acrichto: Defined as thing has type
Tcast it toT? - nrc: Trivial and unnecessary are both. If something is a subtype or requires no coersion, that would be an error. If you have something where it can be implicitly coersed, that's a warning.
- acrichto: Worried about there are platform-specific pieces of code where the casts cause errors on one platform but not others. We have a lint, but it's allow by default for that exact reason.
- nmatsakis: Could presumably do it for this platform-specific code?
- acrichto: Yes, but platform-specific code bleeds into everything.
- nrc: Problem now, or only if widening was implicit?
- acrichto: If T as T was a hard error or where T as U was a warning, that would come up. Some platforms it would be a warning/error; on others it would not.
- nrc: T as T is allow by default today?
- acrichto: Yes.
- nmatsakis: I think for integer types.
- nrc: Aha! I can add that.
- acrichto: That's the only platform-specific thing we deal with anyway.
- pnkfelix: I personally don't care about the ambiguity on : T vs. as T and would be fine with not making the change nrc is proposing. Are we just going along with where the RFC discussion ended up or do we actually believe in this position?
- nmatsakis: I don't have strong opinions, though do agree with people who state that : and as should have specific roles.
- nrc: Could be a source of confusion there. Not that : and as would be interchangeable, just that they're only interchangeable in certain places.
- pnkfelix: I thought that you could just use as everywhere and it would work.
- nrc: That's correct. The point of having as is that it's used rarely and an indication of awareness. Will make people numb to the use of as.
- pnkfelix: Ok, I'm willing to go along with that.
- nmatsakis: We could wind up with some intersection. It's unfortunate, but also just life. I did like the cast idea; too bad it's kinda late.
- nrc: Just wanted to bring some attention to this RFC and its potential impact.
- nrc: triage meeting good that triage happens, good that it gives an idea of what's going on or changing. Generally, like 8 or 9 people and we all agree. Only 10% contentious. That doesn't seem like a good use of people's time. Likewise for RFC stuff. Seems like we could make the meeting shorter and more efficient by dealing with only contentious cases at triage. Downside is that it loses keeping everyone informed. So, would like to replace that with a newsletter / digest listing everything that changed priority. I think it'd be a better use of time. Because triage is also not minuted at the moment, we can more widely disseminate the information. Opinions?
- brson: Obvious problem is that somebody has to do this offline work. Good thing about the meeting is that we all plow through this work together.
- nrc: Seem to be a lot of issues that people nominate with a priority in mind. Maybe just assign the priority and it gets put in the digest for people to double-check? Otherwise, if you truly have to think, then we can triage it.
- brson: That's subtle. Our instructions say not to put P tags on things, which would still be true for most people. If we let people apply P tages, we would want only some people to do so.
- nrc: Only people with r+?
- brson: Nothing in github.
- nrc: Maybe bors?
- brson: Right now, we don't trust anybody to triage. Even expanding to all reviewers seems big.
- nmatsakis: Would we know who assigns it?
- steve: Github keeps track of it.
- nmatsakis: The digest would show who assigned it.
- pnkfelix: My concern is that my e-mail is already out of control.
- nmatsakis: Should be a single e-mail per week. We'll probably all ignore this until the meeting, sit down and read it in the meeting, and maybe that will be the new process.
- brson: That doesn't sound too bad.
- nmatsakis: I'm up for experimenting.
- brson: Me too, as long as nrc does it.
- nmatsakis: I'd like to triage over e-mail!
- brson: So, now we will triage things individually. nrc will produce a script.
- nrc: Yes, so let's wait until the script is ready.
- steve: Trying to explain systems programming in Rust to Ruby/JS people. If you have resources you like about systems programming, please forward them to me.