ICE: ./x.py doc --stage 1 panics
#75849
Comments
camelid
added
C-bug
jyn514
added
the
T-bootstrap
|
Build finally finished! Posted backtrace. |
|
The weird thing here is that there's no main function - the backtrace starts at |
jyn514
added
the
T-rustdoc
|
Actually, this is while compiling |
jyn514
removed
the
T-rustdoc
|
For reference, the |
@jyn514 This is normal, the compiler always runs inside a dedicated thread (even for a non-parallel rustc). Coincidentally I can reproduce this. I believe the issue is that the metadata format changes over time, but when rebuilding rustc, there isn't any versioning in place to check and avoid older versions. In this particular case, it is trying to load a proc macro (libtracing_attributes in my case), and then it tries to decode the metadata in the dylib. However, when the format changes, the serialization format that rustc uses isn't very resilient to errors, and tends to panic. Under normal circumstances, the version of rustc is embedded in the header, and the crate loader will skip files created by a different version of rustc. However, in a rustc dev environment, the version doesn't include the git hash or anything (it is just I think this is just par for the course when working with rustc. I would suggest just deleting the stage1-rustc directory (or running I don't think there is any feasible fix for this. There is a metadata version number that could be bumped manually, but I don't think these kinds of changes usually warrant that. The metadata schema could be versioned automatically, but that would require a lot of infrastructure to do (probably some proc-macro magic). Ideally the serialization code wouldn't panic and provide a better error, but I doubt that would be feasible to really fix (I don't really know, though). |
Is it possible to add the git hash to the version in a dev environment? That would be helpful for |
I think if you set the channel to |
|
There is a separate ignore-git flag in config.toml, which is enabled by default for dev at least. I'm going to close this - I agree with @ehuss' diagnosis. There's a fundamental trade-off between rustbuild being over eager to clean things out and people getting annoyed at "spurious" rebuilds. In this case at least I suspect there's nothing we can do to detect this case. |
Command
./x.py doc --stage 1Happens with PR #75842, but I don't think it's because of the PR, for one because the checks passed.
Meta
Commit hash: 4419e04
Error output
Full
x.pyoutputBacktrace
Cc @jyn514
The text was updated successfully, but these errors were encountered: