jiebi/CodeConvo huggingface dataset:
Code change:
<del> Subproject commit 50ab09fb43f038e4f824eea6cb278f560d3e8621 </del> <ins> Subproject commit 859fb269364623b17e092efaba3f94e70ce97c5e </ins>

Related discussion:
text: I'm okay with any of the three options (flag in , feature for , only setting it for those two platforms) for these platforms.
No. No. Namely the x64 windows ABI is kinda fuzzy about how i128 values are handled so carefully reading it we arrived at a conclusion that they ought to be handled the same way as regular 16-byte structs on 64 bit window platforms. A target cannot not support i128 at a fundamental level the same way a target cannot not support writing turing complete software. IMO what we should do here is to fudge the ABIs somewhat to take and return arguments via pointers (or the same way would be handled) on these targets. C ABI will be more complex; as already said there will always be at least one user of the C ABI with i128 arguments and stuff – LLVM with their intrinsics. The question here is how does LLVM lower to the intrinsics on these targets. If the backend does not lower and asserts for whatever reason, the targets have what’s essentially a broken backend implementation. Which seems to be broken for at least NVPTX () in exactly the place where I’d expect it to be broken if it was broken: That being said, since the C compilers do not support i128 for those targets, the actual interoperation does not matter whatsoever. All that’s really needs to be fixed is LLVM’s lowering of instructions to intrinsics using whatever ABI that works, even if its passing in arguments and taking return value via pointers. I, myself, am very strongly against splitting the language feature sets depending on the target.
How do we break the stalemate? If we submitted changes upstream for each of the smaller targets w/o support for i128 (providing indirection like large structs) it seems like it would meet resistance. As says, it's likely not considered useful since there's many targets without any native registers or support for such large values. But we also also have reluctance to limit this type to only appropriate targets. Does the "vision for 2017 cycle" provide any guidance? Does "provide a more seamless FFI story" help push us in one direction or the other?
regardless whether useful or not, we do need to support i128 on all targets, otherwise people will start using libraries that provide it across platforms.
Code change:
<del> Subproject commit 50ab09fb43f038e4f824eea6cb278f560d3e8621 </del> <ins> Subproject commit 859fb269364623b17e092efaba3f94e70ce97c5e </ins>

Related discussion:
text: Even if it needs to be "virtualized" in some way, and not wholly put into registers. In the worst case we'd have to provide some translation before passing things to LLVM, but it will affect things like alignment and generally looks like an ugly workaround. About FFI, I guess we can't really provide any FFI for i128 on targets where there is no C support for it, as generally the calling conventions only specify things that are part of C.
None of the targets Rust supports have native support for 128-bit integers, other than the fact that some can implement unchecked division and multiplication involving 128-bit integer operand with a single insn. Why? All that needs to be done here is to have the backends fixed. LLVM is supposed to be agnostic over bitwidth of integer, however useful or not somebody on the internet perceives such functionality to be. In other words, its a backend bug. So, its probably pretty clear that all it takes is to write a patch to fix bugs in these backends wrt operations on large values. I have no knowledge of these targets, am not familiar with the backends and haven’t the hardware to test any fixes on, so these patches will have to be written by somebody else. Late answer, but I’ve noticed this only now. This observation is wrong in multiple places. Firstly, (a.k.a. returning via pointer) is not a hack. Neither is it an exception. That’s what pretty much every single ABI¹ out there does for values that do not fit into register(s). It is most likely true that MSP430 ABI does not specify what to do with PODs this large, so it falls on us to pick whatever. ¹: For a less obscure example, x64 ABI used by code targetting Windows mandates to be used for any non-vector values over 64 bit in size, even though they could be fit it into registers. SysV ABI starts returning stuff via after some size threshold as well.
The MSP430 ABI specifies that aggregates larger than 32 bits are passed and returned via pointer. The backend just doesn't implement sret correctly yet (and in fact is implemented targeting an old and outdated ABI in any case). I'm working on fixing this in LLVM.
Code change:
<del> Subproject commit 50ab09fb43f038e4f824eea6cb278f560d3e8621 </del> <ins> Subproject commit 859fb269364623b17e092efaba3f94e70ce97c5e </ins>

Related discussion:
text: I'd bet that similar problems explain the NVPTX problems but I know nothing about that platform so I can't say that for sure.
I also agree that fixing backend is the right thing to do. I just think that it is not that easy as you say it is. MSP430 is the only 16bit architecture in LLVM, and this creates some trouble by itself. Good to know that someone is working on this.
does that LLVM patch really fix NVPTX as well?
No, it doesn't. this should be reopened for NVPTX.
BTW, thanks to for fixing this in LLVM upstream.
Triage: MSP430 has been fixed. No change in the NVPTX backend.
What needs to be done to get NVPTX working again?
You can see the patch I did for the MSP430 above - if it's the same problem you basically just have to add sret (structure return) support to the LLVM backend. I don't know anything about NVPTX but I'd bet it's pretty much the same procedure as what I did for the MSP.
Note that you can use the NVPTX backend today with the nightly compiler if you use a fork of the libcore crate that doesn't include 128 bit integers. Instructions .
I have some progress on the issue. First, I tried a hacky workaround with replacing with in arguments and return values with a custom FunctionPass. Can be transformed to: And compiled to PTX with vanilla LLVM (): Then, I made less hacky workaround patching LLVM NVPTX backend so it became possible to compile the code with without additional passes. Is compiled with patched to pretty much valid and working PTX assembly ;) But another related problems appears. When instead of: I write: I receive an error: And similar error when I try to compile : Does anybody have any suggestions about the problems? Looks like PTX doesn't have an instructions for the functions, and LLVM can't expand them.
Looks like the expansion from i128 to i64 is going OK but the i64 sdiv/mulo instructions aren't properly implemented. Not sure why that might be... it kind of looks like it's trying to assign the address of a library call and that's not working. Possibly the way you implemented the i128 expansion prevented a subsequent i64 expansion from running but I can't tell without seeing the code.
Code change:
<del> Subproject commit 50ab09fb43f038e4f824eea6cb278f560d3e8621 </del> <ins> Subproject commit 859fb269364623b17e092efaba3f94e70ce97c5e </ins>

Related discussion:
text: Run llc with -print-before-all and/or -print-machineinstrs to see where things diverge from what you expect. Look up in your platform ABI what the right action to take for 64-bit divides actually is. Post a link to your changes and someone may be able to take a look at them and see the problem.
Traditionally, in LLVM, is implemented by the library. However, its disabled on most platforms. Not sure why, but is written in C so they probably only can support i128 on platforms where they also provide C support, and clang's C support for i128 is right now very limited. Rust however the function, inside the crate (that is a wrapper for compiler-rt). There are good chances it works already!
It has pretty expected output before and after each pass. I think more interesting would be output with , but I don't really understand it. of the next commands: I tried to make changes over LLVM as minimal as possible: . I'm quite confused about and . Should they be compiled for target or host? If we can build at least for NVPTX, then can we just link against it? It still require some more changes for LLVM to be able to threat libcalls as normal calls. But then, all we would need is to link against . This blocked by but might be solved with my experimental .
For the target. At least its that way on other platforms. What is LLVM doing on 32 bit NVPTX when it encounters a 64 bit operation? On normal targets, this is one of the places compiler-rt gets used. Or idk, to cast a float to an int and back.
by the way, I didn't congratulate you yet for your progress. Really great work, loving it!
I'd like to see this move forward, so I'll summarize the above. Please correct me if I'm wrong: This issue was fixed for the MSP430 backend by submitting a patch to LLVM. worked on a patch to do the same for NVPTX, but it was not submitted to LLVM. I imagine that since that was a year ago, the patch will need some work to bring it up to date. Is this problem still happening with more recent builds? Perhaps it's been fixed by upstream in the meantime.
Code change:
<del> Subproject commit 50ab09fb43f038e4f824eea6cb278f560d3e8621 </del> <ins> Subproject commit 859fb269364623b17e092efaba3f94e70ce97c5e </ins>

Related discussion:
text: If it is still a problem, what would have to be done to fix it?
Well, my patch related to landed in LLVM about year ago. Now we can compile simple examples without any problems: with which produces the PTX assembly: And as for me, the issue can be closed. I was able to compile a kernel from  with latest nightly. So the hack with custom is obsolete now.
Code change:
use rustc::mir::{Mir, Place}; use rustc::mir::{Projection, ProjectionElem}; use rustc::ty::{self, TyCtxt}; <ins> use std::cmp::max; </ins> pub(super) fn places_conflict<'gcx, 'tcx>( tcx: TyCtxt<'_, 'gcx, 'tcx>,

Related discussion:
text: Minimal example: This will complain about multiple mutable borrows, even though it should be valid.
Noted in (but may deserve a separate bug report?). (FYI, slice patterns are unstable for a reason; they're pretty buggy at the moment).
should be closed after MIR borrowck will be by default
Code change:
rustup toolchain install --profile minimal nightly-${TOOLCHAIN} # Sanity check to see if the nightly exists echo nightly-${TOOLCHAIN} > rust-toolchain <del> echo "=> Uninstalling all old nighlies" </del> <ins> echo "=> Uninstalling all old nightlies" </ins> for nightly in $(rustup toolchain list | grep nightly | grep -v $TOOLCHAIN | grep -v nightly-x86_64); do rustup toolchain uninstall $nightly done

Related discussion:
text: We currently emit vec growth glue, but it is called using the push/pop mechanism (e.g. of transcallglue). In reality, the only call site for this glue is generated when translating vec append statements, so it really is user-level glue and need not adhere to the "worst-case glue-call args" max argument count. The fact that we don't do this costs us one extra word of worst-case glue-call args at the moment (7 words instead of the 6 we'd need otherwise). This is a relatively minor issue, but now noted.
WONTFIX (not required for bootstrapping)
Code change:
rustup toolchain install --profile minimal nightly-${TOOLCHAIN} # Sanity check to see if the nightly exists echo nightly-${TOOLCHAIN} > rust-toolchain <del> echo "=> Uninstalling all old nighlies" </del> <ins> echo "=> Uninstalling all old nightlies" </ins> for nightly in $(rustup toolchain list | grep nightly | grep -v $TOOLCHAIN | grep -v nightly-x86_64); do rustup toolchain uninstall $nightly done

Related discussion:
text: Currently, pointers stored on the stack aren't word-aligned. This is a critical issue because it causes stack growth to fail most of the time.
Commit disables task growth for now until this is fixed.
WONTFIX (moot point given disabled stack growth)
Code change:
rustup toolchain install --profile minimal nightly-${TOOLCHAIN} # Sanity check to see if the nightly exists echo nightly-${TOOLCHAIN} > rust-toolchain <del> echo "=> Uninstalling all old nighlies" </del> <ins> echo "=> Uninstalling all old nightlies" </ins> for nightly in $(rustup toolchain list | grep nightly | grep -v $TOOLCHAIN | grep -v nightly-x86_64); do rustup toolchain uninstall $nightly done

Related discussion:
text: u32(1234) should be 1234u32, and handled in the lexer The former is chatty and confuses the issue with runtime calls / casts (the latter of which should be shifted to 'as' casts anyway).
Switch machine-type lexemes to use suffixes. Remove support for foo(bar) as a cast notation. Closed by .
Code change:
<ins> warning: trait-associated function `from_iter` will become ambiguous in Rust 2021 --> $DIR/future-prelude-collision-generic.rs:28:5 | LL |     Generic::from_iter(1); |     ^^^^^^^^^^^^^^^^^^ help: disambiguate the associated function: `<Generic<_, _> as MyFromIter>::from_iter` | note: the lint level is defined here --> $DIR/future-prelude-collision-generic.rs:5:9 | LL | #![warn(rust_2021_prelude_collisions)] |         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ = warning: this is accepted in the current edition (Rust 2018) but is a hard error in Rust 2021! = note: for more information, see issue #85684 <https://github.com/rust-lang/rust/issues/85684> warning: trait-associated function `from_iter` will become ambiguous in Rust 2021 --> $DIR/future-prelude-collision-generic.rs:31:5 | LL |     Generic::<i32, i32>::from_iter(1); |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ help: disambiguate the associated function: `<Generic::<i32, i32> as MyFromIter>::from_iter` | = warning: this is accepted in the current edition (Rust 2018) but is a hard error in Rust 2021! = note: for more information, see issue #85684 <https://github.com/rust-lang/rust/issues/85684> warning: trait-associated function `from_iter` will become ambiguous in Rust 2021 --> $DIR/future-prelude-collision-generic.rs:34:5 | LL |     Generic::<_, _>::from_iter(1); |     ^^^^^^^^^^^^^^^^^^^^^^^^^^ help: disambiguate the associated function: `<Generic::<_, _> as MyFromIter>::from_iter` | = warning: this is accepted in the current edition (Rust 2018) but is a hard error in Rust 2021! = note: for more information, see issue #85684 <https://github.com/rust-lang/rust/issues/85684> warning: 3 warnings emitted </ins>

Related discussion:
text: For generic types, the prelude collision lint can produce suggestions that do not compile: Code: Suggestion from the prelude collision lint: Error after applying the suggestion: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
cc
My guess is this should be a simple fix, just copying the code the lint already uses for adding unspecified generics (). Will try implementing a fix soon.
assign
release-assignment
The code related to this lint lives in the . The relevant suggestion is generated here: The "self type" string comes from here: The code for traits is here: This is actually just a touch tricky, because currently we are getting the "self type" just by copying the text the user wrote. Probably the most correct thing for us to do would be to examine the 'self expression' HIR and, if it is a plain path, then to append the and otherwise skip it. Specifically, the other case that I am thinking about is code like this: Currently , meaning that it offers the suggestion "disambiguate the associated function: ".
claim
great! Let us know if you need anything or make progress. This issue is fairly time sensitive.
release-assignment
claim
Code change:
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

Related discussion:
text: 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.
Code change:
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

Related discussion:
text: 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.
Code change:
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

Related discussion:
text: 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)
Code change:
<ins> // Copyright 2018 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. // no-prefer-dynamic #![crate_type = "proc-macro"] extern crate proc_macro; use proc_macro::*; #[proc_macro_derive(A, attributes(b))] pub fn foo(_x: TokenStream) -> TokenStream { TokenStream::new() } </ins>

Related discussion:
text: This is the code you are supposed to use according to the lint. It fails to compile, with It compiles fine if you use just one of the two attributes. Swapping attribute order makes it complain about the last non-derive attribute. This seems broken? cc
Confirmed, this behavior is broken. Possibly related to .
As a workaround specific to serde_derive, we allow multiple elements within one attribute.
yeah, that's what I ended up doing
This should be fixed in