jiebi/CodeConvo huggingface dataset:
Change:
On x8664, Aarch64, and PowerPC will not pass the lint, but it should. Given the following: The compiler will yield: The implementation of for the x8664, Aarch64, and PowerPC architectures uses or as the pointer type for the pointers to the architecture specific save areas (e.g., ).
defines . Perhaps should be used instead of
It would be fine to just special-case the language item in the lint implementation.
This seems reasonable to me too. The structure should (for obvious reasons) always be FFI safe.

Discussion:
all supported platforms", issue = "44930")] struct VaListImpl { <del> stack: *mut (), gr_top: *mut (), vr_top: *mut (), </del> <ins> stack: *mut c_void, gr_top: *mut c_void, vr_top: *mut c_void, </ins> gr_offs: i32, vr_offs: i32, }

gpr: u8, fpr: u8, reserved: u16, <del> overflow_arg_area: *mut (), reg_save_area: *mut (), </del> <ins> overflow_arg_area: *mut c_void, reg_save_area: *mut c_void, </ins> } /// x86_64 ABI implementation of a `va_list`.

struct VaListImpl { gp_offset: i32, fp_offset: i32, <del> overflow_arg_area: *mut (), reg_save_area: *mut (), </del> <ins> overflow_arg_area: *mut c_void, reg_save_area: *mut c_void, </ins> } /// A wrapper for a `va_list`
Change:
I did drop our patch to fix python detection, thinking it was fixed upstream. It appears not to be and reapplying our patch to fix python detection does not appear to fix the problem.
It may not be related to python. Could just be failing in the vicinity of the python test.
the way I end up dealing with this is making a temp directory and putting another python symlink in with it. So perhaps Rust could detect if is python3 or if only exists and do that before it builds LLVM. That would avoid needing to patch LLVM too. It looks like LLVM has a variable in , so perhaps Rust could be using that somehow.
I can confirm that this also occurs in OS X.
Switching to python 2.7 seemed to allow it to build - I was on python 3.3. For those using MacPorts: .
Fixed.

Discussion:
LDFLAGS=$LLVM_LDFLAGS LLVM_FLAGS="$LLVM_TARGETS $LLVM_OPTS $LLVM_BUILD  <del> $LLVM_HOST $LLVM_TARGET" </del> <ins> $LLVM_HOST $LLVM_TARGET --with-python=$CFG_PYTHON" </ins> msg "configuring LLVM with:" msg "$LLVM_FLAGS"
Change:
Godbolt: Basically the issue is that you compute , check that it doesn't overflow, and then you verify that is greater than , which it of course always is, since you checked for an overflow! This is probably an LLVM optimization bug, but I'm starting here :-) Command line arguments: Source: ASM:
Slightly reduced testcase: LLVM does not realize that and are the same here.
Ok, looks like the thing to do is file an LLVM bug -- do you know off hand if they're ok with Rust reproducers, or do they prefer C ones?
Ok, ended up converting to C because that seemed easy:
Submitted additionally for the IR pattern above (which is an issue separate from the missing combining). Just verified that fixing this does indeed eliminate the check in this example.
am I correct in reading that this has been waiting on a review of the LLVM patch?
Needs a rebase. More generally though, I think this is fighting a losing battle. and are not considered canonical IR for a reason: They optimize badly in the middle end. I think we'd be better off with generating the canonical variants instead (which are and ). LLVM will still form during CGP, but this should optimize better in the middle end (including avoiding the issue here). As we already have a good benchmark for the overhead of overflow checks in , I think it might be worth trying to rerun that without using the unsigned overflow intrinsics.
From the :
once this makes it's way into Rust's LLVM (is there a good way to track this?) I'll verify that the assembly in this bug was improved, and if so I'll rebase the rustc patch and we can get some new numbers!
Ok, confirmed that the recent LLVM10 update removes this branch: Shall this be closed?
Actually, that was probably premature. We should add a codegen test.
is there a good example of what a test looks like? I can spin one up pretty easily if someone can point me at how to add one.
Codegen tests are located in . One test that is thematically related: . They use . Codegen tests can be run with:
Thanks much, that's exactly what I needed! PR is up now.

Discussion:
<ins> // no-system-llvm // compile-flags: -O -C overflow-checks=on #![crate_type = "lib"] pub struct S1<'a> { data: &'a [u8], position: usize, } // CHECK-LABEL: @slice_no_index_order #[no_mangle] pub fn slice_no_index_order<'a>(s: &'a mut S1, n: usize) -> &'a [u8] { // CHECK-NOT: slice_index_order_fail let d = &s.data[s.position..s.position+n]; s.position += n; return d; } // CHECK-LABEL: @test_check #[no_mangle] pub fn test_check<'a>(s: &'a mut S1, x: usize, y: usize) -> &'a [u8] { // CHECK: slice_index_order_fail &s.data[x..y] } </ins>
Change:
For example in the doc for : The in the doc links to instead of . Outside of the standard library, links to the primitive, unless there is a statement in which case it links to the module.
Therefore we should try to link to types before modules I assume? I'll see how it comes out.
Yes I think types should go before modules. After all it's always possible to use charstd::charstd::charchar` as the link text.
Oh btw, you can force the resolution by adding the type before hand like . I wonder if this is documented somewhere... Just like you can say it's a macro by at the end or a function by adding at the end.
It comes from the compiler directly. We need to re-order how the items are resolved. cc
an alternative is to resolve in an empty module first and only then resolve in the current scope. This ambiguity is only possible for primitives, any other types will give a multiple definition error: Since primitives are always in scope they will be the only thing in scope in the empty module (assuming there's no , , or keyword).
Originally posted by in is this still your opinion? That would mean closing this issue as wontfix, but I'm not convinced that's the most clear behavior.
Well, I would close this as fixed, but yes. I think this is a pretty rare situation to be in and the current behavior is not incorrect, it's just surprising, but "fixing" it would also make it surprising to another group.
and I discussed this again and decided it would be less surprising than the current behavior ( himself made the same mistake in !) So I plan to implement this sometime soon.

Discussion:
return Ok((res, Some(path_str.to_owned()))); } Res::Def(DefKind::Mod, _) => { <del> // This resolved to a module, but if we were passed `type@`, // we want primitive types to take precedence instead. if disambiguator == Some(Disambiguator::Namespace(Namespace::TypeNS)) { </del> <ins> // This resolved to a module, but we want primitive types to take precedence instead. if matches!( disambiguator, None | Some(Disambiguator::Namespace(Namespace::TypeNS)) ) { </ins> if let Some(prim) = is_primitive(path_str, ns) { if extra_fragment.is_some() { return Err(ErrorKind::AnchorFailure(AnchorFailure::Primitive));

pub struct MyString; /// See also [char] <del> // @has intra_link_prim_precedence/struct.MyString2.html '//a/@href' 'intra_link_prim_precedence/char/index.html' </del> <ins> // @has intra_link_prim_precedence/struct.MyString2.html '//a/@href' 'https://doc.rust-lang.org/nightly/std/primitive.char.html' </ins> pub struct MyString2; <ins> /// See also [crate::char] and [mod@char] // @has intra_link_prim_precedence/struct.MyString3.html '//*[@href="../intra_link_prim_precedence/char/index.html"]' 'crate::char' // @has - '//*[@href="../intra_link_prim_precedence/char/index.html"]' 'mod@char' pub struct MyString3; </ins>
Change:
I have the following code: I forgot to use , so it wasn't in scope. rustc gave me the following errors: Maybe this is the intended behavior, but it seems odd to report an invalid method receiver type error simply because the type's name was unknown.

Discussion:
} else { debug!("receiver_is_valid: type `{:?}` does not deref to `{:?}`", receiver_ty, self_ty); <del> return false </del> <ins> // If he receiver already has errors reported due to it, consider it valid to avoid // unecessary errors (#58712). return receiver_ty.references_error(); </ins> } // without the `arbitrary_self_types` feature, `receiver_ty` must directly deref to

<ins> struct AddrVec<H, A> { h: H, a: A, } impl<H> AddrVec<H, DeviceId> { //~^ ERROR cannot find type `DeviceId` in this scope pub fn device(&self) -> DeviceId { //~^ ERROR cannot find type `DeviceId` in this scope self.tail() } } fn main() {} </ins>

<ins> error[E0412]: cannot find type `DeviceId` in this scope --> $DIR/issue-58712.rs:6:20 | LL | impl<H> AddrVec<H, DeviceId> { |                    ^^^^^^^^ not found in this scope error[E0412]: cannot find type `DeviceId` in this scope --> $DIR/issue-58712.rs:8:29 | LL |     pub fn device(&self) -> DeviceId { |                             ^^^^^^^^ not found in this scope error: aborting due to 2 previous errors For more information about this error, try `rustc --explain E0412`. </ins>
Change:
While attempting to build the current bobbin-sdk under Ubuntu 18.04 using rust 1.34.0-nightly ( 2019-02-26) I get a panic in rustc.
cc
Minimal repro: you need both the , a method call , and a method call on the result of that in order to trigger promotion. It seems like is promoted to make a for the call to
Ok, so promotion is indeed screwing up. The MIR is promoting the argument.
triage: P-high. Looks under control.
Just to confirm, this has not made it out to the nightly, correct? As of today I am still seeing the same error when attempting to build bobbin-hz as part of bobbin-sdk.
No, is still open, I'll bump its priority

Discussion:
// Refers to temporaries which cannot be promoted as // promote_consts decided they weren't simple enough. <ins> // FIXME(oli-obk,eddyb): Remove this flag entirely and // solely process this information via `IsNotConst`. </ins> struct IsNotPromotable; impl Qualif for IsNotPromotable {

fn in_call( cx: &ConstCx<'_, 'tcx>, callee: &Operand<'tcx>, <del> _args: &[Operand<'tcx>], </del> <ins> args: &[Operand<'tcx>], </ins> _return_ty: Ty<'tcx>, ) -> bool { if cx.mode == Mode::Fn {

} } <del> // FIXME(eddyb) do we need "not promotable" in anything // other than `Mode::Fn` by any chance? false </del> <ins> Self::in_operand(cx, callee) || args.iter().any(|arg| Self::in_operand(cx, arg)) </ins> } }

<ins> // compile-pass // note this was only reproducible with lib crates // compile-flags: --crate-type=lib pub struct Hz; impl Hz { pub const fn num(&self) -> u32 { 42 } pub const fn normalized(&self) -> Hz { Hz } pub const fn as_u32(&self) -> u32 { self.normalized().num() // this used to promote the `self.normalized()` } } </ins>
Change:
I have this crate layout: src/ parent/ where is an empty file and is: This compiles successfully and we end up with a module at backed by the file But if goes anywhere near a proc macro, it no longer works. where is this macro: The error is: so it is looking for a file corresponding to as though the were not contained inside of . I hit this while working on The same problem does not occur if is defined as a macro_rules macro. Mentioning who may know what is going wrong or whether there is a simple rustc fix.
I never audited the module search code and don't know how it fits into the larger macro story. Even without macros it's , so I'd expect issues in macros as well. I'll investigate.
Still the same behavior as of rustc 1.40.0-nightly ( 2019-10-01).
It's still in my queue, just not with a high enough priority :(
This was fixed by , I'll add a test.

Discussion:
<ins> // Out-of-line module is found on the filesystem if passed through a proc macro (issue #58818). // check-pass // aux-build:test-macros.rs #[macro_use] extern crate test_macros; mod outer { identity! { mod inner; } } fn main() {} </ins>
Change:
probably related to
cc might not be impl-trait-in-let-binding related after all
Ah, good to know. Are you going to tackle this? I'm not sure if the RFC for should support this syntax (I suspect not), but it would be nice (for the sake of my upcoming PR) to support within impls at an HIR level, at least.
Existential types for associated types in trait impls are already supported and suggested to exist by the RFC. The issue here is probably that I never considered generics in that light. Or am I misunderstanding what you mean by "this syntax"?
Ah, I was probably thinking of the case of inherent impls... glad these are supported.
The ICE doesn't appear on the latest nightly via the above link.
Good spot. Not sure what PR fixed this, but I suspect it can be closed now...
Before closing this, we can add the tests for this.
It depends if there is already an equivalent (minimal) example. If there is, no need... if not, then yes (and let's minimise this one).
It's sorta harder to minimize something that no longer ICEs... I think it would be sufficient to simply add a test with the above snippet for now and close the issue after.
Fair point. I mean, we could use an old nightly, but that's a pain.

Discussion:
<ins> #![feature(existential_type)] trait UnwrapItemsExt { type Iter; fn unwrap_items(self) -> Self::Iter; } impl<I, T, E> UnwrapItemsExt for I where I: Iterator<Item = Result<T, E>>, E: std::fmt::Debug, { existential type Iter: Iterator<Item = T>; //~^ ERROR: could not find defining uses fn unwrap_items(self) -> Self::Iter { //~^ ERROR: type parameter `T` is part of concrete type //~| ERROR: type parameter `E` is part of concrete type self.map(|x| x.unwrap()) } } fn main() {} </ins>

<ins> error: type parameter `T` is part of concrete type but not used in parameter list for existential type --> $DIR/issue-58887.rs:16:41 | LL |       fn unwrap_items(self) -> Self::Iter { |  _________________________________________^ LL | | LL | | LL | |         self.map(|x| x.unwrap()) LL | |     } | |_____^ error: type parameter `E` is part of concrete type but not used in parameter list for existential type --> $DIR/issue-58887.rs:16:41 | LL |       fn unwrap_items(self) -> Self::Iter { |  _________________________________________^ LL | | LL | | LL | |         self.map(|x| x.unwrap()) LL | |     } | |_____^ error: could not find defining uses --> $DIR/issue-58887.rs:13:5 | LL |     existential type Iter: Iterator<Item = T>; |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ error: aborting due to 3 previous errors </ins>
Change:
I started to get the following error with my nightly builds around two days ago: Using I got the following commit and after building rustc manually I got down to this PR. After poking around my project I found the method in here was causing the issue (stubbing out the method fixed the error) but I haven't been able to reproduce this outside of my codebase (this code is used as a separate crate) Following the on the error causes the error still to happen until increasing it to Sorry I can't be more helpful with a way to reproduce this at the moment
This might be expected, since types used internally can change without notice, and your code might have been getting pretty close to the length limit even before that. Are you chaining/nesting a lot of types (iterators or futures)?
I use iterator chains quite a bit. The thing that confused me was why doubling the limit to wasn't enough and I had to go all the way to which seems like a huge jump.
Played around on the playground and got this silly example: On stable this compiles but on nightly you have to increase the type length limit past the initial suggestion all the way to . So chances are I have something similar in my code (filter inside a filter) and changes are just amplified in my case.
potentially related to
assigning P-high for now since this is a stable-to-beta regression. Given that its already been narrowed down to PR ... this may be a T-libs issue rather than T-compiler one? Not sure.
I would normally also remove the nomination tag, since I do not think there is much for T-compiler to discuss here apart from the severity of the regression. But since it is potentially related to , I figured I'll leave the nomination tag for now, just to help ensure that when we discuss , we will hopefully remember to take note of this issue () as well.
triage: Under assumption that this is duplicate of , I'm going to downgrade this to P-medium and remove the nomination tag.
Afaict this issue can now be closed as the blowup of iterator adapters has been reduced and is used to track the more general problem.

Discussion:
<ins> // run-pass //! This snippet causes the type length to blowup exponentially, //! so check that we don't accidentially exceed the type length limit. // FIXME: Once the size of iterator adaptors is further reduced, // increase the complexity of this test. fn main() { let c = 2; let bv = vec![2]; let b = bv .iter() .filter(|a| **a == c); let _a = vec![1, 2, 3] .into_iter() .filter(|a| b.clone().any(|b| *b == *a)) .filter(|a| b.clone().any(|b| *b == *a)) .filter(|a| b.clone().any(|b| *b == *a)) .filter(|a| b.clone().any(|b| *b == *a)) .filter(|a| b.clone().any(|b| *b == *a)) .filter(|a| b.clone().any(|b| *b == *a)) .filter(|a| b.clone().any(|b| *b == *a)) .filter(|a| b.clone().any(|b| *b == *a)) .filter(|a| b.clone().any(|b| *b == *a)) .filter(|a| b.clone().any(|b| *b == *a)) .filter(|a| b.clone().any(|b| *b == *a)) .filter(|a| b.clone().any(|b| *b == *a)) .filter(|a| b.clone().any(|b| *b == *a)) .filter(|a| b.clone().any(|b| *b == *a)) .collect::<Vec<_>>(); } </ins>
Change:
This issue tracks stabilization for 2 methods in : -
If this feature is accepted, they should implement as well.
Good point, I didn't notice that already implements . Another candidate that could is , and maybe there are more to consider for completeness.
I actually didn't notice either until I went digging in for a totally separate issue. Will have a PR for that separately, although I won't include because it'd be instantly stable, and I'm not sure whether we want to guarantee that.
Is there a reason to not add asslicemut for these? Particularly IterMut, where it makes the iteration over mutable pairs nicer.
Only is sound, and that's offered at the moment. Otherwise, you can have multiple mutable borrows to the same spot in memory.
should be just as sound as here. It could not be , but that's true for & as well.
Yes, as long as it borrows from the itself, not its parameterized lifetime, should be fine. I guess for mutable pairs, you mean something like this?
Yeah, exactly that.
What is the status of this? Is anything required for stabilization other than someone to propose stabilization, make a stabilization PR, and FCP? In rowan, rust-analyzer's syntax tree backend, to remove unneeded allocations from syntax node cache hits. A simple patch that just does so via an arrayvec already sees a 5% improvement on rust-analyzer's main integration benchmark (not rowan's, and not purely parsing!), but being able to use the fact that already has a non-destructively-iterable array backing would make even that collect/copy unnecessary.
One of thse (vec::Drain::as_slice) is already stabilized. As for the other one: we discussed this tracking issue in the libs meeting, and would be happy to see a stabilization PR.

Discussion:
/// Basic usage: /// /// ``` <del> /// # #![feature(slice_iter_mut_as_slice)] </del> /// let mut slice: &mut [usize] = &mut [1, 2, 3]; /// /// // First, we get the iterator:

/// // Now `as_slice` returns "[2, 3]": /// assert_eq!(iter.as_slice(), &[2, 3]); /// ``` <del> #[unstable(feature = "slice_iter_mut_as_slice", reason = "recently added", issue = "58957")] </del> <ins> #[stable(feature = "slice_iter_mut_as_slice", since = "1.53.0")] </ins> pub fn as_slice(&self) -> &[T] { self.make_slice() } } <ins> #[stable(feature = "slice_iter_mut_as_slice", since = "1.53.0")] impl<T> AsRef<[T]> for IterMut<'_, T> { fn as_ref(&self) -> &[T] { self.as_slice() } } </ins> iterator! {struct IterMut -> *mut T, &'a mut T, mut, {mut}, {}} /// An internal abstraction over the splitting iterators, so that
Change:
This example prints when compiled and run in debug mode: Compiling and running in release mode causes a segfault in  because is nul. Enabling debug info in release mode via makes the segfault go away.
thanks for reporting this. The example should probably look more like the following. The example still segfaults (even in debug mode). If is used in the function the issue does not happen. Essentially we're optimizing to the following Note the missing and . I think this is happening because we're hitting . I'll do some more investigation shortly.
the code I list in the above example should work after is merged.

Discussion:
mut bx: Bx, ) { if self.fn_ty.c_variadic { <del> if let Some(va_list) = self.va_list_ref { bx.va_end(va_list.llval); </del> <ins> match self.va_list_ref { Some(va_list) => { bx.va_end(va_list.llval); } None => { bug!("C-variadic function must have a `va_list_ref`"); } </ins> } } let llval = match self.fn_ty.ret.mode {

PassMode::Ignore(IgnoreMode::Zst) => { return local(OperandRef::new_zst(bx.cx(), arg.layout)); } <del> PassMode::Ignore(IgnoreMode::CVarArgs) => { let backend_type = bx.cx().immediate_backend_type(arg.layout); return local(OperandRef { val: OperandValue::Immediate(bx.cx().const_undef(backend_type)), layout: arg.layout, }); } </del> <ins> PassMode::Ignore(IgnoreMode::CVarArgs) => {} </ins> PassMode::Direct(_) => { let llarg = bx.get_param(bx.llfn(), llarg_idx as c_uint); bx.set_value_name(llarg, &name);

<ins> // compile-flags: -C opt-level=3 #![crate_type = "lib"] #![feature(c_variadic)] #![no_std] use core::ffi::VaList; extern "C" { fn vprintf(fmt: *const i8, ap: VaList) -> i32; } // Ensure that `va_start` and `va_end` are properly injected even // when the "spoofed" `VaList` is not used. #[no_mangle] pub unsafe extern "C" fn c_variadic_no_use(fmt: *const i8, mut ap: ...) -> i32 { // CHECK: call void @llvm.va_start vprintf(fmt, ap) // CHECK: call void @llvm.va_end } </ins>
Change:
Consider the following code snippet: This will trigger a 'struct is never constructed' warning, even though the struct is clearly constructed in the implementation of . The problem seems to be caused by using as the constructor. If I replace with the name of the struct, as in the following code snippet, the warning goes away:
You seem to have posted the same snippet twice
My bad! I've updated my comment.
I think this is because is not public, and so rustc can see that that trait implementation is never used. If you make it , the warning goes away. (With a new warning about inner never being used, which is also true, and if you make that , you get no warnings)
That seems reasonable, but in that case, I'd expect to get a warning if is private, regardless of whether I instantiate it with or in the implementation of . As it stands, I only get a warning if I instantiate it with , which seems inconsistent?
This also happens with enum variants and "variant is never constructed" warning, see .
This also applies in connection with : I get warnings about and although they are clearly used multiple times in my code. But maybe I'm doing something wrong here or getting it wrong as a concept in my head; if so, I'm glad for some pointers and hints :-)
None of the incorrect warnings are emitted anymore (nightly 2023-01-22). label: +E-needs-test

Discussion:
<ins> // check-pass // Make sure we don't have any false positives about the "struct is never constructed" lint. #![deny(dead_code)] struct Foo { #[allow(dead_code)] inner: u32, } impl From<u32> for Foo { fn from(inner: u32) -> Self { Self { inner } } } fn main() {} </ins>