You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: posts/2021-05-07-caught-red-handed.md
+77-44Lines changed: 77 additions & 44 deletions
Original file line number
Diff line number
Diff line change
@@ -6,9 +6,11 @@ team: the compiler team <https://www.rust-lang.org/governance/teams/compiler>
6
6
release: true
7
7
---
8
8
9
-
The Rust team has prepared a new release, 1.52.1, working around a bug
10
-
introduced in 1.52.0. We recommend all Rust users, including those currently
11
-
using stable versions prior to 1.52.0 upgrade to 1.52.1.
9
+
The Rust team has prepared a new release, 1.52.1, working around a bug in
10
+
incremental compilation which was made into a compiler error in 1.52.0. We
11
+
recommend all Rust users, including those currently using stable versions prior
12
+
to 1.52.0, upgrade to 1.52.1 or disable incremental compilation. Guidance on how
13
+
to do so is available below.
12
14
13
15
If you have a previous version of Rust installed via rustup, getting Rust
14
16
1.52.1 is as easy as:
@@ -22,44 +24,51 @@ from the appropriate page on our website.
22
24
23
25
[install]: https://www.rust-lang.org/install.html
24
26
25
-
# What's in 1.52.1 stable
26
-
27
-
This point release contains a single change: it disables incremental
28
-
compilation. Read on for more details as to why, and the next steps the Rust
29
-
project is pursuing on this issue.
30
-
31
27
# Summary
32
28
33
-
The Rust teams are always excited to report on new features offered with each release. Sometimes, however, an important change that is not yet "fully baked" gets accidentally included in a release, and we need to issue a point release.
34
-
35
-
There was an instance of this in the most recent release, 1.52.0, which added a new bit of internal-consistency checking, called "incremental compilation hash verification" (abbreviated `verify-ich`). This check is also called an "unstable fingerprint" check, because the diagnostic it currently prints look [like this](https://github.com/rust-lang/rust/issues/84336):
36
-
37
-
```
38
-
thread 'rustc' panicked at 'assertion failed: `(left == right)`
right: `Some(Fingerprint(14934403843752251060, 623484215826468126))`: found unstable fingerprints for <massive text describing rustc internals elided>
41
-
42
-
error: internal compiler error: unexpected panic
29
+
This release works around broken builds on 1.52.0, which are caused by newly
30
+
added verification. The bugs this verification detects are present in all Rust
31
+
versions, and can trigger miscompilations in incremental builds, so downgrading
32
+
to a prior stable version is not a fix.
43
33
44
-
note: the compiler unexpectedly panicked. this is a bug.
45
-
```
34
+
Users are encouraged to upgrade to 1.52.1 or disable incremental in their local
35
+
environment if on a prior versions: please see the [what you should do][part3]
36
+
section for details on how to do so.
46
37
47
-
This internal-consistency check, as stated in the diagnostic, yields an "Internal Compiler Error" (or ICE). In other words, it represents a bug in the internals of the Rust compiler itself. In *this* case, though, the ICE is revealing a bug that 1.) predates the 1.52.0 release and 2.) could result in miscompilation if it had not been caught by `verify-ich`.
48
-
49
-
In other words: If you are seeing the above Internal Compiler Error, you may be tempted to respond by reverting to the 1.51 release. It is important to note that a downgrade is *not* the best response to this problem.
38
+
Incremental compilation is off by default for release builds, so few
39
+
production builds should be affected (only users who may have opted in).
50
40
51
41
This post is going to:
52
42
43
+
1. Explain [what the errors look like][part0],
53
44
1. Explain [what the check does][part1], at a high level,
54
45
2. Explain [how the check is presenting itself][part2] in the Rust 1.52.0 release,
55
46
3. Tell you [what you should do][part3] if you see an unstable fingerprint on your project,
56
47
4. Describe our plans for [how the Rust project will address][part4] the problems discussed here.
right: `Some(Fingerprint(14934403843752251060, 623484215826468126))`: found unstable fingerprints for <massive text describing rustc internals elided>
64
+
65
+
error: internal compiler error: unexpected panic
66
+
67
+
note: the compiler unexpectedly panicked. this is a bug.
68
+
```
69
+
70
+
This is the error caused by the internal consistency check, and as stated in the diagnostic, it yields an "Internal Compiler Error" (or ICE). In other words, it represents a bug in the internals of the Rust compiler itself. In *this* case, the ICE is revealing a bug that predates the 1.52.0 release and could result in miscompilation if it had not been caught by `verify-ich`.
71
+
63
72
## What are fingerprints? Why are we checking them?
64
73
65
74
The Rust compiler has support for "incremental compilation", which has been described in a [2016 blog post][]. When incremental compilation is turned on, the compiler breaks the input source into pieces, and tracks how those input pieces influence the final build product. Then, when the inputs change, it detects this and reuses artifacts from previous builds, striving to expend effort solely on building the parts that need to respond to the changes to the input source code.
@@ -70,14 +79,18 @@ Fingerprints are part of our architecture for detecting when inputs change. More
The `verify-ich` check is a safeguard asserting internal inconsistency of the fingerprints.
74
-
The compiler stores fingerprints for both cached and uncached values.
75
-
Every time we compute an uncached value, we double-check that its newly computed fingerprint against the finger print stored in the cache.
76
-
There are multiple ways that a fingerprint mismatch could arise, but they all represent bugs within the Rust compiler itself.
82
+
The `verify-ich` check is a safeguard asserting internal consistency of the
83
+
fingerprints. Sometimes the compiler is forced to rerun a query, and expects
84
+
that the output is the same as from a prior incremental compilation session. The
85
+
newly enabled verification checks that the value is indeed as expected, rather
86
+
than assuming so. In some cases, due to bugs in the compiler's implementation,
87
+
this was not actually the case.
77
88
78
-
## History of deployment
89
+
## History
79
90
80
-
We [initially added][pr-45867]`verify-ich` as a tool to use when developing rustc itself, back in 2017; it was solely provided via an unstable `-Z` flag, only available to nightly and development builds.
91
+
We [initially added][pr-45867]`verify-ich` as a tool to use when developing
92
+
rustc itself, back in 2017. It was solely provided via an unstable `-Z` flag,
93
+
only available to nightly and development builds.
81
94
82
95
More recently, in March, we encountered a [miscompilation][issue-82920] that led us to [turn on `verify-ich` by default][pr-83007]. The Rust compiler team decided it was better to catch fingerprint problems and abort compilation, rather than allow for potential miscompilations (and subsequent misbehavior) to sneak into Rust programmer's binaries.
83
96
@@ -87,11 +100,13 @@ More recently, in March, we encountered a [miscompilation][issue-82920] that led
87
100
88
101
When we first turned on `verify-ich` by default, there was a steady stream of
89
102
issues filed by users of the nightly (and beta) toolchains, and steady progress
90
-
has been made on identifying fixes, a number of which have already landed. This
91
-
last week, we noted incorrectly that the error would be shipping to stable
92
-
next cycle in 1.53.0, and we started [making plans][issue-84970] to improve the
103
+
has been made on identifying fixes, a number of which have already landed.
104
+
105
+
In the past week, we had started [making plans][issue-84970] to improve the
93
106
user-experience, so that the diagnostic issued by the check would do a better
94
-
job of telling the programmer what to do in response.
107
+
job of telling the programmer what to do in response. Unfortunately, this was
108
+
done under the assumption that the new verification would ship in 1.53, not
@@ -110,20 +125,27 @@ Essentially, for some crates, certain sequences of edit-compile cycles will caus
110
125
Another recent example looks [like this](https://github.com/rust-lang/rust/issues/85039):
111
126
112
127
```
113
-
thread 'rustc' panicked at 'found unstable fingerprints for predicates_of(<massive text describing rustc internals elided>)', /rustc/88f19c6dab716c6281af7602e30f413e809c5974/compiler/rustc_query_system/src/query/plumbing.rs:593:5
128
+
thread 'rustc' panicked at 'found unstable fingerprints for predicates_of(<massive text describing rustc internals elided>)', /rustc/.../compiler/rustc_query_system/src/query/plumbing.rs:593:5
114
129
```
115
130
116
131
They all arise from inconsistencies when comparing the incremental-compilation cache stored on disk against the values computed during a current `rustc` invocation, which means they all arise from using incremental compilation.
117
132
118
-
There are three ways that you may have incremental compilation turned on: You may have set the [environment variable][env-vars]`CARGO_INCREMENTAL=1`, or you may have enabled the `build.incremental`[setting in your Cargo.toml][cargo-toml], or you may be building with the `dev` or `test`[profiles][], which default to having incremental compilation enabled.
133
+
There are several ways that you may have incremental compilation turned on:
134
+
135
+
1. You may be building with the `dev` or `test`[profiles][] which default to having incremental compilation enabled.
136
+
2. You may have set the [environment variable][env-vars]`CARGO_INCREMENTAL=1`
137
+
3. You may have enabled the `build.incremental`[setting in your Cargo config][cargo-config]
138
+
4. You may have enabled the `incremental`[setting in your Cargo.toml][cargo-toml] for a given profile
0 commit comments