- new snapshots (acrichto)
- transmute::<&T, &mut T> lint (acrichto) rust-lang/rust#24392
- rust podcast (acrichto)
- Servo - rustup blocked on rust-lang/rust#24687 (larsberg)
pcwalton, nmatsakis, aturon, acrichto, brson, pnkfelix, larsberg, nrc, steveklabnik, huon
- acrichto: landing fs improvements, landing musl, stability cleanups/reviews
- brson: party planning, crater, 1.0 issues
- nrc: rustfmt, MultiDecorators
- pnkfelix: 1.0 issues, gc planning
- aturon: virtual structs, Rc leakage issues, API evolution RFC
- brson: start internals thread on packaging
- larsberg: hit an ICE in codemap multibyte character code. I removed all unicode characters and we still hit the problem. felix is investigating
- pnkfelix: from all deps?
- larsberg: yep! Everybody likes unicode symbols.
- acrichto: Can you turn off debuginfo?
- pnkfelix: it's connected to that
- larsberg: maybe. w/o debuginfo we can't profile, and perf regresses w/in minutes. big source of perf regressions is rust upgrades. need a fix
- nrc: how is this related to debuginfo?
- pnkfelix: it happens during a query of the codemap while generating debuginfo. stopgap measure to return bogus spans.
- larsberg: not first time we've hit debuginfo problems. wouldn't be against hardening the code.
- pnkfelix: warning would be a nice way to deal with it
- nmatsakis: a compiler-bug lint...
- acrichto: Talked to Alex Newman yesterday, starting a rust podcast. Not exclusively about rust, but topics pertaining to rust. Sounded cool to me. Interested in help from us, guests, etc. Fine w/ any topics. I'll probably sign up. Also interested in Servo.
- acrichto: he's got some other people lined up as well.
- acrichto: haven't made a snapshot since 1.0.0-beta. Curious whether we want to keep it that way. Someone built a new one this morning.
- steveklabnik: to make progress on associated constants
- huon: packages would prefer as few snapshots as possible. they would prefer compilers build with previous releases (so they can do their own bootstraps).
- huon: talked to debian developer. if 1.0 can build with 1.0 that would be useful.
- brson: skeptical that now is the right time to make policy changes here
- nrc: don't want to be hamstrung on compiler development to a 6-week snapshot cycle
- pnkfelix: huon wants 1.0 to compile with 1.0, not 1.1 compile with 1.0
- huon: 1.1 built with 1.0 would be useful as well
- pnkfelix: also wouldn't want to hinder our ability to produce snapshots, though i'd be fine 'tying the knot' with each release.
- huon: w/ more fine-grained staging, with certain compilers using certain code
- nmatsakis: rather see this as a longer-term goal. as rust matures this will get more realistic. would be fine if eventually we build with the previous release, but not there yet
- pnkfelix: e.g. if we proposed this rule today i'd have a lot of pressure to get code into 1.0 so it would be ready for 1.1.
- brson: would be nice to give distros a hand
- nmatsakis: would tying the knot actually help for distros?
- brson: no, it would have to build with the previous release
- huon: talked to debian packager, and they are over most hurdles
- brson: keep that dialog open. we want to help
- larsberg: distribution issue is important for gecko. they expect to get compilers via distributions on linux
- brson: is this packaging issue something we should invest in?
- acrichto: seems like it won't happen otherwise
- nrc: (agree)
- larsberg: also lets you work out the side-by-side story
- acrichto: would like to just know the status. why aren't these things happening? maybe start an internals post
- acrichto: lint, deny by default, to transmute &T to &mut T. me not a fan. 1) lint for undef behavior, 2) this only covers one small case, doesn't catch the biggest abuser of &mut T in std. Don't like this kind of lint.
- nmatsakis: didn't realize it was deny by default, do we have any others like that?
- nrc: I'm a big fan, but would be happy with warn by default. Don't feel strongly that deny by default is wrong. That it doesn't catch everything suggests to me it should be a lint.
- nrc: I was also a bit persuaded by the comment that in some contexts this could be defined
- acrichto: to me it's also unclear what the undefined behavior is. calling transmute isn't undefined, but mutating data in inappropriate circumstances is
- acrichto: exceeding_bitshifts is deny by default
- nrc: one reason its undefined behavior is we might want to do more optimizations in the future. knowing &T is never transmuted to &mut T ensures safety of const and can be used for optimizations.
- nmatsakis: touches on question of what sort of aliasing rust guarantees and what we can optitmize. complex question. transmuting &T to &mut T and mutating is frequently illegal. not sure in the end whether it will always illegal. this depends on the relationship of unsafe pointers and aliasing rules, which we haven't had time to hammer out. lint seems 'ok'. growing set of lints is unsettling. were talking about backporting, do we want to take the PR but not backport it?
- acrichto: hasn't been accepted
- nrc: I do think this is a really important lint. I've done this at least 3 times. You come across transmute relatively quickly, people will know about it. transmuting &T -> &mut T is an obvious thing to do for people from C++, whereas there's no reason to know that UnsafeCell exists. important to have a lint to catch this obvious antipattern.
- acrichto: unsafe docs need improvement. failure mode here is someone adds a new lint in a few months catching more special-case ways to invoke undefined behavior. that's my worry.
- huon: what's the problem with lints catching ub?
- acrichto: i want an external crate with all these lints turned on. (?)
- nmatsakis: general sense that there are too many lints
- aturon: would you prefer a single lint to catch ub?
- nmatsakis: I found nrc's const-cast analogy confusing. I think having one undefined behavior that lint, rather than a series of individual lints, that tries to catch specific instances of things we can't prevent in general makes sense though.
(daydreaming)
- pnkfelix: (what about a lint that catches repr(C) + Drop?)
- nrc: I'd say warn by default. you might just want repr(C) to define the order of the fields, not just the size of the struct. There may be use cases where you have Drop and repr(C).
- nmatsakis: I think all things considered I'd prefer to just have all lints be warn by default (or allow) but not renegotiate on a case-by-case basis.
- nrc: long term i'd like style lints into rustfmt or rusttidy or some external tool, leaving only safety lints in the compiler. a lot of the allow-by-default lints are just style lints.
- steveklabnik: ~20 random issues for lints in tracker. no guidelines for which we want.
- nmatsakis: we're not committed here, we can change from deny to allow, this probably wants to be an rfc in the end ("lint policy")
- steveklabnik: been trying to remove the static_assert feature because it seems half baked and unused.
- nmatsakis: I remember when cmr added the feature gate, i wondered that it was still around.
- nrc: should publicize that this is happening. would be good to broadcast
- brson: the rfc process does call for rfcs for feature removal
- steveklabnik: it's weird. detailed design: remove static_assert. but i'm happy to do it
- nrc: more succinct rfcs would be a good thing!