jiebi/CodeConvo huggingface dataset:
Change:
<ins> // ICE argument to function with "rust-call" ABI is not a tuple // issue: rust-lang/rust#81974 #![feature(unboxed_closures)] #![feature(fn_traits)] use std::collections::HashMap; use std::hash::Hash; struct CachedFun<A, B> { cache: HashMap<A, B>, fun: fn(&mut CachedFun<A, B>, A) -> B, } impl<A: Eq + Hash, B> CachedFun<A, B> { fn new(fun: fn(&mut Self, A) -> B) -> Self { CachedFun { cache: HashMap::new(), fun, } } } impl<A, B> FnOnce<A> for CachedFun<A, B> //~^ ERROR type parameter to bare `FnOnce` trait must be a tuple where A: Eq + Hash + Clone, B: Clone, { type Output = B; extern "rust-call" fn call_once(mut self, a: A) -> Self::Output { //~^ ERROR functions with the "rust-call" ABI must take a single non-self tuple argument self.call_mut(a) //~^ ERROR `A` is not a tuple } } impl<A, B> FnMut<A> for CachedFun<A, B> //~^ ERROR type parameter to bare `FnMut` trait must be a tuple where A: Eq + Hash + Clone, B: Clone, { extern "rust-call" fn call_mut(&mut self, a: A) -> Self::Output { //~^ ERROR functions with the "rust-call" ABI must take a single non-self tuple argument self.cache.get(&a).map(|a| a.clone()).unwrap_or_else(|| { let b = (self.fun)(self, a.clone()); self.cache.insert(a, b.clone()); b }) } } fn main() -> () { let pesce = |y: &mut CachedFun<i32, i32>, x| x + 1; let cachedcoso = CachedFun::new(pesce); cachedcoso.call_once(1); //~^ ERROR `i32` is not a tuple } </ins>

Discussion:
: Same in 1.52.0-nightly, same in 1.51.0. : <details<summary<strongBacktrace</strong</summary<p</p</detailsGood luck! <3
This happens on top of too much code for me to take the time to minimalize this issue, sorry. Though I'll try to file the fixing patch.
Wait! I made it! This issue revolves around L.31. Comment to see the ice go away. Interestingly, comment L.40 (or the whole impl L.37-45) to see ice go away as well. Commenting L.47-56 does not make ice go away. Commenting L.13-22 should raise another error (as L.31 is supposed to go there), but doesn't. Actually, the real fix is to replace L.31 with: Have fun!
Minimized with , then a bit by hand: <details<summaryDetails</summary<pIcemelter version: v0.2.0 label +S-bug-has-mcve </p</details
fixed by . we previously used to eagerly error but did not consider them as part of the cache key. So using a cache key from an evaluation with different can result in buggy behavior
Change:
} #[derive(Diagnostic)] <ins> #[diag(mir_build_literal_in_range_out_of_bounds)] pub struct LiteralOutOfRange<'tcx> { #[primary_span] #[label] pub span: Span, pub ty: Ty<'tcx>, pub max: u128, } #[derive(Diagnostic)] </ins> #[diag(mir_build_lower_range_bound_must_be_less_than_upper, code = "E0579")] pub struct LowerRangeBoundMustBeLessThanUpper { #[primary_span]

Discussion:
For a match where I'm matching on a , I put on accident, and then rather than saying that 256 is out of range for , it decided to wrap 256 to 0 and then error that 251 is lower than the end of the range: Clearly this is not a good situation. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I'd like to fix this claim
Triage: I'm going to release assignment due to inactivity. If you're still interested in this, feel free to re-claim. release-assignment
Explanation on how to solve this in
Change:
let lo = self.prev_token.span; let cond = self.parse_cond_expr()?; <ins> self.parse_if_after_cond(attrs, lo, cond) } fn parse_if_after_cond( &mut self, attrs: AttrVec, lo: Span, cond: P<Expr>, ) -> PResult<'a, P<Expr>> { </ins> let missing_then_block_binop_span = || { match cond.kind { ExprKind::Binary(Spanned { span: binop_span, .. }, _, ref right)

Discussion:
The error here is if is missing in else if but compiler reports: error:
already points out at the place where the should be, even if it doesn't suggest it:
: I still wish the parser to detect that the code immediately following is a binary operation followed by a block, so that we can instead emit
CC in case you might be interested in looking at the parser :)
this seems like a neat fix, i'll take a stab at it
Change:
} pub fn is_block_doc_comment(s: &str) -> bool { <del> let res = (s.starts_with("/**") && *s.as_bytes().get(3).unwrap_or(&b' ') != b'*') || s.starts_with("/*!"); </del> <ins> let res = ((s.starts_with("/**") && *s.as_bytes().get(3).unwrap_or(&b' ') != b'*') || s.starts_with("/*!")) && s.len() >= 5; // Prevent `/**/` from being parsed as a doc comment </ins> debug!("is {:?} a doc comment? {}", s, res); res }

Discussion:
Output: Doesn't occur if the comment isn't empty.
Actually, that's being parsed as a doc comment (which you can see if you remove the macro invocation). This looks like a parsing bug of some kind.
Change:
<ins> #![feature(type_alias_impl_trait)] #![deny(improper_ctypes)] pub trait Baz { } impl Baz for u32 { } type Qux = impl Baz; pub trait Foo { type Assoc; } impl Foo for u32 { type Assoc = Qux; } fn assign() -> Qux { 1 } extern "C" { pub fn lint_me() -> <u32 as Foo>::Assoc; //~ ERROR: uses type `impl Baz` } fn main() {} </ins>

Discussion:
cc Gives the following incorrect warning:
I'm not sure if this is incorrect - I think this is what I'd expect. In the declaration of , we don't know what concrete type is - if it were , then we could normalize to - but we don't know? Maybe I'm missing something.
Hmm, that might be true. I definitely think that the following should not lint here (with bound to u32)
I agree that seems like it should be fine. So, this happens because of this call: It makes sense that we want to lint on opaque types on extern declarations, it's unclear whether we would want to allow projections which contain opaque types - this would solve the case you've shown here, but could be used to "sneak" opaque types by the lint (in , the projection normalizes to an opaque type; it's hard to detect because the normalization goes further and resolves it to so we can't tell that it was an opaque type) - I have a build with this locally. Any thoughts on whether we should change the behavior here? cc
Hm, I think it might be worth it to normalize using here, which should not normalize the first case and your example while fixing the second one if I am not mistaken.
Long ago I filed where we also concluded Reveal::UserFacing is the right behavior for normalization in this lint. The current behavior comes from cc
I'll put up a PR with my experiments from last night later in that case.
Change:
<ins> error[E0515]: cannot return value referencing function parameter `y` --> $DIR/issue-81584.rs:5:22 | LL |             .map(|y| y.iter().map(|x| x + 1)) |                      -^^^^^^^^^^^^^^^^^^^^^^ |                      | |                      returns a value referencing data owned by the current function |                      `y` is borrowed here | = help: use `.collect()` to allocate the iterator error: aborting due to previous error For more information about this error, try `rustc --explain E0515`. </ins>

Discussion:
Given a situation where an iterator is : We should suggest using in these cases. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Or flatten/flat_map?
I want for us to detect cases of trying to operate on iterators of iterators because the only option then is to allocate or completely rework the logic. The former will help newcomers, experts will know enough to try the later.
claim
Couldn't we still recommend both? Recommending bad practices seems suboptimal.
Change:
<ins> #![feature(allocator_api)] #![feature(const_trait_impl)] use core::convert::{From, TryFrom}; //~^ ERROR //~| ERROR use std::pin::Pin; use std::alloc::Allocator; impl<T: ?Sized, A: Allocator> const From<Box<T, A>> for Pin<Box<T, A>> where A: 'static, {} pub fn main() {} </ins>

Discussion:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --code from <!-- 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. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
couple of files from the repo that reproduce this: ./src/test/ui/rfc-2632-const-trait-impl/staged-
This regressed in cc
Thanks for the bisection. This should be a simple fix: Replace with And add a test as well :) label E-easy
claim
Are you still working on this? If not, I would like to fix this as soon as possible.
Sorry for the delay, no problem. Thanks.
Change:
pub UNKNOWN_OR_MALFORMED_DIAGNOSTIC_ATTRIBUTES, Warn, "unrecognized or malformed diagnostic attribute", <del> @feature_gate = sym::diagnostic_namespace; </del> } declare_lint! {

Discussion:
When compiling my feature and is included I got the attached ICE. The following is the unstable configuration is the repository this occurs on. I will get a minimal verifiable example setup shortly. <details<summaryBacktrace</summary<p</p</details
Here is the full ICE output:
Turns out I was missing in my deny list. Not sure if that should be an ICE or not, feel free to close if that is expected behavior. This wasn't a fix, the behavior still happened.
Does this specifically only happen with clippy, or does this ICE also happen with a regular /? The backtrace and the fact that these are all rustc lints/features makes me think it's a bug in the compiler
and both produce the same ICE.
Moving to rust-lang/rust in that case, since it sounds like fixing this requires changes in the compiler and we can't do much about that on the clippy side
From what I can tell, MCVE is or, alternatively,
searched nightlies: from nightly-2024-01-01 to nightly-2024-03-12 regressed nightly: nightly-2024-03-09 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.8</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </detailsProbably , cc
I filled to address this
Change:
"fmt" => Subcommand::Format { check: matches.opt_present("check") }, "dist" => Subcommand::Dist { paths }, "install" => Subcommand::Install { paths }, <del> "run" => { </del> <ins> "run" | "r" => { </ins> if paths.is_empty() { println!("nrun requires at least a path!n"); usage(1, &opts, &subcommand_help, &extra_help);

Discussion:
currently supports , and a few others even though not so discoverable (). It would be good to let supports the aliases supported by , such as , and such. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Change:
fn as_inner(&self) -> &imp::ExitStatus { &self.0 } } <ins> impl FromInner<imp::ExitStatus> for ExitStatus { fn from_inner(s: imp::ExitStatus) -> ExitStatus { ExitStatus(s) } } </ins> #[stable(feature = "process", since = "1.0.0")] impl fmt::Display for ExitStatus { fn fmt(&self, f: &mut fmt::Formatter) -> fmt::Result {

Discussion:
Because has a private field it is impossible to create one in user code, one must actually execute a process. This prevents testing/mocking. My use case is that I have some function which runs a process and generates data, however, for testing I want to mock the test run and just return a success exit status and some data. I can't do that because I can't create my own objects. At the least there should be a way to create a success . Preferably, there would be a way to create various fail statuses too.
Should the constructor just take an ?
I've also wanted a basically "raw constructor" in the past. I'd be fine adding some extensions which allow construction from a or ( and )
+1 I’d like to extend , but I cannot reuse for return value because I can’t construct . :(
I've opened a PR for this over at
Great, thanks! :+1:
This would help n00bs like me who start out by copying the example code and tweaking it: This example is a special case that only happens to work if the contains a or something else that immediately exits. Otherwise you need to create your own struct to return which is currently impossible.
This issue is now entering a cycle-long final comment period for stabilization
Discussed recently, the libs team decided to stabilize.
Change:
# enable warnings during the llvm compilation enable-warnings = true # build llvm from source <del> download-ci-llvm = false </del> <ins> download-ci-llvm = "if-unchanged" </ins> [rust] # This enables `RUSTC_LOG=debug`, avoiding confusing situations

Discussion:
The profile is intended not just for people working on LLVM itself, but also anyone who touches codegen but not LLVM. For example, anyone who modifies or is only changing the IR we send to LLVM, not LLVM itself. We should keep on for them but not for , but ideally we wouldn't build LLVM from source if it's unmodified. points out some things that we should fix before enabling that option by default for the profile: Originally posted by in <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim Should all 3 tasks be in one PR or is it 3 separate PR's?
I'd say it depends how challenging they are - if it's simple to fix all three in one PR that seems fine, but if it takes a more than a day to do one of the tasks, it probably makes sense to open a PR for it early.
I think I can tackle points 1 and 3 by tonight so I'll make that into one PR. I'll open a separate PR for the second point, since I think it has more work involved, if that's alright :)
release-assignment
Change:
use rustc_middle::ty::fold::TypeFolder; use rustc_middle::ty::subst::InternalSubsts; use rustc_middle::ty::{self, AdtKind, Lift, Ty, TyCtxt}; <del> use rustc_mir::const_eval::is_min_const_fn; </del> <ins> use rustc_mir::const_eval::{is_const_fn, is_min_const_fn, is_unstable_const_fn}; </ins> use rustc_span::hygiene::MacroKind; use rustc_span::symbol::{kw, sym, Ident, Symbol}; use rustc_span::{self, Pos};

Discussion:
This is a follow-up on I opened earlier, with the requested minimal reproduction in the form of a simple .
Looks like this is either or cc - do you know what those are doing/why they exist?
It's because of the feature. As long as it's not stable, they don't want the keyword to be displayed, even if the function description is describing a const fn. This is a bit strange.
Yeah, that makes no sense to me at all. I have a crate that is very much nightly-only containing a rather large number of s, and at the moment literally none of them are displayed as such in my documentation because of this, despite the fact that they've never not been and will never not be in the future. I of course cannot disable the flag either as then the crate won't compile, as much of what I'm doing does not fit into the stabilized set of functionality. At the very least, surely there must be some way to make it possible to specifically tell rustdoc to "please always document s as exactly what they are no matter what" without changing this default behaviour if that's not desired?
I think the metric should be 'does this have , not 'is this a function'.
I wonder if this isn't an artifact of the switch when adding support... But in any case, it should be a check over , you're absolutely right.
I wonder if this ever worked ... do you mind trying this with an old version of rustdoc? Preferably before was implemented: cc
I'll try that on my crate later today.
After testing both the example I gave here and my own crate with various nightlies from before was implemented, I can confirm that this problem definitely pre-dates it. There's no difference in how rustdoc behaved.
(apologies to lcnr for the ping)
If this helps at all, whichever version of rustdoc was using on August 1st did document my crate properly, it seems. Only the very latest version, uploaded on September 5th, was documented with the keyword missing. So it's a fairly recent bug, overall.
Ok, so I think I was reading the dates on the PRs a bit wrong when I tested yesterday as far as the timeframe for when was merged.

I just did a whole bunch more one-by-one testing of nightlies from August, and in fact the problem doesn't quite predate which was merged on August 7th. Specifically, the very last nightly to have a rustdoc that documents correctly is . Switching directly from that to from the next day makes the problem appear.
consider using instead which will do it automatically
Well, I already know it's a commit from between the 10th and 11th of August now, at least. Also, doesn't really seem to be designed for scenarios where identifying the problem specifically requires running on a crate and then visually inspecting the generated HTML files...
Change:
impl<A: Unsigned, B: Unsigned> Unsigned for Sum<A,B> { const MAX: u8 = A::MAX + B::MAX; //~ ERROR any use of this value will cause an error <del> //~| ERROR any use of this value will cause an error </del> } fn foo<T>(_: T) -> &'static u8 {

Discussion:
See https://travis- for failed build
Could you please provide a backtrace for the ICE?
cc
cc more const prop fallout?
Seems likely. I'll have some time tonight to look at it.
Minimal repro:
Cc me
Change:
<ins> // See https://github.com/rust-lang/rust/pull/67911#issuecomment-576023915 fn f<'a, 'b>(x: i32) -> (&'a i32, &'b i32) { let y = &x; (y, y) //~ ERROR cannot return } fn main() {} </ins>

Discussion:
This code: Returns this error: Which is very unhelpful; it should at least in some way point to the line with the . This happens on rustc 1.40.0 ( 2019-12-16). For reference, this is the equivalent non-async error message (much more helpful): <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Marking as focus, since improving diagnostics are important to the wg.
Change:
// when the unstable no_global_oom_handling feature is turned on. // See https://github.com/rust-lang/rust/pull/84266 <del> use run_make_support::rustc; </del> <ins> use run_make_support::{rustc, source_root}; </ins> fn main() { rustc() .edition("2021") .arg("-Dwarnings") .crate_type("rlib") <del> .input("../../../library/alloc/src/lib.rs") </del> <ins> .input(source_root().join("library/alloc/src/lib.rs")) </ins> .cfg("no_global_oom_handling") .run(); }

Discussion:
Some run-make tests refer to stdlib sources with which seems not ideal. suggested that we should introduce a helper to make this less fragile.
There is already the env var set by compiletest for the source root.
I'm actually dumb, we even already have in the support library:
That's a very descriptive environment variable name, lol
Change:
<ins> // edition:2021 async fn foo() -> Result<(), String> { Ok(()) } fn convert_result<T, E>(r: Result<T, E>) -> Option<T> { None } fn main() -> Option<()> { //~^ ERROR `main` has invalid return type `Option<()>` convert_result(foo()) //~^ ERROR mismatched types } </ins>

Discussion:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --Still working out how to get rid of this and find a minimal replicating code example. The backtrace however, contains some useful information like "index out of bounds", for those who knows the implementation of the compiler. I guess it should be a good clue to find out what makes it wrong. <!-- 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. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Can you check if this is fixed on nightly?
Running the nightly channel on the same code reports a type error that linked to a change I made in the code that making a function returning to an but forgot to change the calling site to use .
Ok, according the clue above I found a minimal code example The above code should not compile; but instead of reporting errors it crashes the compiler. Seems only affects the stable channel; beta and nightly are working properly. (The example code can be rewritten as or something like that and it will report the error correctly; however the real code was converting to instead of so it does not help)
So this is fixed by -- unfortunately that's going to land in the next release cycle (1.65) and this isn't a critical enough ICE to warrant a patch release for 1.64
can we add the repro to the test suite and close the ticket then?
claim To add the test if it's not already done.
Please do!
Change:
#[rustc_const_unstable(feature="foo", issue = "none")] pub const unsafe fn foo() -> u32 { 42 } <del> // @has 'foo/fn.foo2.html' '//pre' 'pub fn foo2() -> u32' </del> <ins> // @has 'foo/fn.foo2.html' '//pre' 'pub const fn foo2() -> u32' </ins> #[unstable(feature = "humans", issue = "none")] pub const fn foo2() -> u32 { 42 }

Discussion:
This is a follow-up on I opened earlier, with the requested minimal reproduction in the form of a simple .
Looks like this is either or cc - do you know what those are doing/why they exist?
It's because of the feature. As long as it's not stable, they don't want the keyword to be displayed, even if the function description is describing a const fn. This is a bit strange.
Yeah, that makes no sense to me at all. I have a crate that is very much nightly-only containing a rather large number of s, and at the moment literally none of them are displayed as such in my documentation because of this, despite the fact that they've never not been and will never not be in the future. I of course cannot disable the flag either as then the crate won't compile, as much of what I'm doing does not fit into the stabilized set of functionality. At the very least, surely there must be some way to make it possible to specifically tell rustdoc to "please always document s as exactly what they are no matter what" without changing this default behaviour if that's not desired?
I think the metric should be 'does this have , not 'is this a function'.
I wonder if this isn't an artifact of the switch when adding support... But in any case, it should be a check over , you're absolutely right.
I wonder if this ever worked ... do you mind trying this with an old version of rustdoc? Preferably before was implemented: cc
I'll try that on my crate later today.
After testing both the example I gave here and my own crate with various nightlies from before was implemented, I can confirm that this problem definitely pre-dates it. There's no difference in how rustdoc behaved.
(apologies to lcnr for the ping)
If this helps at all, whichever version of rustdoc was using on August 1st did document my crate properly, it seems. Only the very latest version, uploaded on September 5th, was documented with the keyword missing. So it's a fairly recent bug, overall.
Ok, so I think I was reading the dates on the PRs a bit wrong when I tested yesterday as far as the timeframe for when was merged.

I just did a whole bunch more one-by-one testing of nightlies from August, and in fact the problem doesn't quite predate which was merged on August 7th. Specifically, the very last nightly to have a rustdoc that documents correctly is . Switching directly from that to from the next day makes the problem appear.
consider using instead which will do it automatically
Well, I already know it's a commit from between the 10th and 11th of August now, at least. Also, doesn't really seem to be designed for scenarios where identifying the problem specifically requires running on a crate and then visually inspecting the generated HTML files...