jiebi/CodeConvo huggingface dataset:
Change:
</form> </nav> <del> <section id='main' class="content {css_class}">{content}</section> </del> <ins> <section id='main' class="content">{content}</section> </ins> <section id='search' class="content hidden"></section> <section class="footer"></section>

Discussion:
What it looks like on : ! ! The strange color change on the side with the new sidebar style looks kind of tacky (especially at the bottom) and was probably not intended. Currently on : ! !
This is also broken on beta, tagging as such.
I'm looking into this. I see three potential options: the sidebar white on the src pages. This would look the same as the old styling. the width of the src view so it doesn't overlap with the sidebar. The sidebar is empty on src pages though so this looks kind of weird. If the sidebar retained its items from the other doc pages, this might look nice. the sidebar color and the background of the code block match so there isn't slightly different shades of grey on top of each other. I'm leaning toward option 1 for now but I think option 2 might be worth considering in the future. Thoughts?
While I am certainly not the most qualified to weigh in on this, my thoughts would be that 3 is less than desirable (having a random grey stripe on the left side looks out-of-place regardless of whether the color matches or not), 2 would unnecessarily decrease the usability of pages by decreasing the amount of horizontal space available to the code, and 1 is likely the best option. 3 would also mean that the code block would have padding on the right side but no padding on the left.
1 seems good
Ok. Option 1 it is!
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. use std::marker::PhantomData; struct TheType<T> { t: PhantomData<T> } pub trait TheTrait { type TheAssociatedType; } impl TheTrait for () { type TheAssociatedType = (); } pub trait Shape<P: TheTrait> { fn doit(&self) { } } impl<P: TheTrait> Shape<P> for TheType<P::TheAssociatedType> { } fn main() { let ball = TheType { t: PhantomData }; let handle: &Shape<()> = &ball; } </ins>

Discussion:
I don't know whether this was already reported. I get an ICE when running on (also the previous commit, didn't test others). An older version works fine:
cc has Callee in trace.
My guess is or needs to normalize the substitutions/.
Getting the same ICE with but also on while running examples (works fine on 1.8.0).
Just bisected this and got Surely it regressed during the trans refactoring, but as none of the intermediate commits is building it's not exactly sure which change is to blame though. Will help investigating further.
I would try to fix this, already did one-liner fix in according to , both and the minimal testcase in passed without ICE. Will prepare the PR later ;-) (EDIT: It's with stage1. Currently building stage2 and seeing if it can pass all tests. New to compiler writing and maintenance so kindly point out anything you feel like, thanks.)

Testcase currently relying on the most recent ncollide and nphysics3d from When I get some time later today I'll try to reduce it more. Code: Error:
I investigated this further and ended up with the following test case independent from ncollide/nphysics. It causes an ICE on both beta (rustc 1.9.0-beta.2 ( 2016-05-04)) and nigthly (rustc 1.10.0-nightly ( 2016-04-28))( and compiles fine on stable. The ICE will appear with and without . This might be related to . I can try to compile this on master but it will take some time before I can download the repo and compile rustc manually. This will compile fine, without any ICE if we do at least one of the following: Implement the method explicitly on :Remove the associated type in the impl, i.e., replace with (or anything else, including itself instead of ). Remove the cast to a trait-object at the end of the .
Fixed by .
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. use std::marker::PhantomData; struct TheType<T> { t: PhantomData<T> } pub trait TheTrait { type TheAssociatedType; } impl TheTrait for () { type TheAssociatedType = (); } pub trait Shape<P: TheTrait> { fn doit(&self) { } } impl<P: TheTrait> Shape<P> for TheType<P::TheAssociatedType> { } fn main() { let ball = TheType { t: PhantomData }; let handle: &Shape<()> = &ball; } </ins>

Discussion:
Testcase currently relying on the most recent ncollide and nphysics3d from When I get some time later today I'll try to reduce it more. Code: Error:
I investigated this further and ended up with the following test case independent from ncollide/nphysics. It causes an ICE on both beta (rustc 1.9.0-beta.2 ( 2016-05-04)) and nigthly (rustc 1.10.0-nightly ( 2016-04-28))( and compiles fine on stable. The ICE will appear with and without . This might be related to . I can try to compile this on master but it will take some time before I can download the repo and compile rustc manually. This will compile fine, without any ICE if we do at least one of the following: Implement the method explicitly on :Remove the associated type in the impl, i.e., replace with (or anything else, including itself instead of ). Remove the cast to a trait-object at the end of the .
Fixed by .
Change:
assert!(gt(c.iter(), b.iter()) == (c[0] >  b[0])); assert!(ge(c.iter(), b.iter()) == (c[0] >= b[0])); } <ins> #[test] fn test_multi_iter() { use slice::ImmutableVector; use iter::DoubleEndedIterator; let xs = [1i,2,3,4]; let ys = [4i,3,2,1]; assert!(eq(xs.iter(), ys.iter().rev())); assert!(lt(xs.iter(), xs.iter().skip(2))); } </ins> } #[cfg(test)]

Discussion:
They're currently very restricted as they only work with a single iterator type for both arguments, so, e.g. doesn't work. It should be easy to just add another parameter for the second argument.
Change:
<ins> fn main() { let a = std::process::Command::new("echo") .arg("1") ,arg("2") //~ ERROR expected one of `.`, `;`, `?`, or an operator, found `,` .output(); } </ins>

Discussion:
In an obscure situation with a typo (where there is a comma instead of a period), rustc will suggest replacing the comma with a semicolon, which will fail to compile. Produces the following error and suggestion: Some observations: This must be a let binding. The method calls must be on separate lines (all on one line gives a different error). I would expect this to provide the same error if it is all on one line ("expected one of , , , or an operator"), possibly with a "maybe incorrect" suggestion to replace it with a period (maybe only if the following character is not whitespace?). Note: Feel free to close this. This is really obscure, and I suspect it is not trivial to change, and it is fairly obvious what is wrong. I just thought it was strange, and I was doubly puzzled that the indentation mattered. rustc 1.45.0-nightly ( 2020-05-10) <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
This is because the error recovery tries to figure out if you typoed something when trying to write ; to end an expression. This is probably easy to fix.
claim
Thoughts about the better approach?: vs.
I would prefer something closer to what we already see in other syntax errors: We are not afraid of using vertical space to make errors clearer, but that vertical space still comes at a premium, as does verbosity. We try to lean towards the tersest possible output that can still convey the concept to the broadest set of people.
Merged. Thanks for a good learning issue And thanks for mentoring it I really appreciate your time!
Change:
LL | const MUTABLE_BEHIND_RAW: *mut i32 = &UnsafeCell::new(42) as *const _ as *mut _; | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ <del> thread 'rustc' panicked at 'no errors encountered even though `delay_span_bug` issued', src/librustc_errors/lib.rs:363:17 </del> <ins> thread 'rustc' panicked at 'no errors encountered even though `delay_span_bug` issued', src/librustc_errors/lib.rs:366:17 </ins> note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace error: internal compiler error: unexpected panic

Discussion:
I'm seeing an internal compiler error on the following input (found by ): The error happens on and but not on .
Visited from compiler team triage meeting. Categorized as P-medium.
searched nightlies: from nightly-2020-01-01 to nightly-2020-02-10 regressed nightly: nightly-2020-01-22 searched commits: from to regressed commit: source code: <details<summaryICE backtrace</summary<p</p</detailsReproduce bisect report:
Interesting -- the regression report suggests this was caused by , cc
The problem is here: is a character index. It needs to be translated into a byte index before it can be used to slice . I've submitted a
Change:
} } <del> /// Makes the test file. Also returns the number of lines before the code begins </del> <ins> /// Transforms a test into code that can be compiled into a Rust binary, and returns the number of /// lines before the test code begins. /// /// # Panics /// /// This function uses the compiler's parser internally. The parser will panic if it encounters a /// fatal error while parsing the test. </ins> pub fn make_test(s: &str, cratename: Option<&str>, dont_insert_main: bool,

Discussion:
Doc test with missing closing back quotes fail without any explanation. rust /// let x = 7; /// asserteq!(x, a()); /// // <- HERE /// fn a() -i32 { 7 } rustc 1.35.0-nightly ( 2019-03-22) binary: rustc commit-hash: commit-date: 2019-03-22 host: x8664-unknown-linux-gnu release: 1.35.0-nightly LLVM version: 8.0 rustc 1.33.0 ( 2019-02-28) binary: rustc commit-hash: commit-date: 2019-02-28 host: x86_64-unknown-linux-gnu release: 1.33.0 LLVM version: 8.0
~I believe this is related to . The second <coderust</codeline is unable to be lexed, so the lexer bails with an unbuffered fatal error.~ I was wrong. I have a fix incoming.
Oh hey, this looks to be related to and , cc
Change:
pub fn new(capacity: uint) -> RawTable<K, V> { unsafe { let ret = RawTable::new_uninitialized(capacity); <del> zero_memory(ret.hashes.0, capacity); </del> <ins> zero_memory(ret.hashes, capacity); </ins> ret } }

Discussion:
This compiles, despite Rc<T: !Send. I'm guessing this is because RawTable only uses K and V with marker::CovariantType, and I guess that isn't enough for the negative-impl to propagate. I haven't checked which other collections might be unsafe.
It appears that this also isn't specifically related to trait bounds: cc
Ah, yeah. RawTable contains only a , which is of course always Send/Sync. It should presumably just contain a plain and impl Send/Sync conditionally?
Or we need a more rich marker type.
may be a good replacement for the current system as it could contain a marker of and for example. For now though a manual impl of and will probably be required. Should other collections with an unsafe representation also be audited?
I can say confidently this is the only problem case in collections. It's the only collection that uses basically a pointer.
ok cool, good to know!
Change:
consider immediately dropping the value lint_non_binding_let_on_drop_type = <del> non-binding let on a type that implements `Drop` </del> <ins> non-binding let on a type that has a destructor </ins> lint_non_binding_let_on_sync_lock = non-binding let on a synchronization lock .label = this lock is not assigned to a binding and is immediately dropped

Discussion:
I tried this code: I got this warning: However, there is no impl on the type, so the error message is misleading. It is true however that there is a destructor, as defined here: That being said, it's insiginificant for all underlying types (only destructor of and type in the ), so ideally the warning still wouldn't even show. : <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summaryBacktrace</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
Well, even if the parameter of is , it still has a side-effect (deallocates memory). I don't think we need this special-casing. I do think the diagnostic is a bit misleading and should just say "has a destructor" or "has side-effects when dropped". Is there a more practical code example for why you'd want to suppress this error? The example you gave is a bit artificial, so it's a hard to motivate why we'd want to suppress this code since it really could be rewritten to be clearer.
claim
Change:
} pub fn bound_region_ptr_to_str(cx: &ctxt, br: BoundRegion) -> StrBuf { <del> bound_region_to_str(cx, "&", true, br) </del> <ins> bound_region_to_str(cx, "", false, br) </ins> } pub fn bound_region_to_str(cx: &ctxt,

Discussion:
Consider compilefail/regions-nested- When you run this, in addition to various error output, you will also see messages prefixed by . In those messages, when a lifetime is printed, it is printed with a leading in addition to the that is part of its name. For example: . In my opinion, this is confusing. is a lifetime, while are the first three characters of some (incomplete) type expression that is missing the pointed-to type (along with a potential qualifier). I suspect the leading is arising probably some artifact of how the code is implementing the trait; it might also involve the use of as the implementation of how lifetimes are printed (even though the former says it is for printing ptrs, not lifetimes). Also, there is an extra space between and above.
that's a holdover from the days before existed as a notation for lifetimes, definitely should be fixed
If no one else is working on this, I'll take it.
Apologies for how long this is taking, I'm still kind of learning the internals. I have a question, though. I have fixed this issue, but I'm now getting output like: The second is an int scoped to an anonymous lifetime, but the way I've implemented it there's no indication of this in the output. Is there a decided-upon notation for this case? Perhaps ?
I think those types should be written .
Or perhaps, better yet, or something like that. It'd be nice to indicate to the user that there are in fact two distinct lifetimes there, otherwise the message looks silly ("expected but found " -- wat??)
Given that work on this issue seems to have stagnated somewhat, would it be OK if I could take this issue? I was thinking that perhaps would be better than as it’s more descriptive, and matches with . Also, should all references be annotated thus? It seems slightly unnecessary to state the lifetime in an error like &'<anonintuinttype has no method `. This would probably complicate the implementation rather a lot, however.
On 5/19/2014 10:56 PM, P1start wrote:
Change:
<ins> // check-pass mod bar { pub trait QueryId { const SOME_PROPERTY: bool; } } use bar::QueryId; #[allow(non_camel_case_types)] pub struct bool; impl QueryId for bool { const SOME_PROPERTY: core::primitive::bool = true; } fn main() {} </ins>

Discussion:
I got a bug report on Diesel from someone who has a database column called . This lead to us attempting to generate the following code: which causes a type mismatch because their struct is shadowing the primitive. I'd like to change the generated code to be , which is the path that the rustdoc for libstd indicates it should be, but the type doesn't exist there, or anywhere else I can find. I would assume the same issue exists for , , and all the numeric types.
Since the module already exists, the type cannot be called . But it can be aliased as I guess.
would make sense as well
Related: The reason these primitives are not put into prelude was because but I think this is no longer a problem? (cc
Tagging this as a library issue. The solution (if it happens on our side) is to add a module or (and reexport it from as well) as described in In the meantime Diesel can privately define such a module itself and use it when unintended shadowing can happen. It doesn't make much sense to put primitive types into the std prelude because they are already in a prelude actually, it's just not the std prelude, but an additional language prelude one level below (as it was decided in and ).
I agree that primitives should be exposed at some absolute path. sounds reasonable.
I'd be happy to work on this. What's needed besides the implementation? I'm not entirely sure what a test for this should look like. Just a run-pass test that shadows and references ? Do we need one for every type?
I would start with a PR that has: Implementation, Module-level documentation for std::primitive with a helpful example that communicates why you may want to use this, One run-pass test for a shadowed bool as you suggested.
Sounds good. I'll try to get that PR done this week.
Does this need a feature gate?
Yes I believe so.
Triage: not aware of anything happening here.
Change:
<ins> //! The trait query `foo: Fn() -> u8` is a valid defining use of RPIT. // build-pass fn returns_u8(_: impl Fn() -> u8) {} pub fn foo() -> impl Sized { returns_u8(foo); 0u8 } fn main() {} </ins>

Discussion:
This used to compile and now ICEs: Compiles on Stable version: 1.70.0 Regressed in 1.71.0-beta.6 (2023-07-08 ) I guess it is , but this shouldn't be in beta? <details<summary<strongBacktrace</strong</summary<p</p</details
Bisection results: searched nightlies: from nightly-2023-05-20 to nightly-2023-07-14 regressed nightly: nightly-2023-06-25 searched commit range: regressed commit: ( -), cc <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.6</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
Change:
ModuleOnly(Span), } <del> // A minimal representation of a path segment. We use this in resolve because // we synthesize 'path segments' which don't have the rest of an AST or HIR // `PathSegment`. </del> <ins> /// A minimal representation of a path segment. We use this in resolve because we synthesize 'path /// segments' which don't have the rest of an AST or HIR `PathSegment`. </ins> #[derive(Clone, Copy, Debug)] pub struct Segment { ident: Ident, id: Option<NodeId>, <ins> /// Signals whether this `PathSegment` has generic arguments. Used to avoid providing /// nonsensical suggestions. has_generic_args: bool, </ins> } impl Segment {

Discussion:
Rustc should know that is not in the right direction because that still wouldn't make a valid thing to write; type parameters can't have type parameters (yet??). Separately, should also have prevented the suggestion in this case, but is an independent issue. cc who worked on this recently in .
Change:
fallback } <ins> fn suggest_shadowed( &mut self, err: &mut Diagnostic, source: PathSource<'_>, path: &[Segment], following_seg: Option<&Segment>, span: Span, ) -> bool { let is_expected = &|res| source.is_expected(res); let typo_sugg = self.lookup_typo_candidate(path, following_seg, source.namespace(), is_expected); let is_in_same_file = &|sp1, sp2| { let source_map = self.r.tcx.sess.source_map(); let file1 = source_map.span_to_filename(sp1); let file2 = source_map.span_to_filename(sp2); file1 == file2 }; // print 'you might have meant' if the candidate is (1) is a shadowed name with // accessible definition and (2) either defined in the same crate as the typo // (could be in a different file) or introduced in the same file as the typo // (could belong to a different crate) if let TypoCandidate::Shadowed(res, Some(sugg_span)) = typo_sugg && res.opt_def_id().is_some_and(|id| id.is_local() || is_in_same_file(span, sugg_span)) { err.span_label( sugg_span, format!("you might have meant to refer to this {}", res.descr()), ); return true; } false } </ins> fn err_code_special_cases( &mut self, err: &mut Diagnostic,

Discussion:
(A better title would be appreciated) I like this part: It could have a suggestion like , especially because are very close to each other on a US keyboard and could very well be a typo. Applying the suggestion will result in a compile error. No response No response <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I think the label might be fitting as well.
Error: Parsing assign command in failed: ...' claim' ' +D-invali'... Please file an issue on GitHub at if there's a problem with this bot, or reach out on on Zulip.
Change:
} pub fn get_missing_lang_items(&self) -> Vec<lang_items::LangItem> { <del> self.root .lang_items_missing .decode(self) .collect() </del> <ins> if self.proc_macros.is_some() { // Proc macro crates do not depend on any target weak lang-items. vec![] } else { self.root .lang_items_missing .decode(self) .collect() } </ins> } pub fn get_fn_arg_names(&self, id: DefIndex) -> Vec<ast::Name> {

Discussion:
: : Steps to reproduce: This is failing when the crate attempts to import the crate (which is a crate). That is, if I modify 's file to only contain: rustc will ICE. <details<summaryBacktrace:</summary</details
I suspect this is a duplicate of , but I only count 2 #[procmacro] and 1 #[procmacro_attribute] in the repository.
The crate only has 1 and 1 . If I comment both of them out, the compiler still ICEs. The crate used to compile a couple weeks ago, so this was a fairly recent change.
To give some bounds on this: the crate compiles with . It fails with . I would bisect this with rustup to determine which nightly the issue started with, but .
Derp, I just remembered I could remove the component. Okay, doing that, I was able to bisect the nightlies: Last working version: First failing version:
I just did a git bisect, and it looks like commit (from PR ) is the source of the breakage. cc
visited for triage. Going to try to followup with . Assigning to self to keep myself honest about that claim.
also, P-high
Am looking at this.
Minified: // #[allow(unused)] // enum ProcMacroHack { // Input = (stringify!(ARGS), 0).1, // } // The problem is caused by containing "host" defids and being used in [trans]. I don't think that this field has any business containing host libraries when compiling a proc macro, but I'll ask for confirmation. [trans]:
visited for triage. Seems like PR handles this. Leaving as P-high