hey @eddyb and @simulacrum , I finally put up that PR that I promised, over on "Track devirtualized filename"s #72767
Its probably not the best long-term fix; at least, I know @eddyb was ... well, I don't know if "laughably unhappy" is the right term, but it did seem like they were both laughing and unhappy when they saw the problem
but anyway, even though it may not be the best long term fix, it is one that I would be okay backporting to beta
(which was to be done before, when @simulacrum ? before Monday?)
I think so, yeah
Well, we'll include it in the beta to stable promotion probably instead of separately landing it
If you tag it as accepted that'd be great
I'm guessing long term we should maybe just store the raw text of the files in metadata? I can't imagine it being a huge size increase or anything, especially if we run compression of some kind... Not entirely sure why we don't do that today.
well we still want paths too, no?
for local development
I guess it depends on what metadata you're talking about
I know I have been curious about storing raw text in our incremental build artifacts, but that is more because I would like to just spit out, as part of an incremental ICE: "here is the diff from the build we were using when we made the current set of artifacts"
Also, I don't have a regression test as part of the PR, because I'm not sure how to make one
my local replication relies on either adding/removing the
rust-src component in rustup , or actually renaming the
rustlib/src/rust subdirectory in my build directory. Either of these options don't seem to lend themselves to a test in our infrastructure, no?
(I will transcribe the last two comments to the github PR, because it seems like a generally useful comment. and maybe someone will have a bright idea about how to test this scenario.)
@simulacrum If I tag it as beta accepted, will you still wait for someone (hopefully @eddyb ) to r+ it before you put it into the beta-to-stable promotion?
(leave a comment please to that effect)
(I don't want to inadvertantly bypass the review process just because I'm willing to take the heat for a unilateral beta approval)
Okay I will do so
A run-make test could mess with the sysroot (or a copy of it) I guess, but it would probably be fairly error prone
Also quite slow I imagine, especially on Windows? Not sure.. generally I don't think we have a good story for incremental tests
I at least always struggle to read them quickly
I mean we do have a nice infrastructure with the revision system
depending on your point of view
it at least makes authoring certain cases easy
but i'll admit that may not be so great for people trying to understand them
Yes, I usually need to spend a bit of time refreshing myself on what is going on before I can interpret revision tests
Maybe that's unavoidable :)