jiebi/CodeConvo huggingface dataset:
Change:
<ins> // Issue #52544 // run-rustfix fn main() { let i: &i64 = &1; if i < 0 {} //~^ ERROR mismatched types [E0308] } </ins>

Discussion:
What I actually wanted was . <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
The problem is by the time this error is emittedwe don't have the information about the root cause anymore. In this case that would be the type of being checked for and figuring out the the rhs needs to be of the same type. Clippy has a lint that will tell you to clean it up afterwards, but we should probably issue a better diagnostic to begin with.
can you please create a ?
Please excuse my naïvety, but why is this (according to csmoes MCVE) a problem? You can actually write if i < &0 {} and everything works just fine. Can you please explain this part (to me)?
The comparison operator already takes references to both sides. so it seems simpler to dereference the lhs and save the monomorphizer and the optimizer some effort
Resurrecting this. what're the benefits of dereferencing the lhs instead of referencing the rhs? Also, if I were to go about fixing this, where would I start?
The benefit is that expands to , so if you start out with you get , seems better to just do instead (since is a no-op that gets easily removed). I'm not sure how to solve this or whether we should try at all.
claim
I want to get started with this, but would appreciate some mentoring from someone before I do, to point me in the right direction please
There's a reason I marked this as . I have no idea how to do this reasonably. I'm sorry, but I have no hints for you, and I don't even know if it's possible to do in a reasonable way.
cue terminator background music Leaving this here for future generations to see. I'm gonna try attempting to solve this and see if I can do something about it. I don't know if I can, or if I'll even survive this, but there's only one way to find out. Lol in all seriousness, if someone wants to claim this up, feel free to. Until then, I'll try and fix this.
Hi, are you still working on this issue
Hey I've been meaning to fix this up.

I've reached a point where I know exactly how to fix this as well. I just haven't found the time to fix this. Feel free to take it up, considering I wouldn't be having the time to work on this in the forseeable future.
release-assignment If do you find the time in the future, please claim this issue again. Until then I'll free it up in case anybody else wants it
Is anyone currently working on this? If not, I'd be happy to give it a go. claim
Change:
<ins> fn main() {} fn f() -> isize { fn f() -> isize {} pub f< //~^ ERROR missing `fn` or `struct` for function or struct definition //~| ERROR mismatched types //~ ERROR this file contains an un-closed delimiter </ins>

Discussion:
I'm getting an internal compiler error on the following program (found by ): I'm seeing the error on stable, beta, and nightly. As with , the error occurs on () but not on (). , the proposed fix for , does not fix this error. cc
Change:
pub mod borrowck; pub mod cfg; pub mod check_const; <ins> pub mod check_static_recursion; </ins> pub mod check_loop; pub mod check_match; pub mod check_rvalues;

Discussion:
Normally when a static variable has a recursive the definition, the compiler issues an error. However, if the static is used (and not just defined) rustc overflows its stack. This program causes a stack overflow: Stack trace:
Constant checking -- which detects this recursion -- occurs after type checking in the phase order, but type checking needs to evaluate the constant expression in order to find the length of the array type. It looks like strategically inserting a call to in the appropriate place would fix this at the cost of potentially performing the check many times.
After some chatting on IRC, it looks like the best way to fix this is to break the item recursion check out into a separate pass that comes before type checking. This is my first time looking at this part of the compiler, but I'll give it a shot.
This approach looks promising. I need to do a full build/test run and then I can submit a PR.
Fixed.
Change:
/// /// This trait can be used with `#[derive]`. When `derive`d on structs, two /// instances are equal if all fields are equal, and not equal if any fields <del> /// are not equal. When `derive`d on enums, each variant is equal to itself /// and not equal to the other variants. </del> <ins> /// are not equal. When `derive`d on enums, two instances are equal if they /// are the same variant and all fields are equal. </ins> /// /// ## How can I implement `PartialEq`? ///

Discussion:
Current docs on derive : I interpret the above statement as " compares enum discriminants", which is not the case. This is true for enums variants with no data, however for enum variants that are struct-like or tuple struct-like, derived actually compares the fields (which is expected) and not just discriminants: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
label: +A-docs +C-cleanup +E-easy +T-libs-api
claim
Change:
<ins> // 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. // Point at correct span for self type struct SomeType {} trait Foo { fn handler(self: &SomeType); } fn main() {} </ins>

Discussion:
The high end of the span of in is incorrectly set to .
It's seems to be caused by this `hack': (Called here: ) Weirdly enough, the proper span is shown for diagnostics: Any pointers,
Since works in s now, it's probably time to retire that hack and always provide the correct type. appears to hold the type (with its correct span), instead of the argument itself, in this case.
This has been fixed. Can this ticket be closed?
Change:
fn set_output_kind(&mut self, output_kind: LinkOutputKind, out_filename: &Path) { match output_kind { LinkOutputKind::DynamicNoPicExe => { <del> if !self.is_ld { </del> <ins> if !self.is_ld && self.sess.target.target.options.linker_is_gnu { </ins> self.cmd.arg("-no-pie"); } }

Discussion:
between and linking behavior changes which broke my cross compilation from linux to macos. It now adds the which is unknown by my compiler. leaving it out would probably fix the error. Below are detailed informations about my project and the cross compilation setup in order to reproduce. We for the veloren project we have a CI docker container. i tried to update the toolchain. with docker the error is reproduceable quite easy, however if you are familar with docker you can skip some steps in order to save you a hour of compilation I expected to see this happen: we successfully build the osxcross enviorment with the first docker container, based on this: the code compiles for macos after compilation it starts linking using the '/dockercache/osxcross/target/bin/x86_64-apple-darwin17-clang' linker we build in osxcross the linking suceeds Instead, this happened: the linking fails as it tries to use a flag which isn't supported. Interestingly when you search in the rust code for this flag, you'll find a refactor about a month ago changing behavior here: however i personally dont know how that caused the change. :
This is a regression from
Looks like the condition was lost, and clang for macos is apparently not "linkerisgnu".
I'll fix this today.
Assigning .
Fixed in
awesome, i will confirm it, once it's in a good nightly build :)
Just wanted to confirm that with this error no longer occurs, so it is fixed now, thank you!
Change:
} } <ins> // (ouz-a 1005988): Normally `[T] : std::ops::Index<usize>` should be normalized // into [T] but currently `Where` clause stops the normalization process for it, // here we compare types of expr and base in a code without `Where` clause they would be equal // if they are not we don't modify the expr, hence we bypass the ICE fn is_builtin_index( &mut self, typeck_results: &TypeckResults<'tcx>, e: &hir::Expr<'_>, base_ty: Ty<'tcx>, index_ty: Ty<'tcx>, ) -> bool { if let Some(elem_ty) = base_ty.builtin_index() { let Some(exp_ty) = typeck_results.expr_ty_opt(e) else {return false;}; let resolved_exp_ty = self.resolve(exp_ty, &e.span); elem_ty == resolved_exp_ty && index_ty == self.fcx.tcx.types.usize } else { false } } </ins> // Similar to operators, indexing is always assumed to be overloaded // Here, correct cases where an indexing expression can be simplified // to use builtin indexing because the index type is known to be

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. -- <!-- 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
Minimized a bit more:
It started ICE-ing in 1.41.0:
This compiles successfully without the bound. It also compiles if you change the bound to constrain the associated type:
I bisected it to be between and : I've tried to bisect between these commits, but I'm getting a compilation error in llvm.
It'll be , which changed the coherence rules to allow . The impl in this code is intentionally allowed under the new rules and should be fine, so it didn't really regress in that PR so much as it was newly permitted but likely surfaced a pre-existing bug. I tried to replicate this issue with a local trait but compiles successfully, so this does seem to involve the built-in trait and operator (the error message complains about the MIR statement which is a built-in index).
Further reduced to: , but not on 1.24.0 I agree with assessment:
So it could be considered a stable-to-stable regression? I don't how or who could add this label.
Yeah, I guess we could modify labels +regression-from-stable-to-stable although it's a regression from a very old stable
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-medium
Change:
<ins> // check-pass // edition:2018 macro_rules! with_doc { ($doc: expr) => { #[doc = $doc] async fn f() {} }; } with_doc!(concat!("")); fn main() {} </ins>

Discussion:
I was migrating my library (Mammut) to use reqwest and be async, and the compiler ICEd. I don't know how to reduce it further than this. I tried this code: I expected to see this happen: A successful build or another compile error Instead, this happened: I also tried this on the latest nightly and it emits the same error. : Backtrace:
Reproduced with lastest nighlty: ICE from macro resolving I believe. cc
cc
triage: P-high, removing nomination tag. (instead, going to proritize going through the P-high issues that have accumulated over last two weeks.)
Visiting from triage.. the next step is to reduce the reproducer.
Reduced ():
Further reduced:
Fixed in
Change:
use session::search_paths::PathKind; use session::config::DebugInfoLevel; use ty::tls; <del> use util::nodemap::{NodeMap, FnvHashMap}; </del> <ins> use util::nodemap::{NodeMap, FnvHashMap, FnvHashSet}; </ins> use util::common::duration_to_secs_str; use mir::transform as mir_pass;

Discussion:
Example: Adding to a crate will point out the location of this line for every time the lint fires (). This should be listed only once. It should be reasonably easy to deduplicate these based upon equal span and message.
I think this is a good "E-easy" candidate. Relevant code is in . Using a as a field on should work, so that we only emit a note the first time we encounter it.
Question -- in , we get only "lint level defined here" per , even if it applies to multiple lints (e.g., ). Do people think it'd be better to have it like this, or would you rather see different messages for (say) and , even if they both apply to the same ?
Can someone with perms close this? I forgot to use the in .
Great! Fixed in
Change:
} } <ins> pub trait Trait4<'a, T> { type Output: 'a; fn qux(&self, _: &T) -> Self::Output; } pub struct Type4; impl<'a, T, U> Trait4<'a, U> for T { type Output = &'a i32; fn qux(&self, _: &U) -> Self::Output { &0 } } </ins> pub fn foo1(a: &dyn Trait1) { a.foo(); // CHECK-LABEL: define{{.*}}4foo1{{.*}}!type !{{[0-9]+}}

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. --<!-- 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 --
claim
Change:
stable("test-args", |o| { o.optmulti("", "test-args", "arguments to pass to the test runner", "ARGS") }), <del> unstable("test-run-directory", |o| { </del> <ins> stable("test-run-directory", |o| { </ins> o.optopt( "", "test-run-directory",

Discussion:
This is a tracking issue for the flag in rustdoc. This flag changes the directory where doctests are run. This was to support changing the directory used while running in a Cargo workspace. See for more information. None at this time. — Initial PR. Tracking issues are used to record the overall progress of implementation. They are also used as hubs connecting to other relevant issues, e.g., bugs or open design questions. A tracking issue is however not* meant for large scale discussion, questions, or bug reports about a feature. Instead, open a dedicated issue for the specific matter and add the relevant feature gate label. cc
I opened with the aim to stabilize this rustdoc flag, primarily to facilitate the cargo flag, and to eventually making it the default. The flag in combination with allows specifying an explicit directory in which rustdoc will run the compiled doctests. The default, without this explicit flag, is to run the resulting doctest binaries in the same current working directory as rustdoc itself. This flag is primarily the building block for the cargo flag (See ). With that flag, doctests are handled consistently to unit- and integration tests: They will be compiled relative to the cargo workspace root, but they are run in the crate directory. The flag is currently not documented as part of the . -- highlights usage with cwd-sensitive functions inside doctests. -- shows indirect usage via the cargo flag.Similar flags that allow hooking into or observing the side effects of rustdoc test compilation, such as are not stable yet, and there does not seem to be a push to stabilization either. The usefulness of this flag when invoking manually might be limited. But it is a requirement for the cargo flag. Is there maybe a better alternative to solve the compile/run directory inconsistency that exists in cargo workspaces today?
over in expressed agreement to make the cargo flag the default, considering it rather a bugfix for the current inconsistent behavior. However, stabilizing is a requirement for that, and there does not seem to be a better alternative to it. is there anything I can do to move stabilization () forward?
Next step is the FCP. I'll start on the PR.
cargo test runs doc tests by default and doesn't allow to specify . My project uses sqlx which tries to create directory. But if fails because I run the build inside a container against immutable source. Instead I expect that the test should stay in the workspace directory and use which is mounted as a build cache volume.
Change:
<ins> // check-pass trait AsBufferView { type Device; } trait Error { type Span; } trait Foo { type Error: Error; fn foo(&self) -> &<Self::Error as Error>::Span; } impl<D: Error, VBuf0> Foo for VBuf0 where VBuf0: AsBufferView<Device = D>, { type Error = D; fn foo(&self) -> &<Self::Error as Error>::Span { todo!() } } 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. -- <!-- 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. --This code compiles on the and channels, but crashes with an ICE on the channel. : (Backtrace omitted) .. And so on for , , etc. <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Minimized (from the chumsky crate) to: or (from the above) to: Bisected with v0.6.6 to , which is and that PR does look like it's in the right area to have caused this.
Change:
<ins> // run-pass #![feature(const_generics)] //~^ WARN the feature `const_generics` is incomplete and may cause the compiler to crash fn main() { <()>::foo(); } trait Foo<const X: usize> { fn foo() -> usize { X } } impl Foo<{3}> for () {} </ins>

Discussion:
: <details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Got same error with: It seems unrelated to the type of the const
claim
Reduced: Looks like a normalization failure to me, but that shouldn't happen for .
So I found the bug, is just outright missing : <hr/But also, it's worrying that an equivalent to this is missing for consts (even if it's not relevant here):
For the record, what I described above () isn't fixed, just worked around. EDIT: opened .
Change:
<del> Subproject commit 8f89434446f72f27f8145d8bbc1a302c6ef29d1e </del> <ins> Subproject commit 5965cf5fc17affc84c11dc9972ae8f4dc2c32db1 </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! And nominating for compiler team prioritization.
I don't think we can resolve this until is fixed, as we can't build a libstd anymore :(
However, that cannot be the only problem -- Miri also fails to build in-tree: any idea why those might be missing?
is an optional dependency of libstd, and Miri does not enable that option. Looks like the backtrace code incorrectly expects it to be present anyway?
Ah this is my mistake, I didn't check that libstd still compiled without the dependency. I believe that unconditionally depending on is indeed the right thing to do. I can send a PR for this tomorrow if no one else gets to it.
Just please make sure to also include it in rust-src then :)
I'm hoping this will be fixed by
You can test that via 'x.py test --stage 0 src/tools/miri'
That indeed solved the libstd build issue, at least for in-tree builds. Now the problem is Previously, disabling the feature meant we did not have to do anything. Now it seems like some C FFI () is mandatory? That's odd though, elsewhere said this is now Rust-only.
Interestingly, is only called on a double-panic.
should help (and that's way easier than finding all the methods we have to stub, in particular on Windows).
Backtraces are unconditionally generated on double panics, and some reshuffling of the crate itself probably meant that happened to go to the noop unwinder before and now it went to the libunwind unwinder. In any case should fix that issue.
Change:
asm!("xor %eax, %eax" : : <del> : "{eax}" </del> <ins> : "eax" </ins> ); # } } ```

Discussion:
The rust book states that asm! clobbers should be written as "{rdx}" but when you use them as such the clobbers will be silently ignored making for some nasty bugs. output Relevant part of objdump: Relevant LLVM IR: As we can seen in the emitted LLVM IR, the given clobbers are surrounded by {{}}. I'm not sure what effect this has, but it seems like LLVM just silently ignores them. A fix would either be to not send the extra {}'s to LLVM or to edit the documentation to reflect that clobbers should be given without surrounding {}'s. Either way, this should probably not generate invalid code silently.
Change:
<del> Version 1.2.0 (August 2015) </del> <ins> Version 1.2.0 (2015-08-07) </ins> =========================== * ~1200 changes, numerous bugfixes

Discussion:
Pages like Wikipedia/Wikidata need to prove that a given information is correct. The announcement blog posts seem to be the only obvious place to look up the the exact release dates. Blog post URLs are not necessarily stable over time. It would be simpler to just refer to
They already contain the month and the year, is the day that important? (that said, I don't see the harm, I was just like "I thought we did this already")
That probably depends on the context. Most software on Wikidata has the complete date defined along the versions. Does it hurt? If the days where given, what could be reasons to remove them? I would add the days in a PR myself, just wanted to make sure there is no opposition. I suggest we use ISO-format. The dates are currently defined in Wikdata as
Change:
match attr.parse_list(cx.parse_sess, |parser| parser.parse_path_allowing_meta(PathStyle::Mod)) { <del> Ok(ref traits) if traits.is_empty() => { cx.span_warn(attr.span, "empty trait list in `derive`"); false } </del> Ok(traits) => { result.extend(traits); true

Discussion:
The following code emits an unsquelchable warning. This warning should be a part of .
empty trait list in should have a lint name ... and that name is .
Does not appear to squelch the warning for me...
It seems eminently reasonable to me to include in since it is an attribute applied with no effect; so let's kick off fcp for that. merge
Team member has proposed to merge this. The next step is review by the rest of the tagged teams: [x] [x] [x] [x] [x] [ ] [x] [x] [x] [ ] No concerns currently listed. Once a majority of reviewers approve (and none object), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See for info about what commands tagged team members can give me.
Implementing this as part of the existing would be complicated by , but it might also be possible to implement where the existing "empty trait list" warning is issued (possibly as a ).
I need to make a buffered early lint for the same thing with .
Seems reasonable. And a macro that might end up with an empty derive list should have no problem turning off locally.
reviewed I certainly agree with moving warnings to lints.
:bell: This is now entering its final comment period, as per the . :bell:
The final comment period, with a disposition to merge, as per the , is now complete.