jiebi/CodeConvo huggingface dataset:
Change:
assert_eq!(Ok(()), r.advance_back_by(usize::MAX)); assert_eq!((r.start, r.end), (0u128 + usize::MAX as u128, u128::MAX - usize::MAX as u128)); <ins> // issue 122420, Step::forward_unchecked was unsound for signed integers let mut r = -128i8..127; assert_eq!(Ok(()), r.advance_by(200)); assert_eq!(r.next(), Some(72)); </ins> } #[test]

Discussion:
I tried this code: I expected to see this happen: No UB. Instead, this happened: UB, confirmed by Miri. is called, which does , or . The implementation of is correct here, and should be safe to call. The implementation that does a wrapping cast from to before doing the unchecked math is the incorrect code here. Signed integers should switch to just using wrapping or unsigned math, whichever gets better codegen out of LLVM. We do have and methods now, but no . <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --:
Note that this is reachable on stable since the default impl of uses and not all adapters forward both.
did you find this with Miri or just use Miri to confirm the bug? (I'm asking because I may want to add this to our "bugs found by Miri" list :)
Only confirmed/diagnosed with Miri, spotted manually when looking at the code.
Change:
<ins> // check-pass // edition:2018 #![feature(async_await)] // See issue 60414 trait Trait { type Assoc; } async fn foo<T: Trait<Assoc=()>>() -> T::Assoc { () } fn main() {} </ins>

Discussion:
With the following code: comes the following error: However, this function compiles correctly without the keyword.
cc
You can trigger this without async/await using : cc
Some more reduction in genericity and clearing up a few things: The problem is that is not know in impl trait items. It's also not related to the return position, but refers to any impl trait in the function. Outside of impl trait can be resolved without a problem, so it must be something related to the way impl trait reuses the generics of its parent.
It seems to be a missing normalization, most likely.
I have a local fix for reduction above, but is making this rather difficult as it makes output not work properly.
This also happens for definitions: My fix only seems to turn this into a cycle error for some reason. EDIT: Nevermind I just broke existential types in general lol
Marking as blocking, although I think there's minimal future compat risk. If push came to shove I personally would be ok with removing this from the blocking list. But then it looks like already fixed it =)
I think the problem is on this line of code: in particular, we "instantiate" the predicates -- meaning, substitute in the values for their type parameters -- but we never normalize them. We should be able to invoke the methods. Note that in this code we do have an available, as well, in . I think we should be able to invoke: this returns an  value, which contains obligations that must be pushed into .
Hmm, that code is only invoked if is true, which I think wouldn't be the case here since there are no region bounds at all (right?). I also noticed that does not exist in this context ( is an ), and there's no nearby either. However, another place where is called without normalizing the result is here, further down in the same file: there does exist (as does ). Quick testing shows that normalizing there fixes this issue as well, and as a bonus also fixes the issue with without ICEs!
good catch -- actually I think the lines you found are the ones I meant to direct you to in the first place. I see you have some other problems on the PR, looking now.
Change:
<del> #!/bin/sh # Copyright 2016 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. set -ex # We need to mitigate rust-lang/rust#34978 when compiling musl itself as well export CFLAGS="-fPIC -Wa,-mrelax-relocations=no" export CXXFLAGS="-Wa,-mrelax-relocations=no" MUSL=musl-1.1.14 curl https://www.musl-libc.org/releases/$MUSL.tar.gz | tar xzf - cd $MUSL ./configure --prefix=/musl-x86_64 --disable-shared make -j10 make install make clean # for i686 CFLAGS="$CFLAGS -m32" ./configure --prefix=/musl-i686 --disable-shared --target=i686 make -j10 make install cd .. # To build MUSL we're going to need a libunwind lying around, so acquire that # here and build it. curl -L https://github.com/llvm-mirror/llvm/archive/release_37.tar.gz | tar xzf - curl -L https://github.com/llvm-mirror/libunwind/archive/release_37.tar.gz | tar xzf - # Whoa what's this mysterious patch we're applying to libunwind! Why are we # swapping the values of ESP/EBP in libunwind?! # # Discovered in #35599 it turns out that the vanilla build of libunwind is not # suitable for unwinding 32-bit musl. After some investigation it ended up # looking like the register values for ESP/EBP were indeed incorrect (swapped) # in the source. Similar commits in libunwind (r280099 and r282589) have noticed # this for other platforms, and we just need to realize it for musl linux as # well. # # More technical info can be found at #35599 cd libunwind-release_37 patch -Np1 < /build/musl-libunwind-patch.patch cd .. mkdir libunwind-build cd libunwind-build cmake ../libunwind-release_37 -DLLVM_PATH=/build/llvm-release_37  -DLIBUNWIND_ENABLE_SHARED=0 make -j10 cp lib/libunwind.a /musl-x86_64/lib # (Note: the next cmake call doesn't fully override the previous cached one, so remove the cached # configuration manually. IOW, if don't do this or call make clean we'll end up building libunwind # for x86_64 again) rm -rf * # for i686 CFLAGS="$CFLAGS -m32" CXXFLAGS="$CXXFLAGS -m32" cmake ../libunwind-release_37  -DLLVM_PATH=/build/llvm-release_37  -DLIBUNWIND_ENABLE_SHARED=0 make -j10 cp lib/libunwind.a /musl-i686/lib </del>

Discussion:
Causing our builds to fail. I have no idea why ;_;
According to https://travis- We have 30GB of disk space 23 of which is available on the start of a build: ` At the end of the build, the dir is 23 GB: And such, we're filling up.
cc
According to https://travis- we start out with 5/30GB taken up
Word from travis is that we can't increase disk size right now.
According to the run-pass output directory is 17GB
"Hello world" for musl is 3.5 MB. With 2.8k tests and three separate targets being tested, that's ~30GB. That's where the space is going.
1MB of that 3.5 is debuginfo
Change:
//         ^ elided type as this type argument was the same in both sides let type_arguments = sub1.types().zip(sub2.types()); let regions_len = sub1.regions().count(); <del> for (i, (ta1, ta2)) in type_arguments.take(len).enumerate() { </del> <ins> let num_display_types = consts_offset - regions_len; for (i, (ta1, ta2)) in type_arguments.take(num_display_types).enumerate() { </ins> let i = i + regions_len; if ta1 == ta2 { values.0.push_normal("_");

Discussion:
This code (): results in with missing const arguments in the at the bottom.
Hey guys could I take this on?
Just FYI, same problem with messages involving const generics and matches, e.g. () Also for functions: ()
Interestingly, when I use concrete types for the function example, things display properly: gives ()
you're welcome to look into fixing this! However, I'm not sure what might be causing this problem, so I don't have any suggestions for where to start looking yet.
I spent a few hours doing some digging and I can't find anything yet as well, though I'm as of yet still quite unfamiliar with the code-base. I might have more time tomorrow to look things over again, or maybe the day after.
Change:
let field = ecx.operand_field(down, field.index() as u64).unwrap(); // and finally move back to the const world, always normalizing because // this is not called for statics. <del> op_to_const(&ecx, field).unwrap() </del> <ins> op_to_const(&ecx, field) </ins> } // this function uses `unwrap` copiously, because an already validated constant must have valid

Discussion:
It looks like this was broken in the release of 1.32.0 (and is still broken, even on nightly) (checked on ). The following example program: Fails to compile: Interestingly, making the fixes it. My Rust version: I know , but I don't think this qualifies as a field access. And yes, I'm aware of . cc
Interesting. Looks like a validation issue? Cc
Change:
vtable_entries, vtable_trait_upcasting_coercion_new_vptr_slot, subst_and_check_impossible_predicates, <ins> is_impossible_method, </ins> try_unify_abstract_consts: |tcx, param_env_and| { let (param_env, (a, b)) = param_env_and.into_parts(); const_evaluatable::try_unify_abstract_consts(tcx, (a, b), param_env)

Discussion:
Found in [this topic] on URLO. It shows the method on the page for . This is misleading, because you can't actually call that method, because . [this topic]: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
The same issue with and . do you know how to exclude these options from hashmap? I'm still digging with it, if hashmap has this kind of issue, other data structures maybe have similar kind of issue. I think we need to check the trait bounds when generating the doc.
I expect you want to do it while — turning the rustc IR into rustdoc's own IR — or earlier. Doing it later would mean reimplementing parts of rustc's type checker using rustdoc's IR, and nobody wants to do that.
For the record I was working on this, sorry for not claiming this... Anyways, let me know if you don't get around to this, and I'll pick it back up :smile_cat: . Seems like you've claimed a few issues in the past hours so not sure which ones you've gotten started with.
I haven't started this one, released it, please go ahead. It's funny and also helpful to learn some Rust internals, I'm starting with some trivial fixes
Thank you Sorry for the mistake, and I am excited for you to get involved more in the compiler :) claim
This is a dupe of
Uh, sorry, actually not a dupe. That's impl level, this is method level. I think there were legitimate concerns with hiding whole impls in that other issue. Reopening this, andf I'll probably solve this first.
Change:
<del> Subproject commit d7342a9a957470bb62c890cf88fc655ccfb755cc </del> <ins> Subproject commit ceb177eeefa7d67ca29230d2e7e8584f97d4fdad </ins>

Discussion:
Works fine with : This is a bug in LLVM () that has already been fixed in . We only have to backport the fix. cc
Seeing the reproduction involves assembly and jumping to a label that hasn’t been passed as an input for the asm!, I do not think this deserves a backport.
I meant backporting/cherry-picking the upstream fix into our LLVM fork; not a "beta-backport". People that use the targets make pretty much exclusive use of the nightly channel (because Xargo, unstable features, etc.) so whether a fix makes it faster to the stable/beta channel doesn't really make much difference to us. Honest question: How does one pass a function to with the goal of using it as a label? And does that handle the mangling of the function?
There’s no support for doing that directly in LLVM sadly, mostly because this is not a very desired feature; and you can work around the issue with some indirection, which not only handles mangling but also any relocation business you might have going on (pardon my x86): compiles to code like this (PIC) or in static relocation mode.
Clever. The ARM asm parser doesn't seem to like the dereference though:
to branch to an address in a register can do but if you want to branch to a label you need an integer constant constraint.
Thanks, That works nicely and will let me hide more symbols in some crates like f3 . (Using "b $0" with the thumbv6m target still needs though)
Change:
<ins> // See https://github.com/rust-lang/rust/issues/88442 // run-rustfix // edition:2018 // check-pass #![allow(unused)] #![warn(rust_2021_prelude_collisions)] trait AnnotatableTryInto { fn try_into<T>(self) -> Result<T, Self::Error> where Self: std::convert::TryInto<T> { std::convert::TryInto::try_into(self) } } impl<T> AnnotatableTryInto for T where T: From<u8> {} fn main() -> Result<(), &'static str> { let x: u64 = 1; AnnotatableTryInto::try_into::<usize>(x).or(Err("foo"))?.checked_sub(1); //~^ WARNING trait method `try_into` will become ambiguous in Rust 2021 //~| WARNING this is accepted in the current edition (Rust 2018) but is a hard error in Rust 2021! AnnotatableTryInto::try_into::<usize>(x).or(Err("foo"))?; //~^ WARNING trait method `try_into` will become ambiguous in Rust 2021 //~| WARNING this is accepted in the current edition (Rust 2018) but is a hard error in Rust 2021! Ok(()) } </ins>

Discussion:
Given the following code: The lint provides two suggestions, both of which fail with different errors. The first: fails with "type annotations needed" because the generics in the path are lost. The second: fails with "the trait bound is not satisfied". Ideally I think the suggestions should be: Found in the 2021 crate run migrating https://crater-
Looks like the turbofishes are swimming away! grabs turbofish food
Change:
<del> Subproject commit 18667a856596713fc4479f99b96afc7f03aa995c </del> <ins> Subproject commit fa91a89193d26e6a86e2eee1cbaa38cb28ccebe1 </ins>

Discussion:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool miri has failing tests. A follow-up PR to the repository is needed to fix the fallout. cc do you think you would have time to do the follow-up work? If so, that would be great!
Test failures are fixed in rust-lang/miri; all this needs is a submodule sync.
Change:
}; 51 }]; <ins> while true { break (|| { //~ ERROR `break` with value from a `while` loop let local = 9; }); } </ins> }

Discussion:
<!-- [31mICE[0m: Rustc '' 'error: internal compiler error: no type for local variable HirId(DefId(0:3 ~ E798F6428C27040F6BCB788CE3C70B28DC596BC8C3AD45A9CC67EC872D6B13EF[a927]::main).70) (local )', 'error: internal compiler error: no type for local variable HirId(DefId(0:3 ~ E798F6428C27040F6BCB788CE3C70B28DC596BC8C3AD45A9CC67EC872D6B13EF[a927]::main).70) (local )' File: --auto-reduced (treereduce-rust): &lt;details&lt;summary&lt;strongoriginal code&lt;/strong&lt;/summary&lt;poriginal: </p</detailsVersion information Command: &lt;!-- Include a backtrace in the code block by setting in your environment. E.g. . --&lt;details&lt;summary&lt;strongProgram output&lt;/strong&lt;/summary&lt;p&lt;/p&lt;/details&lt;!-- TRIAGEBOTSTART --&lt;!-- TRIAGEBOTASSIGNSTART --&lt;!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --&lt;!-- TRIAGEBOTASSIGNEND --&lt;!-- TRIAGEBOTEND --
Regression in nightly-2023-10-31 Regression in = ping
reduced a bit further:
claim
Change:
// except according to those terms. use fmt::{Formatter, Result, LowerExp, UpperExp, Display, Debug}; <ins> use mem; </ins> use num::flt2dec; <ins> // Don't inline this so callers don't use the stack space this function // requires unless they have to. #[inline(never)] fn float_to_decimal_common_exact<T>(fmt: &mut Formatter, num: &T, sign: flt2dec::Sign, precision: usize) -> Result where T: flt2dec::DecodableFloat { unsafe { let mut buf: [u8; 1024] = mem::uninitialized(); // enough for f32 and f64 let mut parts: [flt2dec::Part; 5] = mem::uninitialized(); let formatted = flt2dec::to_exact_fixed_str(flt2dec::strategy::grisu::format_exact, *num, sign, precision, false, &mut buf, &mut parts); fmt.pad_formatted_parts(&formatted) } } // Don't inline this so callers that call both this and the above won't wind // up using the combined stack space of both functions in some cases. #[inline(never)] fn float_to_decimal_common_shortest<T>(fmt: &mut Formatter, num: &T, sign: flt2dec::Sign) -> Result where T: flt2dec::DecodableFloat { unsafe { // enough for f32 and f64 let mut buf: [u8; flt2dec::MAX_SIG_DIGITS] = mem::uninitialized(); let mut parts: [flt2dec::Part; 5] = mem::uninitialized(); let formatted = flt2dec::to_shortest_str(flt2dec::strategy::grisu::format_shortest, *num, sign, 0, false, &mut buf, &mut parts); fmt.pad_formatted_parts(&formatted) } } </ins> // Common code of floating point Debug and Display. fn float_to_decimal_common<T>(fmt: &mut Formatter, num: &T, negative_zero: bool) -> Result where T: flt2dec::DecodableFloat

Discussion:
floattodecimalcommon in does this: let mut buf = [0; 1024]; let mut parts = [flt2dec::Part::Zero(0); 16]; and then passes buf and parts to flt2dec::toexactfixedstr or flt2dec::toshorteststr Looking at the docs for those functions at and the "parts" array needs to have length at least 5, right? And the "buf" array needs to be at least 800+ for the toexactfixedstr case but only 17 (MAXSIGDIGITS) for the toshorteststr case, afaict. Changing the toshorteststr case to not use the huge buffer would probably help out too. Also, it's not clear to me that the "buf" scratch buffer needs to be zero-initialized. Does it?
Note that I'm poking at this a bit.
I spun off the zeroing thing into because I have a fix for that... we may still want to make the stackframe here smaller, though.
Change:
mcount: "mcount".into(), llvm_mcount_intrinsic: None, llvm_abiname: "".into(), <del> relax_elf_relocations: true, </del> <ins> relax_elf_relocations: false, </ins> llvm_args: cvs![], use_ctors_section: false, eh_frame_header: true,

Discussion:
Hashbrown crate starts fail when running: , , with: <details<summaryBacktrace</summary<pFor : </p</details
Could this be related to cc
I'm also seeing this on x86_64 with the recent nightlies: Update 1: It seems like in both cases it's related to cross. The original PR mentions problems with old versions. Could it be that cross needs to update their docker images? (Though they seem to be based on Ubuntu 20, which doesn't seem THAT old) Update 2: cross runs
Centos 7 used by i686-dist builder seems to use Binutils 2.27, dist-armv7 uses Binutils 2.32 and dist-various1 (so thumbv6m-none-eabi) uses Binutils 2.38. They all are indeed newer than:
hashbrown ci uses cross 0.2.5, which is the latest stable release for cross. To fix this issue with cross specifically, one can set the image used by cross to be a newer version, cross 0.2.5 images use ubuntu 16.04, we can change that with the env vars or config (see ) (make sure to set the correct env-var and image for the specific target)
The diagnostic looks similar to a binutils 2.41 change I made to fix ld: Allow RX8664GOTPCREL for call *_tlsgetaddr Threadlocal int a; int main() { return a; } % gcc -fno-plt -fpic a.c -fuse-ld=bfd -Wa,-mrelax-relocations=no /tmp/ccSSBgrg.o: TLS transition from RX8664TLSGD to RX8664_GOTTPOFF against .text' failed failed to set dynamic section sizes: bad value collect2: error: ld returned 1 exit status There is incompatibility between  and with GNU ld<2.41. You may need to figure out where similar semantics are used.
Ran into this in github CI today as well (e.g. ). Works fine locally on Arch though when I try to recreate it. EDIT: Managed to reproduce it locally. I was mixing up -gnu and -musl targets, my bad.
Posted a revert at
This is really not a great solution for projects that build binaries for releases though (like I do).

To target an old enough glibc to work on all systems (e.g. CentOS/RHEL, stable Debian, etc) you need to build on a fairly old distro. And then you also get older ld etc as well. It would be great if you could tell rust & gcc (for native dependencies) to target an older glibc than the system one, that would solve a lot of issues.
In GCC/Clang, can happen with . is to use modern GCC/Clang style . I am not sure why is related to the problem. I think I should keep arguing for for all targets, not just non-x86. is prone to cause such problems for GNU ld and possibly mold.
cc
I apologize to everyone, forgot about this issue. I can state that this issue is closed and no longer relevant. suggestion (as a workaround) and pull request fixed the issue.
Change:
encode_bounds_and_type(rbml_w, ecx, &lookup_item_type(tcx, def_id)); encode_name(rbml_w, item.ident.name); encode_path(rbml_w, path); <ins> encode_attributes(rbml_w, item.attrs.as_slice()); </ins> encode_inlined_item(ecx, rbml_w, IIItemRef(item)); encode_visibility(rbml_w, vis); encode_stability(rbml_w, stab);

Discussion:
and are currently empty, except for the module’s docstring. Compare with and
I don't know the best way to tackle this, as I know little about re-exported documentation. do you know?
To clarify: I think this is a bug in rustdoc code rather than documentation that needs to be written.
Agreed.
This is a dupe of (although that should be updated to reflect the static -const split).
Not actually a dupe of , my mistake.
Change:
<del> //@ known-bug: #130921 //@ compile-flags: -Zvalidate-mir -Copt-level=0 --crate-type lib pub fn hello() -> [impl Sized; 2] { if false { let x = hello(); let _: &[i32] = &x; } todo!() } </del>

Discussion:
<!-- [31mICE[0m: Rustc '-Zvalidate-mir -ooutputfile -Zdump-mir-dir=dir' 'thread 'rustc' panicked at 'broken MIR in Item(DefId(0:7 ~ a[e8bd]::hello)) (after pass CheckPackedRef) at bb3[6]:'', 'thread 'rustc' panicked at 'broken MIR in Item(DefId(0:7 ~ a[e8bd]::hello)) (after pass CheckPackedRef) at bb3[6]:'' File: --auto-reduced (treereduce-rust): original: Version information ` Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details<!-- query stack: [mirbuilt] building MIR for [hasffiunwindcalls] checking if contains FFI-unwind calls --
another one from rust #![feature(typealiasimpltrait)] fn rpit() -impl Sized {} pub type Tait = impl Sized; pub fn foo() -Box<dyn std::future::Future<Output = Tait{ Box::new(async { let out: Tait = rpit(); _out }) } ``
another one that is a bit smaller than the original example:
Change:
<ins> error[E0599]: the method `extend_from_slice` exists for mutable reference `&mut Vec<NoDerives>`, but its trait bounds were not satisfied --> $DIR/issue-91492.rs:4:9 | LL | pub struct NoDerives; | --------------------- doesn't satisfy `NoDerives: Clone` LL | fn fun1(foo: &mut Vec<NoDerives>, bar: &[NoDerives]) { LL |     foo.extend_from_slice(bar); |         ^^^^^^^^^^^^^^^^^ | = note: the following trait bounds were not satisfied: `NoDerives: Clone` help: consider annotating `NoDerives` with `#[derive(Clone)]` | LL | #[derive(Clone)] | error[E0599]: the method `extend_from_slice` exists for mutable reference `&mut Vec<SomeDerives>`, but its trait bounds were not satisfied --> $DIR/issue-91492.rs:12:9 | LL | pub struct SomeDerives; | ----------------------- doesn't satisfy `SomeDerives: Clone` LL | fn fun2(foo: &mut Vec<SomeDerives>, bar: &[SomeDerives]) { LL |     foo.extend_from_slice(bar); |         ^^^^^^^^^^^^^^^^^ | = note: the following trait bounds were not satisfied: `SomeDerives: Clone` help: consider annotating `SomeDerives` with `#[derive(Clone)]` | LL | #[derive(Clone)] | error[E0599]: the method `use_clone` exists for struct `Object<NoDerives, SomeDerives>`, but its trait bounds were not satisfied --> $DIR/issue-91492.rs:22:9 | LL | pub struct NoDerives; | --------------------- doesn't satisfy `NoDerives: Clone` ... LL | struct Object<T, A>(T, A); | -------------------------- method `use_clone` not found for this ... LL |     foo.use_clone(); |         ^^^^^^^^^ method cannot be called on `Object<NoDerives, SomeDerives>` due to unsatisfied trait bounds | = note: the following trait bounds were not satisfied: `NoDerives: Clone` help: consider annotating `NoDerives` with `#[derive(Clone)]` | LL | #[derive(Clone)] | error: aborting due to 3 previous errors For more information about this error, try `rustc --explain E0599`. </ins>

Discussion:
Given the following code: The current output is: Ideally the output should look like: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim