jiebi/CodeConvo huggingface dataset:
Code change:
AtomicOrderingFence, AtomicOrderingLoad, AtomicOrderingStore, ImproperCTypes, InvalidAtomicOrderingDiag, OnlyCastu8ToChar, OverflowingBinHex, OverflowingBinHexSign, OverflowingBinHexSub, OverflowingInt, OverflowingIntHelp, OverflowingLiteral, <del> OverflowingUInt, RangeEndpointOutOfRange, UnusedComparisons, VariantSizeDifferencesDiag, </del> <ins> OverflowingUInt, RangeEndpointOutOfRange, UnusedComparisons, UseInclusiveRange, VariantSizeDifferencesDiag, </ins> }, }; use crate::{LateContext, LateLintPass, LintContext};

Related discussion:
text: <!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. --I tried this code: I expected to see this happen: printing all numbers from 0 to 255 (inclusive) Instead, this happened: : <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
The error is correct, 256 is indeed out of range for u8. You need to use .
You can run that code if you want, by allowing the lint: if you do you'll see that it will print nothing because the overflows and becomes , so it's which is empty. Examples like this where allowing the literal overflow would do something you don't want are exactly why this lint is deny-by-default
I've renamed this issue because the lint is correct. If there's anything to be done here, it would be to add a range-specific suggestion for this situation to help guide towards the correct code.
claim
Code change:
<ins> `async fn`s are not yet supported in traits in Rust. Erroneous code example: ```compile_fail,edition2018 trait T { // Neither case is currently supported. async fn foo() {} async fn bar(&self) {} } ``` `async fn`s return an `impl Future`, making the following two examples equivalent: ```edition2018,ignore (example-of-desugaring-equivalence) async fn foo() -> User { unimplemented!() } // The async fn above gets desugared as follows: fn foo(&self) -> impl Future<Output = User> + '_ { unimplemented!() } ``` But when it comes to supporting this in traits, there are [a few implementation issues][async-is-hard]. One of them is returning `impl Trait` in traits is not supported, as it would require [Generic Associated Types] to be supported: ```edition2018,ignore (example-of-desugaring-equivalence) impl MyDatabase { async fn get_user(&self) -> User { unimplemented!() } } impl MyDatabase { fn get_user(&self) -> impl Future<Output = User> + '_ { unimplemented!() } } ``` Until these issues are resolved, you can use the [`async-trait` crate], allowing you to use `async fn` in traits by desugaring to "boxed futures" (`Pin<Box<dyn Future + Send + 'async>>`). Note that using these trait methods will result in a heap allocation per-function-call. This is not a significant cost for the vast majority of applications, but should be considered when deciding whether to use this functionality in the public API of a low-level function that is expected to be called millions of times a second. You might be interested in visiting the [async book] for further information. [`async-trait` crate]: https://crates.io/crates/async-trait [async-is-hard]: https://smallcultfollowing.com/babysteps/blog/2019/10/26/async-fn-in-traits-are-hard/ [Generic Associated Types]: https://github.com/rust-lang/rust/issues/44265 [async book]: https://rust-lang.github.io/async-book/07_workarounds/06_async_in_traits.html </ins>

Related discussion:
text: we currently emit We should tell people that trait functions are not possible , and possibly point them to . <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Created
Code change:
<ins> error: invalid const generic expression --> $DIR/issue-103143.rs:2:13 | LL |     x::<#[a]y::<z>> |             ^^^^^^ | help: expressions must be enclosed in braces to be used as const generic arguments | LL |     x::<#[a]{ y::<z> }> |             +        + error[E0425]: cannot find value `x` in this scope --> $DIR/issue-103143.rs:2:5 | LL |     x::<#[a]y::<z>> |     ^ not found in this scope error: aborting due to 2 previous errors For more information about this error, try `rustc --explain E0425`. </ins>

Related discussion:
text: Found with The attribute applies to The was initially lexed as part of a token This seems to be exactly the case described by the : <details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Do you have any suggestion for this case? The code path is going like this: Parser eat the first one of '' at here and set : fall pass at here: So this assertion is failed: The result is: and is true. Seems the assertion missed this scenario, do we need to add a TrailingToken::Gt ?
The assertion I wrote is overly conservative - it really just needs to check that we don't simultaneously break a token and 'really' capture a trailing token. Specifically, we only need to panic if we actually incremented in the match block. I think the simplest fix would be to add a variable, which gets set to in the parts of the block that increment . The assertion can then be changed to breaklasttoken
Code change:
} } <del> // Maybe add libLLVM.so to the lib-dir. It will only have been built if // LLVM tools are linked dynamically. // // We add this to both the libdir of the rustc binary itself (for it to load at // runtime) and also to the target directory so it can find it at link-time. // // Note: This function does no yet support Windows but we also don't support //       linking LLVM tools dynamically on Windows yet. pub fn maybe_install_llvm_dylib(builder: &Builder<'_>, target: Interned<String>, sysroot: &Path) { </del> <ins> /// Maybe add libLLVM.so to the given destination lib-dir. It will only have /// been built if LLVM tools are linked dynamically. /// /// Note: This function does not yet support Windows, but we also don't support ///       linking LLVM tools dynamically on Windows yet. fn maybe_install_llvm(builder: &Builder<'_>, target: Interned<String>, dst_libdir: &Path) { </ins> let src_libdir = builder.llvm_out(target).join("lib"); <del> let dst_libdir1 = sysroot.join("lib/rustlib").join(&*target).join("lib"); let dst_libdir2 = sysroot.join(builder.sysroot_libdir_relative(Compiler { stage: 1, host: target })); t!(fs::create_dir_all(&dst_libdir1)); t!(fs::create_dir_all(&dst_libdir2)); </del> if target.contains("apple-darwin") { let llvm_dylib_path = src_libdir.join("libLLVM.dylib"); if llvm_dylib_path.exists() { <del> builder.install(&llvm_dylib_path, &dst_libdir1, 0o644); builder.install(&llvm_dylib_path, &dst_libdir2, 0o644); </del> <ins> builder.install(&llvm_dylib_path, dst_libdir, 0o644); </ins> } return; }

Related discussion:
text: Like running the cross-compiled on a host without anything more than the component?
Hmm, I can't actually get cross-builds to work with . I this to : ... so it would pick that up from the sysroot. Trying to cross-compile i686, I get: I do have both i686 and x8664 builds of in the sysroot. I suspect the error is because the i686 build has different metadata than my host build, so it can't find the one it wants for the host. That may mean that is really tied to being used on the same host. It works if I just compile native x86_64 though. Then I tried removing the , and it gets essentially the same error as : AFAICS, building normal crates still works fine with that extra removed though. In short: Cross-compiling with seems broken -- maybe it should be shipped native-only. The only difference would be in the manifest created for rustup. Linking to crates will inherit , so that needs to be in the library path.
Ah, fascinating. What happens if you build such an executable and then remove the component entirely? Can it pick up the dylibs outside or does it hardcode the paths inside?
The final executable still isn't actually linked to LLVM, since it didn't need any of those symbols: I can run this with , which set , or even if I set that path myself. But doesn't work if we've removed that library, since needs itself.
Okay, it being dependent on makes sense. Overall, probably the safe thing to do would be to move the duplicate to , oh well.
Oh, also needs LLVM, and those binaries are installed in with RUNPATH . I guess they might be able to find the LLVM in anyway?
Code change:
} impl<'self> Writer for BufWriter<'self> { <del> fn write(&mut self, _buf: &[u8]) { fail!() } </del> <ins> fn write(&mut self, buf: &[u8]) { // raises a condition if the entire write does not fit in the buffer let max_size = self.buf.len(); if self.pos >= max_size || (self.pos + buf.len()) > max_size { io_error::cond.raise(IoError { kind: OtherIoError, desc: "Trying to write past end of buffer", detail: None }); return; } </ins> <del> fn flush(&mut self) { fail!() } </del> <ins> vec::bytes::copy_memory(self.buf.mut_slice_from(self.pos), buf, buf.len()); self.pos += buf.len(); } </ins> } <ins> // FIXME(#10432) </ins> impl<'self> Seek for BufWriter<'self> { <del> fn tell(&self) -> u64 { fail!() } </del> <ins> fn tell(&self) -> u64 { self.pos as u64 } </ins> <del> fn seek(&mut self, _pos: i64, _style: SeekStyle) { fail!() } </del> <ins> fn seek(&mut self, pos: i64, style: SeekStyle) { // compute offset as signed and clamp to prevent overflow let offset = match style { SeekSet => { 0 } SeekEnd => { self.buf.len() } SeekCur => { self.pos } } as i64; self.pos = max(0, offset+pos) as uint; } </ins> }

Related discussion:
text: Currently all of its functions immediately . We need to either remove this or implement it. I vote for implementing it.
Code change:
assert_eq!(copy(&mut r as &mut dyn Read, &mut w as &mut dyn Write).unwrap(), 1 << 17); } <ins> struct ShortReader { cap: usize, read_size: usize, observed_buffer: usize, } impl Read for ShortReader { fn read(&mut self, buf: &mut [u8]) -> Result<usize> { let bytes = min(self.cap, self.read_size); self.cap -= bytes; self.observed_buffer = max(self.observed_buffer, buf.len()); Ok(bytes) } } struct WriteObserver { observed_buffer: usize, } impl Write for WriteObserver { fn write(&mut self, buf: &[u8]) -> Result<usize> { self.observed_buffer = max(self.observed_buffer, buf.len()); Ok(buf.len()) } fn flush(&mut self) -> Result<()> { Ok(()) } } #[test] fn copy_specializes_bufwriter() { let cap = 117 * 1024; let buf_sz = 16 * 1024; let mut r = ShortReader { cap, observed_buffer: 0, read_size: 1337 }; let mut w = BufWriter::with_capacity(buf_sz, WriteObserver { observed_buffer: 0 }); assert_eq!( copy(&mut r, &mut w).unwrap(), cap as u64, "expected the whole capacity to be copied" ); assert_eq!(r.observed_buffer, buf_sz, "expected a large buffer to be provided to the reader"); assert!(w.get_mut().observed_buffer > DEFAULT_BUF_SIZE, "expected coalesced writes"); } </ins> #[test] fn sink_sinks() { let mut s = sink();

Related discussion:
text: When I built and ran the release version, the speed jumped to over 1 GB/s.
With merged you can now (on next nightly) use to control the chunk size of . Since this relies on specialization it only works if you pass a directly, any other wrapper around it would disable this optimization.
Code change:
<ins> #[macro_export] macro_rules! a{ () => {}} #[macro_export] macro_rules! b{ () => {}} </ins>

Related discussion:
text: Hey! Ran into what appears to be a bug - crate's exported macros each appear twice in the left sidebar: ! Toolchain versions (per log): rustc 1.60.0-nightly ( 2022-02-09), docsrs 0.6.0 ( 2022-02-01) Please let me know if I can provide additional info.
Thank you for the report! This is definitely not an issue with itself, but with rustdoc. is this known? Should a rustdoc issue be created?
Not known afaik. Please do file an issue (or transfer this one)!
Seems similar to
Thanks for transferring the issue. One difference between this and - both macros are exported using a wildcard in crate root (not rename):
Well, just another reexport issue. It's common around here. :laughing: I'll try to take a look in the next days.
This is what I have on currently nightly: ! So I guess it's fixed?
Trying locally with the latest nightly (, more current than that of issue open) I get the same initial landing page for but if I click on one of the macros listed (e.g. "drill down") duplicates still appear on the sidebar: ! So the tiny bug is still there, just deeper/hidden on the latest nightly?
Ah indeed! I can also reproduce it now. Will take another look tomorrow then.
Code change:
<ins> // Copyright 2015 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. fn f<F, R>(_: F) where F: Fn() -> R { } fn main() { f(|| -> ! { () }); //~^ ERROR: computation may converge in a function marked as diverging [E0270] } </ins>

Related discussion:
text: Minimised example: Both the and the fail in the same way, with an ICE: Adding bounds to and on the trait or in the fn’s where clause doesn’t fix it, but changing to does fix it. (In the particular case that I was dealing with, the lifetime could_ be changed to where this was a problem, but it would only have taken a slight variation of it for me to be in a situation where I needed a non- implementation. There were, of course, other arguments which were using the .) The whole thing around there seems a bit fragile and I’m not quite sure what’s supposed to work and what’s not; if we just take an and transmute it to , for example, we get “error: cannot transmute to or from a type that contains type parameters in its interior [E0139]”. Anyway, an ICE is always a bug, so here’s the report!
No longer repros. compiles now. Fails with: But no ICE.
Code change:
<ins> // Copyright 2015 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. fn f<F, R>(_: F) where F: Fn() -> R { } fn main() { f(|| -> ! { () }); //~^ ERROR: computation may converge in a function marked as diverging [E0270] } </ins>

Related discussion:
text: While trying to learn how to return a closure.... I came across this.. gives....
Commenting-out the body of still results in an ICE.
I can't seem to produce an ICE no matter what I do.
Those closure kinds info are already gone, so I think many related bugs are gone as well. e.g. I cannot reproduce a bug related to closure kinds and macro
Code change:
id: ast::NodeId, span: syntax_pos::Span, name: ast::Name, <del> node_type: &str) { </del> <ins> node_type: &str, participle: &str) { </ins> if !name.as_str().starts_with("_") { self.tcx .lint_node(lint::builtin::DEAD_CODE, id, span, <del> &format!("{} is never used: `{}`", node_type, name)); </del> <ins> &format!("{} is never {}: `{}`", node_type, participle, name)); </ins> } } }

Related discussion:
text: I was changing some code from integer constants to a proper enum and was greeted by the following warning: The warning sounded weird to me because I was pattern-matching on that damn variant in various places of the code; but I was pointed out to the fact that I wasn't actually creating that value. Maybe the warning should be rewritten to explicitly mention value creation? Cc
cc that looks like your thing
duplicate of
Yup! Closing in favor of that.
Code change:
[submodule "src/llvm-project"] path = src/llvm-project url = https://github.com/rust-lang/llvm-project.git <del> branch = rustc/17.0-2023-07-29 </del> <ins> branch = rustc/17.0-2023-09-19 </ins> shallow = true [submodule "src/doc/embedded-book"] path = src/doc/embedded-book

Related discussion:
text: Minimized from : This issue was introduced in the build, and so it is likely to be a result of the upgrade to LLVM 17 ().
I have bisected the LLVM pass to the pass on main. I'm trying to get a diff of before/after so I can start tracking down the exact location of the incorrect optimization.
The optimization transforms this switch lookup which appears to correspond to the : with only the calculation of and changing from: to: with the rest of the IR remaining unchanged. The transform of appears to be okay ( by 64 -by 6). The transform of introduces the issue because although the instruction is marked as , is equal to which is negative in the signed representation and so subtracting 128 does cause signed underflow.
The IR output from rustc without any optimization passes outputs is: Which appears correct to me. This suggests that the is being introduced in a later optimization pass. I'll continue bisecting when I get a chance.
Looks like this instruction is being generated by a pass that's run before the pass. Before : Which is correct. So the real errant pass is , it just doesn't cause incorrect x86 to be emitted until a later pass.
Looks like this issue is known and a fix is in progress upstream at
Code change:
#![allow(non_upper_case_globals)] <ins> use attributes; </ins> use intrinsics::{self, Intrinsic}; use llvm::{self, TypeKind}; use abi::{Abi, FnType, LlvmType, PassMode};

Related discussion:
text: and are both broken on s390x since Rust 1.28. When is built without debuginfo, the tests hang with their backtracing processes stuck in a loop. With debuginfo, it fails with output like: I believe the problem is this part of : where doesn't identify that is a 64-bit platform. See also alexcrichton/backtrace-rs. I plan to update that here when it's published, and make a similar fix in .
fixes the backtrace when is built with debuginfo, but I'm still getting a hang without. In GDB, it looks like the unwinder gets to the that catches panics, then loops unwinding that same PC forever. This part of the regression is older -- happens on 1.27.2 as well, but 1.26.2 is fine. Binaries from the older version don't appear to have a distinct symbol at all, but maybe that's just inlined differently. I'm bisecting for that hang now.
Bisecting pointed me at (cc which attributes to all functions. For s390x the base features actually include a removal, . But it doesn't look like the features are applied to the synthesized (), and as a result it doesn't get inlined anymore since it has more features (w/ ) than the callee. We probably should apply target-features to as well. I don't know why the non-inlined can't be unwound -- maybe we need to force ? By default GDB backtrace stops at crate , but tries to go further: Maybe Rust's could have a similar defensive check, at least.
Nice find Definitely makes sense to me, and this should be fixed up (at least the business) in
With , , and , I believe we have this fixed.
Code change:
// option. This file may not be copied, modified, or distributed // except according to those terms. <del> #![feature(globs)] </del> <ins> #![feature(globs, lang_items)] </ins> #![no_std] // makes debugging this test *a lot* easier (during resolve) <ins> #[lang = "sized"] pub trait Sized for Sized? {} </ins> // Test to make sure that private items imported through globs remain private // when  they're used.

Related discussion:
text: The following code causes an ICE: Removing the parameter or changing it to be a value instead of a reference stops the crash with an error saying I need to specify a lifetime, which makes me think this is a problem related to inferred lifetimes.
It isn't, you just have to specify a lifetime: ICE-s as well. Returning an unsized type should be a typeck error.
happens to work because it implies , i.e. would also work.
Code change:
<ins> error: unterminated double quote string --> $DIR/test-compile-fail3.rs:3:1 | 3 | "fail | ^^^^^^ error: aborting due to previous error </ins>

Related discussion:
text: I have a no_std crate that imports std when testing: However, I get this error during testing: Allocating on the heap during testing does appear to work, so I'm assuming this is just a case of the warning still being emitted.
I have the same issue. Any update?
builds the crate both as a library (for doctests) and as a test executable. You only pull in std for the test executable, so the error message could be coming from building as a library.
I have the same issue, error message seems to be spurious
Yeah, the error message is emitted when building the library. Funnily enough, it does not cause the build to fail. That is, still continues running and then exits with success (0). Sadly, there is currently no way to link in a default allocator (or for that matter) for doctests. There is the unstable feature that provides , but I don't see how to achieve something similar without relying on unstable features. I simply use until this is fixed.
Related:
modify labels: +T-rustdoc
Error: Parsing label command in failed: labels +T-rustdo... Please let know if you're having trouble with this bot.
If you don't put inside the doctest it will be linked against even when testing a crate, you can think of each doctest as a separate crate. If you do want a different allocator you can add a static like in a normal binary. Even though this error message is printed the doc tests should still be running.
Also see the error is basically spurious.
Code change:
<ins> error: unterminated double quote string --> $DIR/test-compile-fail3.rs:3:1 | 3 | "fail | ^^^^^^ error: aborting due to previous error </ins>

Related discussion:
text: I noticed this in the output running locally: and that didn't make tests fail. Cc:
Same with panic_unwind:
This error message is printed when running , but before running any test. The code printing it is in . It looks like rustdoc is using that code in order to load the crate and find doctests in it. But since it’s not actually compiling this crate, not having an allocator is not a problem. So I think there are two issues: rustdoc keeps doing its thing even though there are errors. It probably should call something like on its instance at some point. This error should not occur in the first place. One way to inhibit it would be to tell that we’re "compiling" an rlib () rather than some other crate type. rlibs do not need (yet) to have an allocator defined. This is possibly this line: The first issue could in some other situation hide a real problem, but in this case it makes the second one mostly harmless. The only bad consequence is some noise in the output of a test run.
Related:
modify labels: +T-rustdoc
Error: Parsing label command in failed: labels +T-rustdo... Please let know if you're having trouble with this bot.