./x.py check failed if incremental builds enabled
#58633
Comments
|
What's your |
|
This is a part of my config.toml which is not commented out. |
|
If you run |
|
@varkor Thank you for your advice! ./x.py clean and then build completed successfully! |
|
This happens to me every time I try to do an incremental build after making a change. Is there any other way to resolve this than |
|
Let's keep this issue open, because we'd rather not have to clean even single time. |
estebank
added
A-incr-comp
|
I'm running into the same problem with incremental builds, which makes incremental kind of useless... |
|
I think I am also running into this. I'm going to tag this T-compiler to try to increase visibility |
pnkfelix
added
the
T-compiler
pnkfelix
changed the title
./x.py check failed./x.py check failed if incremental enabled
pnkfelix
changed the title
./x.py check failed if incremental enabled./x.py check failed if incremental builds enabled
|
I am also running into this |
|
This is super painful, can this gets prioritized, or could we disable incremental builds until its fixed? |
|
FYI, the following command seems like a pretty reliable way to reproduce this problem: |
|
(assigning to self to investigate) |
|
Strange; part of the problem I have had in investigating this is that it seemed like my manual attempts to run the "same" commands that were being issued by bootstrap would all complete successfully. I think part of the issue there is that the and an interesting part about that output is that I saw these two lines right next to each other in the output: The first command listed won't reproduce the problem. The second will. (I suspect its because the first is lacking that |
|
Also, setting this to Lines 402 to 403 in 003382e |
|
(The aforementioned setting was moved into rustbuild in #49715) |
|
I am getting an increasing feeling that we need to document and simplify the bootstrapping process better... |
…, r=petrochenkov Whitelist some rustc attrs These rustc attrs are used within libcore, and were causing failures when one mixed incremental compilation with bootstrapping (due to a default of `-D warnings` when bootstrapping). Fix rust-lang#59523 Fix rust-lang#59524 Cc rust-lang#58633
|
Fixed on my end as well, thank you all! |
Seeing this one here: #64764 (comment) I attempted some kind of whitelisting just as you did in PR #59525, but I'm thinking it will only work if I attempt recompilation with a rustc that has that whitelisted already?(which would explain why it keeps failing as if whitelisting it had no effect, ok definitely placing garbage instead of the below patch(which should compile fail) does have no effect which says that it doesn't get compiled before the above fail) Either way, I'm not sure where to Whitelist it, since it appears as diff --git a/src/libsyntax/feature_gate/builtin_attrs.rs b/src/libsyntax/feature_gate/builtin_attrs.rs
index d14afc6deaa..2d92c4df399 100644
--- a/src/libsyntax/feature_gate/builtin_attrs.rs
+++ b/src/libsyntax/feature_gate/builtin_attrs.rs
@@ -331,7 +331,7 @@ pub const BUILTIN_ATTRIBUTES: &[BuiltinAttribute] = &[
"the `#[rustc_const_unstable]` attribute is an internal feature",
),
gated!(
- allow_internal_unstable, Normal, template!(Word, List: "feat1, feat2, ..."),
+ allow_internal_unstable, Whitelisted, template!(Word, List: "feat1, feat2, ..."),
EXPLAIN_ALLOW_INTERNAL_UNSTABLE,
),
gated!(allow_internal_unsafe, Normal, template!(Word), EXPLAIN_ALLOW_INTERNAL_UNSAFE),
@@ -438,6 +438,11 @@ pub const BUILTIN_ATTRIBUTES: &[BuiltinAttribute] = &[
// Internal attributes, Layout related:
// ==========================================================================
+// rustc_attr!(
+// allow_internal_unstable, Whitelisted, template!(Word, List: "feat1, feat2, ..."),
+// EXPLAIN_ALLOW_INTERNAL_UNSTABLE,
+// ),
+
rustc_attr!(
rustc_layout_scalar_valid_range_start, Whitelisted, template!(List: "value"),
"the `#[rustc_layout_scalar_valid_range_start]` attribute is just used to enable \(notice how the filename moved: Something extra: |
ghost
mentioned this issue
|
This keeps happening to me with this: |
|
I'm reopening and nominating for compiler team since it seems like it may be worth discussing to see if there's some principled solution for bugs like this. I think we've seen the last 2-3 releases all introduce at least one case of unused attribute errors in libcore/libstd during incremental, which is not great. Maybe there's some way we can stop tracking the rustc-perma-unstable attributes as 'green' in incremental? That may be too big a hammer though (or maybe too small). At least, it seems worth bringing this up at pre-triage. |
|
This keeps happening to me when switching from |
use `#[allow(unused_attributes)]` to paper over incr.comp problem Paper over the problem in rust-lang#58633. r? @Mark-Simulacrum
|
triage: P-high, leaving nominated in hopes of discussion in a near term meeting. |
|
There is a way of dealing with side-effects in the incremental system. We use such a solution for diagnostics. It could probably be expanded to unused-attributes if there is no cleaner approach. |
|
removing nomination label; I'll follow-up with @michaelwoerister directly on ways to resolve this. (And/or discuss removing |
jonas-schievink
added
A-attributes
|
Should we just demote It's getting pretty boring to nuke IMO |
|
Opened #70881 for the "temporary workaround". |
…d-attrs, r=Mark-Simulacrum bootstrap: work around "unused attribute" errors in incremental stdlib rebuilds. This should alleviate rust-lang#58633 separately from a proper fix. r? @Mark-Simulacrum
|
Just FYI, #70881 landed, please leave a comment here if you still hit this issue. |
…ark-Simulacrum Remove hack ignoring unused attributes for stage 0 std This seems to no longer be giving spurious errors when incremental is enabled. Closes rust-lang#58633.
This error occurred when running
./x.py check.Should I remove these unused attributes?
The text was updated successfully, but these errors were encountered: