Stream: t-compiler/wg-mir-opt

Topic: keep stage


simulacrum (Apr 17 2020 at 01:16, on Zulip):

Yeah, we can. There's someone working on getting regular cargo builds working (vs x.py)

simulacrum (Apr 17 2020 at 01:16, on Zulip):

I should check on that

eddyb (Apr 17 2020 at 01:17, on Zulip):

right, I saw that, hope it all works out

Santiago Pastorino (Apr 17 2020 at 01:24, on Zulip):
// Check that while a trait with by-value self is object-safe, we
// can't actually invoke it from an object (yet...?).

#![feature(rustc_attrs)]

trait Bar {
    fn bar(self);
}

trait Baz {
    fn baz(self: Self);
}

fn use_bar(t: Box<dyn Bar>) {
    t.bar() //~ ERROR cannot move a value of type dyn Bar
}

fn main() { }
Santiago Pastorino (Apr 17 2020 at 01:25, on Zulip):

this now compiles

Santiago Pastorino (Apr 17 2020 at 01:25, on Zulip):

@eddyb :point_up:

eddyb (Apr 17 2020 at 01:28, on Zulip):

maybe you need to check for the unsized_locals feature-gate?

eddyb (Apr 17 2020 at 01:29, on Zulip):

in your special-casing

Santiago Pastorino (Apr 17 2020 at 01:34, on Zulip):

I meant, this is an existing test that was supposed to fail

Santiago Pastorino (Apr 17 2020 at 01:34, on Zulip):

but now compiles

Santiago Pastorino (Apr 17 2020 at 01:34, on Zulip):

unsure what you meant

eddyb (Apr 17 2020 at 01:35, on Zulip):

@Santiago Pastorino your code needs to only go into effect if #![feature(unsized_locals)] was specified

Santiago Pastorino (Apr 17 2020 at 01:35, on Zulip):

ahhh

eddyb (Apr 17 2020 at 01:35, on Zulip):

otherwise you're removing an unsized move that would've prevented the code compiling w/o feature-gates

eddyb (Apr 17 2020 at 01:35, on Zulip):

with no opt-in

eddyb (Apr 17 2020 at 01:36, on Zulip):

(we probably want a separate feature-gate for but testing you can use unsized_locals)

Santiago Pastorino (Apr 17 2020 at 01:36, on Zulip):

:+1:

Santiago Pastorino (Apr 17 2020 at 01:36, on Zulip):

will fix tomorrow

eddyb (Apr 17 2020 at 01:36, on Zulip):

@Santiago Pastorino @nikomatsakis would be really nice if we don't have to change typeck and it looks like we won't :D

eddyb (Apr 17 2020 at 01:37, on Zulip):

(basically we want all of core/alloc/std to compile w/o #![feature(unsized_locals)] and at most a new feature-gate)

eddyb (Apr 17 2020 at 01:37, on Zulip):

(to make sure we're not miscompiling anyone's dynamic alignments)

eddyb (Apr 17 2020 at 01:37, on Zulip):

(via public stdlib APIs, and even worse, stable ones)

RalfJ (Apr 17 2020 at 16:36, on Zulip):

keep-stage is still absolutely essential when working on miri with rustc changes

RalfJ (Apr 17 2020 at 16:36, on Zulip):

I can do --keep-stage 0 and then it only rebuilds stage 1, so when I change librsutc_mir just a few crates, before I can build miri against the new stage 2 toolchain

RalfJ (Apr 17 2020 at 16:37, on Zulip):

but yeah libstd only takes a minute here as well so I hardly ever use keep-stage to just skip libstd

RalfJ (Apr 17 2020 at 16:37, on Zulip):

but until https://github.com/rust-lang/rust/issues/52856 is resolved please keep keep-stage :D

eddyb (Apr 17 2020 at 16:38, on Zulip):

probably blocked on subtree-ing miri :P

eddyb (Apr 17 2020 at 16:38, on Zulip):

or maybe not

eddyb (Apr 17 2020 at 16:39, on Zulip):

or do you mean you want to build miri out of tree?

eddyb (Apr 17 2020 at 16:40, on Zulip):

rustdoc for example works fine being built at stage0 into stage1/bin/rustdoc and running rustdoc tests at stage1

eddyb (Apr 17 2020 at 16:40, on Zulip):

i.e. ./x.py test --stage 1 src/test/rustdoc{,-ui} builds the compiler once, builds rustdoc and runs the tests

eddyb (Apr 17 2020 at 16:41, on Zulip):

theoretically we can do the same for miri

eddyb (Apr 17 2020 at 16:41, on Zulip):

the last comment in the issue mentions proc macros, which have since been fixed I guess

eddyb (Apr 17 2020 at 16:41, on Zulip):

@simulacrum likely understands the situation better than me though

simulacrum (Apr 17 2020 at 16:42, on Zulip):

Yeah you shouldn't need a stage 2 toolchain for miri I think, though we may not quite be setup right for that

simulacrum (Apr 17 2020 at 16:43, on Zulip):

Probably fixable though

eddyb (Apr 17 2020 at 16:43, on Zulip):

out of tree will sadly always be harder because the stage0 toolchain isn't exposed to allow building e.g. build scripts

eddyb (Apr 17 2020 at 16:43, on Zulip):

wait no that should be fine. even proc macros maybe

eddyb (Apr 17 2020 at 16:43, on Zulip):

/me forgets what the edge case is

eddyb (Apr 17 2020 at 16:44, on Zulip):

oh miri itself would have to be built by the stage0 toolchain to link against the same rustc_driver that stage1/bin/rustc uses

RalfJ (Apr 19 2020 at 08:13, on Zulip):

yeah I was thinking out-of-tree

RalfJ (Apr 19 2020 at 08:13, on Zulip):

I could move my work in-tree though for these cases I guess. (with subtree miri switching between out-of and in-tree might be harder but I'm sure there'll be ways.)

RalfJ (Apr 19 2020 at 08:15, on Zulip):

so are you saying ./x.py --stage 1 test src/tools/miri should work these days, or could be made to work with minor adjustments to rustbuild? well that would be cool :D

Last update: Sep 28 2020 at 16:30UTC