Stream: t-compiler/help

Topic: quick testing


Camelid (May 31 2020 at 18:08, on Zulip):

Hi, I've just started working on fixing a rustc bug, but I'm not sure how I will test if my change worked. Do I have to build the entire stage1 compiler or is there a faster way to do it?

LeSeulArtichaut (May 31 2020 at 18:11, on Zulip):

@Camelid You have some suggested workflows in the rustc-dev-guide

LeSeulArtichaut (May 31 2020 at 18:12, on Zulip):

So if you run ./x.py build -i --stage 1 src/libstd, it will build the compiler from source once

Camelid (May 31 2020 at 18:13, on Zulip):

Okay, thanks! By the way, how long does it take the first time? I'm guessing a while

LeSeulArtichaut (May 31 2020 at 18:14, on Zulip):

Well that depends on your machine I think?

LeSeulArtichaut (May 31 2020 at 18:14, on Zulip):

First time you'll have to compile LLVM as well

Camelid (May 31 2020 at 18:15, on Zulip):

Okay, thanks for your help! One more thing: the same page says:

You can also use --keep-stage 1 when running tests. Something like this:

LeSeulArtichaut (May 31 2020 at 18:16, on Zulip):

That's for running the test suite for the compiler

Camelid (May 31 2020 at 18:16, on Zulip):

If I run the test without --keep-stage, does that throw away part of my compiler?

LeSeulArtichaut (May 31 2020 at 18:17, on Zulip):

I think --keep-stage will keep the stage0 std, which you have to build a first time

LeSeulArtichaut (May 31 2020 at 18:17, on Zulip):

But I might be very wrong :rolling_eyes:

Camelid (May 31 2020 at 18:17, on Zulip):

I see, so --keep-stage is preventing the test suite from recompiling std?

LeSeulArtichaut (May 31 2020 at 18:19, on Zulip):

I think so

LeSeulArtichaut (May 31 2020 at 18:19, on Zulip):

It's going to throw you a warning like "using a potentially outdated libstd"

LeSeulArtichaut (May 31 2020 at 18:20, on Zulip):

But if you're not working on the standard library then it doesn't matter

LeSeulArtichaut (May 31 2020 at 18:20, on Zulip):

Again, the rustc dev guide has some documentation for building the compiler

LeSeulArtichaut (May 31 2020 at 18:21, on Zulip):

Like for example Creating a rustup toolchain which in my experience was a game changer, being able to invoke my own build of rustc through rustc +stage1 is really useful

marmeladema (May 31 2020 at 19:24, on Zulip):

I would advise not to build llvm and instead create a config.toml file and the path to your local llvm-config

LeSeulArtichaut (May 31 2020 at 19:59, on Zulip):

Note that you need to have the LLVM FileCheck tool installed, which is used for codegen tests.

lcnr (May 31 2020 at 20:44, on Zulip):

I would advise not to build llvm and instead create a config.toml file and the path to your local llvm-config

I really should have done that earlier :laughter_tears: Up to now I had 6 identical LLVM builds

mark-i-m (Jun 01 2020 at 02:08, on Zulip):

Yeah, building llvm wastes like 45m on my laptop. @Camelid not sure if you've already built, but it can take a while. I would recommend turning on incremental (in config.toml) and only building stage 1 (unless your change needs stage 2 for some reason, but most people don't need it)

mark-i-m (Jun 01 2020 at 02:08, on Zulip):

Also, if you're just checking if your changes compile you can use ./x.py check which takes a couple of minutes is the cargo check of the compiler...

Camelid (Jun 01 2020 at 02:47, on Zulip):

I did already build; building LLVM actually didn't seem to take too long, maybe because I'm on a desktop. Does LLVM have to rebuilt often?

Camelid (Jun 01 2020 at 02:49, on Zulip):

Thanks for the tip! I'd been running ./x.py with -i but I turned on incremental so I don't forget. I'm wondering why it's not on by default?

Tshepang Lekhonkhobe (Jun 01 2020 at 03:25, on Zulip):

Camelid said:

I did already build; building LLVM actually didn't seem to take too long, maybe because I'm on a desktop. Does LLVM have to rebuilt often?

it happens rarely (i.e. when llvm parts changed)

mark-i-m (Jun 01 2020 at 20:34, on Zulip):

Camelid said:

Thanks for the tip! I'd been running ./x.py with -i but I turned on incremental so I don't forget. I'm wondering why it's not on by default?

It's a bit buggy to reuse objects when bootstrapping because the ABI may change and there is weirdness with recompiling the std libs, so technically doing so is unsound (I think). But in practice it usually works fine.

mark-i-m (Jun 01 2020 at 20:35, on Zulip):

More generally, ./x.py seems to be more optimized for producing distributions than for development, which will hopefully change a bit in the future...

Camelid (Jun 01 2020 at 20:35, on Zulip):

Yeah, the commands to run it are pretty long :)

LeSeulArtichaut (Jun 01 2020 at 20:41, on Zulip):

I've set up shell aliases for basic commands like

alias rb='./x.py build -i --stage 1 src/libstd'
alias rt='./x.py test -i --stage 1'

So that I can invoke them much more quickly. And I also never forget the -i this way :D

Camelid (Jun 01 2020 at 20:50, on Zulip):

Ah, good idea! Although what about --keep-stage 1? That part confuses me: what's the different between between -i and --keep-stage 1?

LeSeulArtichaut (Jun 01 2020 at 20:52, on Zulip):

IIRC, -i means "use incremental compilation", and --keep-stage means "don't recompile things and just keep what you can keep of the previous stage's artifacts"

Camelid (Jun 01 2020 at 20:58, on Zulip):

Is that like what mark-i-m said, where -i is sound, but --keep-stage is technically unsound because of ABI etc.?

Camelid (Jun 01 2020 at 20:59, on Zulip):

I just added your aliases, except I added --keep-stage 1 so that I don't forget and have to wait forever :)

mark-i-m (Jun 02 2020 at 03:09, on Zulip):

I might be mistaken, but I believe it is --keep-stage 0 (yeah, the numbering is very weird)

mark-i-m (Jun 02 2020 at 03:10, on Zulip):

IIUC, both are unsound but work in practice. -i is the same as setting incremental = true in the config.toml

Last update: Sep 28 2020 at 15:45UTC