jiebi/CodeConvo huggingface dataset:
Change:
<ins> // issue: 113314 #![feature(type_alias_impl_trait)] type Op = impl std::fmt::Display; fn foo() -> Op { &"hello world" } fn transform<S>() -> impl std::fmt::Display { &0usize } fn bad() -> Op { transform::<Op>() //~^ ERROR concrete type differs from previous defining opaque type use } fn main() { let mut x = foo(); println!("{x}"); x = bad(); println!("{x}"); } </ins>

Discussion:
<!-- 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: compile error that said the return type is wrong. Instead, this happened: compiled without error <!-- 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. --:
cc

edit: minimized see for more details <!-- 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: Compilation should fail, because different generator types should be generated by calling , meaning and should not share the same type . Instead, compilation passes, and occurs during runtime: More context: <!-- 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<summaryNo Backtrace from running it</summary<p</p</details
label +F-typealiasimpl_trait +I-unsound +T-compiler
Only possible with unstable feature label -I-prioritize
it would be good to have an example which does not depend on external crates or macros here.
slightly minimized completely minimized: + incorrectly ignoring recursive definitions, writing a clean MVCE rn
constrains to , which gets ignored because of I am not totally sure how this all interacts, would have to look at the code, but it feels like the same root cause as
Change:
} } <ins> #[derive(Debug)] </ins> enum TargetLocation { ThisFile(PathBuf), ThisDirectory(PathBuf),

Discussion:
Doctest test names have changed due to . Doc comments that pass through a macro defined in another crate now seem to report a different span. /// assert!(true); /// running with previously looked like this: Now the test names look like this: Frankly, neither are particularly great. It would be nice if the test name used the span from where the macro was invoked, not where it was defined.
I think this also affects normal backtraces :( Just got this rather unuseful backtrace while bootstrapping: full:
cc
What you're describing is entirely in the opposite direction, is the old (and arguably bad) kind of that's impossible to get anymore. I've hidden your comment to focus on the reported issue.
That makes sense, we have a way to get the outermost invocation, that is used by / and : We'd just need to use this in .
cc
cc
Removed label, left nomination for to decide about this issue.
Well, using what suggested seems like the best thing to do.
Change:
let path = Path::new(submodule); // Don't update the submodule unless it's already been cloned. if GitInfo::new(false, path).is_managed_git_subrepository() { <del> self.update_submodule(submodule); </del> <ins> self.config.update_submodule(submodule); </ins> } } }

Discussion:
<!-- 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: in is not specified explicitly, the default value is used. I expected to see this happen: LLVM is downloaded from CI, when LLVM version is bumped the new LLVM is downloaded from CI as well. Instead, this happened: LLVM starts building from source code after an LLVM update, instead of being downloaded, unless I remove the build directory and do a fresh build, then it starts downloading from CI again. <!-- 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. --:
Or maybe it's a stage0 toolchain update that triggers this issue, not LLVM update (I observed this today). But I've seen this issue several times in the past as well. cc
The section in is completely empty, nothing is overridden.
Update: LLVM is built from source only on the first build attempt, after that it is correctly downloaded from CI.
This is still an issue that I observe regularly.
There were some issues with the change detection logic for LLVM and I think should fix it. Let's see if it still happens with the next LLVM update.
Change:
<del> // Copyright 2018 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. // run-rustfix #![allow(dead_code)] fn missing_discourses() -> Result<isize, ()> { Ok(1) } fn forbidden_narratives() -> Result<isize, ()> { Ok(missing_discourses()?) //~^ ERROR try expression alternatives have incompatible types //~| HELP try wrapping with a success variant } fn main() {} </del>

Discussion:
Reproduced on versions: - Isolated example to reproduce: Actual error: Mentioned suggestion about "wrap into " is incorrect at all. There we should deref the value from the . - - Expected error: (something like this)
Here's where the suggestion gets issued: The motivation was to solve (where a -expression appears in tail position, which seemed likely to be a common mistake), but it turns out that there are other situations where we run into a type mismatch between match arms of a desugared expression. We regret the error.
Here's another case of this:
I see what's happening, we're only checking wether the error came from a desugaring, disregarding the types involved. It should be possible to check that information as well, even if the suggestion is only provided when it's a where everything but the error type matches. (I think it's ok if the supplied error cannot be converted to the expected error, as this suggestion exposes newcomers to a non-obvious construct at least.)
Clippy to detect this that we might want to uplift ...
(But for now I'm just going to remove the suggestion.)
Change:
err.span_label(ident.span, "while parsing this `fn`"); err.emit(); } else { <ins> // check for typo'd Fn* trait bounds such as // fn foo<F>() where F: FnOnce -> () {} if self.token.kind == token::RArrow { let machine_applicable = [sym::FnOnce, sym::FnMut, sym::Fn] .into_iter() .any(|s| self.prev_token.is_ident_named(s)); err.subdiagnostic(errors::FnTraitMissingParen { span: self.prev_token.span, machine_applicable, }); } </ins> return Err(err); } }

Discussion:
It feels like rustc should be able to determine that a trait followed by a is a -family trait bound and be able to suggest this behavior. If that is too general it could just check for , , . Very similar is if parenthesis are missing from regular declarations: Also happens on nightly according to Rust Playground. I'd like to try my hand at implementing this diagnostic, but I'll likely need a little bit of locational guidance. A naive code search show that the message is emitted by this code is the parser diagnostics, but I'm not sure if the adjustment would need to be made within that or from where it is invoked in this case. Edit: Updated to use the wording "-family trait bounds" rather than "HRTBs"._
Where this function is invoked. Try looking for the code that parses .
If you end up writing a fix, note that those trait bounds are usually called -family trait bounds, not “HRTBs”. The latter would require at least one higher-rank parameter to be involved (e.g. ).
It seems this diagnostic contextually comes from which does this token search by . As corroboration it also seems that declaring a regular without parenthesis causes a similar if more contextually understandable error: I naively think that the adjustment point should probably be rather than ... However I don't understand how the output gets multiple possibilities e.g. and in this output: or the whole list of Since it's only calling with from ... I guess this requires catching the result in and handling this result type somehow?
Any time you call , it stashes the token type you tried probing for and it'll present that in a list whenever you get to . (Or something like that).
Anyways, it shouldn't matter -- in the caller to (when parsing ), you could add a check for before calling and handle the token specifically.
Just chiming in to mention: in any parser change you make here make sure you don't start accepting new code and add tests for all combinations you can think of.
Change:
repro() } } <ins> #[test] fn drop_unreceived() { let (tx, rx) = sync_channel::<Rc<()>>(1); let msg = Rc::new(()); let weak = Rc::downgrade(&msg); assert!(tx.send(msg).is_ok()); drop(rx); // Messages should be dropped immediately when the last receiver is destroyed. assert!(weak.upgrade().is_none()); drop(tx); } </ins>

Discussion:
<!-- Thank you for filing a regression report! A regression is something that changed between versions of Rust but was not supposed to. Please provide a short summary of the regression, along with any information you feel is relevant to replicate it. --I tried this code: I expected to see this happen: I expected to see the struct in the Sender buffer get dropped after the Receiver is dropped during the unwind of the panicking thread. Instead, this happened: The data in the Sender buffer is not dropped until the whole process ends. <!-- Provide the most recent version this worked on, for example: It most recently worked on: Rust 1.47 --It most recently worked on: 1.66.1 <!-- Provide the version you are using that has the regression. --: <!-- Did the compiler crash? If so, please provide a backtrace. --</p</details<!-- If you know when this regression occurred, please add a line like below, replacing with one of stable, beta, or nightly. modify labels: +regression-from-stable-to-{channel} -regression-untriaged --
bisection seems to point to cc searched nightlies: from nightly-2022-11-01 to nightly-2023-02-01 regressed nightly: nightly-2022-11-14 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.5</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with:
In crossbeam, the unbounded channel does this (), but the bounded channel does not. There is no particular intent, it just hasn't been implemented. cc
Change:
|| self.get_uid().is_some() || (self.env_saw_path() && !self.program_is_path()) || !self.get_closures().is_empty() <ins> || self.get_groups().is_some() </ins> { return Ok(None); }

Discussion:
already offers and methods to control the user identity of the child process (calling respectively). For complete control of Unix credentials, there should also be a way to call and the concept of the supplementary group list are; I would expect this not to be a portability concern.) This feature would eliminate a use of and an unsafe block (to call ) from the program I'm currently writing, which is a port to Rust of a setuid C program. For illustration, this function exists in the C version: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
I would be prepared to consider a PR to add .
claim
Change:
<ins> // compile-flags:-Ztranslate-lang=en_US #![feature(negative_impls)] #![feature(marker_trait_attr)] #[marker] trait MyTrait {} struct TestType<T>(::std::marker::PhantomData<T>); unsafe impl<T: MyTrait + 'static> Send for TestType<T> {} impl<T: MyTrait> !Send for TestType<T> {} //~ ERROR found both positive and negative implementation unsafe impl<T: 'static> Send for TestType<T> {} //~ ERROR conflicting implementations impl !Send for TestType<i32> {} 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. --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
<!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
claim
After doing some more investigation, this also happens on a crate with only the empty crate: and like the original error, and are all used in manual implementations.
There are a bunch of these triggering in various lints it seems, so I wonder if the assert might actually not be thaaat justified?
changed that when a message is not in the primary bundle and debugassertions are on, it ices. So, for example, if you are using a half translated French bundle with messages missing, and have debugassertions on, you'll probably ice a lot. I agree that that in hindsight might have been a bad idea, and we should back that out ...however we don't actually have any other bundles, so I have no idea how this can trigger. I did some more debugging today, and it looks like the primary bundle never has any messages, so it should only trigger if the message requires formatting. I have no idea why that is or why it only happens if you have a rustc built with debug_assertions, rather than during tests for example. The only thing I can come up with is that between invoking rustc and running tests the bundle is created differently.
Change:
<ins> //compile-pass fn main() { let s = &[0x00; 4][..]; //Slice of any value const MAGIC_TEST: &[u8] = b"TEST"; //Const slice to pattern match with match s { MAGIC_TEST => (), [0x00, 0x00, 0x00, 0x00] => (), [84, 69, 83, 84] => (), // this should warn _ => (), } match s { [0x00, 0x00, 0x00, 0x00] => (), MAGIC_TEST => (), [84, 69, 83, 84] => (), // this should warn _ => (), } match s { [0x00, 0x00, 0x00, 0x00] => (), [84, 69, 83, 84] => (), MAGIC_TEST => (), // this should warn _ => (), } } </ins>

Discussion:
Attempting to pattern match a slice with a constant value and THEN a slice literal causes an ICE. Simple test case: However simply changing the order to test the slice literal and then the const slice compiles fine: Error message: rustc version:
So... I do have a fix for byte slices, but that just exposed that we have the same ICE for other slices: This can be fixed, too, but I need to wait for to be merged before being able to do this in a reasonable way.
Change:
let mut by_move_body = body.clone(); MakeByMoveBody { tcx, by_ref_fields, by_move_coroutine_ty }.visit_body(&mut by_move_body); dump_mir(tcx, false, "coroutine_by_move", &0, &by_move_body, |_, _| Ok(())); <del> by_move_body.source = mir::MirSource { instance: InstanceDef::CoroutineKindShim { coroutine_def_id: coroutine_def_id.to_def_id(), }, promoted: None, }; </del> <ins> by_move_body.source = mir::MirSource::from_instance(InstanceDef::CoroutineKindShim { coroutine_def_id: coroutine_def_id.to_def_id(), }); </ins> body.coroutine.as_mut().unwrap().by_move_body = Some(by_move_body); } }

Discussion:
on commit If you don't set a you will OOM while optimizing syn with these very silly flags. I also have another example of this that produces a "but found ConstICE. They look similar, I'll post the other one later if someone wants.
I've been able to minimize to this:
Here is a further minimized -only repro: The came out of the innards of . The use of is not critical, but the use of a type with both a lifetime and a type generic is; for example, will do too. Tested with the above RUSTFLAGS, under . T/ <details<summaryBacktrace</summary</details
Change:
# If this file is modified, then llvm will be forcibly cleaned and then rebuilt. # The actual contents of this file do not matter, but to trigger a change on the # build bots then the contents should be changed so git updates the mtime. <del> 2016-08-17 </del> <ins> 2016-08-23 </ins>

Discussion:
rustup reports of 0.6.1 crashes: These were built with rustup 0.6.0 crashed on OS X 10.10+. Fixed with a strategic That was built with Reducing these has been very difficult and I have nothing for them right now. cc
Do you know of a nightly which doesn't result in crashes?
looking for one now.
rust- looks like the exact same issue AFAICT.
from 2016-08-18 is the first nightly that miscompiles. Curiously this is also the first 1.13 nightly. Unfortunately the bug is on beta too. reproducing: commit nightly results: 2016-08-10, rustc 1.12.0-nightly ( 2016-08-09) - good 2016-08-16, rustc 1.12.0-nightly ( 2016-08-15) - build error 2016-08-17, rustc 1.12.0-nightly ( 2016-08-16) - build error 2016-08-18, rustc 1.13.0-nightly ( 2016-08-17) - bad 2016-08-22, rustc 1.13.0-nightly ( 2016-08-21) - bad 2016-08-26, rustc 1.13.0-nightly ( 2016-08-25) - bad stable/beta results: rustc 1.11.0 ( 2016-08-15) - good rustc 1.12.0-beta.2 ( 2016-08-24) - bad! beta-2016-08-16, rustc 1.12.0-beta.1 ( 2016-08-16) - buld error
Removing the from appears to make the crash go away.
I am trying to minimize a test case next.
Reduced case. This segfaults on x86_64-unknown-linux-gnu with , compiled with .
Normalized to: Backtrace is: Note the passed to .
So far I've found that the drop glue for optimizes to start with: That is reading the data pointer of the (which may be null in the case, where it represents ) and assuming it's .

While the null check which distinguishes between and is still there, it gets optimized out later, due to that metadata on the first . EDIT: Those 3 instructions are for the case, however, the IR ends up looking like: The has turned into a (presumably "everything but "). Which is still fine, is taken for and for , so you would think_ it'd work. But SimplifyCFG comes in and shoves the load into the entry block: What does this mean? LLVM has a nasty (class of) bug around metadata hints, not updating/removing them when needed MIR trans and the lifetime intrinsics are coincidental factors, causing the crash, not the misoptimization the assembly is pretty similar without lifetime intrinsics, the null check is still missing
Barebones reproduction:
Found a LLVM commit should've fixed this (but apparently didn't fully?): EDIT: Most likely  also needs that metadata-stripping treatment.
Filed LLVM bug report:
But I thought that bad-metadata loads only result in , not in UB. That's how the last of these bugs were fixed.
Just is useless, the metadata is there to kill later redundant checks. Hopefully the fix is just to add one or two of those metadata stripping loops to that unhandled case.
Fix is Recommend backport to beta, too.
Thanks a bunch
LLVM patch was merged to 3.9 stable branch in and will be included in 3.9.1 release.
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. trait T : Iterator<Item=Self::Item> //~^ ERROR unsupported cyclic reference between types/traits detected {} fn main() {} </ins>

Discussion:
Compiling the above (admittedly ill-typed) file will cause My version is
cc didn't easily find a dup of this.
Looks like I am hitting a similar issue. Repro:
your code compiles with code still ICEs though
I have a similar issue with:
With the latest nightly, your example doesn't ICE, but errors instead:
So that would be wrong...? Should I make a new issue?
Why would that be wrong? implementors don't have a associated type, so is correctly rejected (the first error). The second error pops up because of a typo (I just noticed) it says Resouces in .
Oh, woops - the example was meant to be:
that compiles with the latest nightly ()
Yay!
Change:
Err(Determinacy::Determined) => {} } <ins> // Ok at this point we've determined that the `attr` above doesn't // actually resolve at this time, so we may want to report an error. // It could be the case, though, that `attr` won't ever resolve! If // there's a custom derive that could be used it might declare `attr` as // a custom attribute accepted by the derive. In this case we don't want // to report this particular invocation as unresolved, but rather we'd // want to move on to the next invocation. // // This loop here looks through all of the derive annotations in scope // and tries to resolve them. If they themselves successfully resolve // *and* the resolve mentions that this attribute's name is a registered // custom attribute then we flag this attribute as known and update // `invoc` above to point to the next invocation. // // By then returning `Undetermined` we should continue resolution to // resolve the next attribute. </ins> let attr_name = match path.segments.len() { 1 => path.segments[0].ident.name, _ => return Err(determinacy),

Discussion:
Originally reported as this is reduced to: compiles with:
cc I'm not really sure what this classifies under, it seems like maybe although doesn't break it, only does. After though it may be broken by (I'm not 100% sure where this is happening)
I'm not really sure what this classifies under, it seems like maybe although doesn't break it This falls under and .
I hit this error last week when trying to update a crate that used 's derive macros. I found that ing the macro would give me the attribute error, but ing the crate worked.
I think that may be a separate bug, can you file a different issue? I believe I've fixed this issue in
Change:
} #[test] <ins> fn test_remove_matches() { let mut s = "abc".to_string(); s.remove_matches('b'); assert_eq!(s, "ac"); s.remove_matches('b'); assert_eq!(s, "ac"); let mut s = "abcb".to_string(); s.remove_matches('b'); assert_eq!(s, "ac"); let mut s = "ศไทย中华Việt Nam; foobarศ".to_string(); s.remove_matches('ศ'); assert_eq!(s, "ไทย中华Việt Nam; foobar"); let mut s = "".to_string(); s.remove_matches(""); assert_eq!(s, ""); let mut s = "aaaaa".to_string(); s.remove_matches('a'); assert_eq!(s, ""); } #[test] </ins> fn test_retain() { let mut s = String::from("α_β_γ");

Discussion:
Like , but doesn't result in any allocations. I started implementing this in but got stuck, mainly because of limitations in the APIs. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim