Change:
This error occurred when running . Should I remove these unused attributes?
What's your ? These should only warn, not error.
This is a part of my which is not commented out.
If you run and check again, these warnings should go away. It would be nice if this wasn't necessary, though.
Thank you for your advice! 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.
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
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 mode for is sometimes hiding information about the commands it runs. To get something that actually reproduced the problem, I had to drop into the "more verbose" mode by passing twice to , like so: 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 that is present in the second.)
Also, setting this to may provide an easier workaround for this speciifc bug than a full clean:
(The aforementioned setting was moved into rustbuild in )
I am getting an increasing feeling that we need to document and simplify the bootstrapping process better...
My hope is that once PR gets into the beta-channel, then we should not see this particular problem arise. I would like to know if anyone is seeing other warnings that are not covered by the cases I handled in PR .
This is fixed now, right?
I haven't encountered it since
Same here. Seems to be working. Thanks
closing as fixed.
Fixed on my end as well, thank you all!
Seeing this one here: ie. I attempted some kind of whitelisting just as you did in PR , 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 too: (notice how the filename moved: is now ) Something extra: If I put in (which overrides the stage0 rust / / ) then it compiles ok the first time(as expected) then if I interrupt it and then attempt (re)compile, I get now:
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 to . Very annoying to have to . :(
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 directly on ways to resolve this. (And/or discuss removing lint with )
Should we just demote to warn-only at stage0? It's getting pretty boring to nuke every time I rebase and something has changed in libstd (looks even more frequent nowadays), and I've heard people say they don't set in because of these "unused attribute" errors, which is a shame. IMO should be the default for dev builds, although there's also the wasteful duplication between build artifacts and incremental dirs (for which I've just opened ).
Opened for the "temporary workaround".
Just FYI, landed, please leave a comment here if you still hit this issue. (it might move from libcore to other crates, not sure)

Discussion:
rustdocflags.arg("-Dwarnings"); } <del> // FIXME(#58633) hide "unused attribute" errors in incremental // builds of the standard library, as the underlying checks are // not yet properly integrated with incremental recompilation. if mode == Mode::Std && compiler.stage == 0 && self.config.incremental { lint_flags.push("-Aunused-attributes"); } </del> // This does not use RUSTFLAGS due to caching issues with Cargo. // Clippy is treated as an "in tree" tool, but shares the same // cache as other "submodule" tools. With these options set in