x.py commands stopped working when CWD is not the rust.git root directory

[pnkfelix]

Until somewhat recently I was able to do (for example):

% git clone git@github.com:rust-lang/rust.git
Cloning into 'rust'...
Enter passphrase for key '/Users/fklock/.ssh/id_rsa-Mozilla': 
remote: Counting objects: 750528, done.        
remote: Total 750528 (delta 0), reused 1 (delta 0), pack-reused 750527        
Receiving objects: 100% (750528/750528), 338.52 MiB | 4.64 MiB/s, done.
Resolving deltas: 100% (605180/605180), done.
Checking out files: 100% (12010/12010), done.
% cd rust
% mkdir objdir
% cd objdir/
% ../x.py test src/tools/tidy
...

and, after some amount of time downloading bootstrap stuff and compiling tidy (sigh), it would run that command, checking that the source from the checked out directory was indeed tidy.

Likewise, I could use x.py build to do a build (where it would use the config.toml in my CWD as the basis for the build, which would be emitted into $(pwd)/build/).

Today, however, after a git pull from master bringing myself up to 5570cdc, I can no longer use the above workflow.

All of my attempts to run x.py from a directory other than the root of the checkout have been met with, for example:

% time python ../x.py test src/tools/tidy
Updating submodules
    Finished dev [unoptimized] target(s) in 0.0 secs
Warning: no rules matched objdir-opt/src/tools/tidy.
Build completed successfully in 0:00:03

real	0m3.829s
user	0m2.087s
sys	0m1.334s
%

This is bad in two ways:

1. A command that used to work is now failing.
2. A command that used to work is now failing and returning 0 as its exit status, so that when I have a local script for driving my builds that works by chaining calls (so e.g. I can run tidy before I start my build), the implicit failure of the first x.py call only causes a warning to be emitted, while the rest of the command sequence is subsequently run.

For me, point 2 is not so so bad, since the command sequence in question is just more calls to x.py from that same non-root directory, so they all emit the warning and so I'm likely to notice at least one of them.

But for other clients, I can imagine point 2 being quite disasterous.

[pnkfelix]

(bisecting. Initial report: this worked, at least for running tidy, as of commit 56733bc ; now just bisecting to find the injection merge from bors...)

[pnkfelix]

Bisection indicates that 90759be while c83fa5d is broken.

Based on my reading of git log --graph 90759befe0234b20ecf81edbbff353b85419d7e9^..c83fa5d91c3b16459ab7b87c48ed18bd059a23af, I think that implies that #48105 is to blame for this.

[pnkfelix]

Apparently we were about to revert PR #48105 (see PR #48242) because it has other breakage it injected (that may or may not be unrelated to the bug I have filed here), but then the reversion PR was closed ... 😢

[jyn514]

@pnkfelix your ../x.py command works for me on master. Are you still running into this issue?

[jyn514]

@pnkfelix I'm going to close this because it works for me and I think I remember you saying you use this command pretty often today - feel free to reopen if you're still having trouble.