jiebi/CodeConvo huggingface dataset:
Change:
vec![ // super::$test_fn(b) cx.expr_call( <del> sp, </del> <ins> ret_ty_sp, </ins> cx.expr_path(cx.path(sp, vec![item.ident])), vec![cx.expr_ident(sp, b)], ),

Discussion:
Edit: outstanding work is to change the span from pointing at the function body to point at the return type. adds a test for the case where a unit test returns a value that does not implement . The message currently talks about and has an ugly multi-line span: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
As long as we have the method signature around when we emit E0277, it has a field with the span for the return type, which should be used for this instead, but this will probably require some special casing this in that (already quite hairy) diagnostic code. Extending could be possible, but I would advice against doing so to avoid turning that attribute into a bigger monster than it already is.
Chiming in that this confused me as I was preparing for a Rust training session, where I expect it would confuse the students even more. Specifically, this should not talk about at all as it's plausible to cause people to look in the wrong spot.
CC
Just started learning Rust and came across this error while writing some tests- I absolutely agree "ungreat" is perfect word choice.
It could get even more confusing when : Rust 1.64
This issue is now (mostly) fixed on nightly by and should be closed I think. The error message is now correct but the span is still “ugly”. I've overlooked this issue and only closed its duplicate, namely .
Actually, let's keep this open only for the span change :)
Just wrap the return type with a struct and implement the Termination trait for that wrapper struct example
Note that this GitHub issue is about the subpar error message given by the compiler which should be fixed and not about potential solutions for user code when facing this message. claim
Change:
name = "rustc_query_impl" version = "0.0.0" dependencies = [ <del> "measureme 10.0.0", </del> <ins> "measureme", </ins> "rustc-rayon-core", "rustc_ast", "rustc_data_structures",

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!
Probably a missing join (these tests are a bit random, now that we have preemption).
Change:
} ExprCall(ref callee, _) => { match v.tcx.def_map.borrow().find(&callee.id) { <del> Some(&DefStruct(..)) => {}    // OK. </del> <ins> Some(&DefStruct(..)) | </ins> Some(&DefVariant(..)) => {}    // OK. _ => { span_err!(v.tcx.sess, e.span, E0015,

Discussion:
compiles fine (other than the dead code warning for ), but is not:
I hit this as well, I would love a fix :+1:
Change:
<del> //@ known-bug: #117829 #![feature(auto_traits)] trait B {} auto trait Z<T> where T: Z<u16>, <T as Z<u16>>::W: B, { type W; } fn main() {} </del>

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<strongICE location label +A-auto-traits +F-unboxed_closures
Minimized: <details<summaryError output</summary</details label -F-unboxedclosures +F-autotraits
Regression in nightly-2023-06-18 (...)
probably just another duplicate of

<!-- [31mICE[0m: Rustc '' 'error: internal compiler error: unexpected builtin trait with associated type: <u16 as Z<'b, u16', 'error: internal compiler error: unexpected builtin trait with associated type: <u16 as Z<'b, u16' File: --auto-reduced (treereduce-rust): original: Version information ` Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details
Regression in nightly-2023-06-18 Regression in / ping
The depth of the stack at the ICE depends on the recursion limit. Add and it still ICEs, but with only 8 repeated stack portions.
Simplified to use only locally defined traits, not use a lifetime parameter, and hit fewer errors: Oddly enough, this variant hits the same ICE but without such a deep stack.
You can replace the bound with a lifetime bound to reproduce too, such as .
Change:
/// A hashable type. /// <del> /// The `H` type parameter is an abstract hash state that is used by the `Hash` /// to compute the hash. </del> <ins> /// Types implementing `Hash` are able to be [`hash`]ed with an instance of /// [`Hasher`]. </ins> /// <del> /// If you are also implementing [`Eq`], there is an additional property that /// is important: </del> <ins> /// ## Implementing `Hash` </ins> /// <del> /// ```text /// k1 == k2 -> hash(k1) == hash(k2) /// ``` /// /// In other words, if two keys are equal, their hashes should also be equal. /// [`HashMap`] and [`HashSet`] both rely on this behavior. </del> <ins> /// You can derive `Hash` with `#[derive(Hash)]` if all fields implement `Hash`. /// The resulting hash will be the combination of the values from calling /// [`hash`] on each field. </ins> /// <del> /// ## Derivable /// /// This trait can be used with `#[derive]` if all fields implement `Hash`. /// When `derive`d, the resulting hash will be the combination of the values /// from calling [`.hash`] on each field. /// /// ## How can I implement `Hash`? </del> <ins> /// ``` /// #[derive(Hash)] /// struct Rustacean { ///     name: String, ///     country: String, /// } /// ``` </ins> /// <del> /// If you need more control over how a value is hashed, you need to implement /// the `Hash` trait: </del> <ins> /// If you need more control over how a value is hashed, you can of course /// implement the `Hash` trait yourself: </ins> /// /// ``` /// use std::hash::{Hash, Hasher};

Discussion:
Part of Here's what needs to be done to close out this issue: needs a stronger summary/explanation distinction. "This structure is zero-sized and does not need construction." is weird. also needs a stronger summary/explanation distinction. It also needs a better explanation of why it exists with an example. needs general improvement, it is the main bit of this module, but its docs feel tossed together and have few examples or coherence. needs more than just a summary line; it needs explanation and examples.
What kind of further documentation are you looking for here?
Better explanations for examples of implementing and and and more docs generally for all three.
There seem to be a lengthy example of BuildHasherDefault in this commit () Also for BuildHasher and there is a healthy amount of documentation as of now. Hasher seems to be really outdated (still lists several Implementors without mentioning they have been deprecated), which I'm looking into right now.
Thanks ! Looks like all that's left is documenting .
I am happy to mentor anyone who wants to tackle this issue.
I volunteer as a tribute :-)
wonderful! If you need any help, please just let me know, as I said above, happy to help you help me (We can do it here or ping me on IRC)
I have more specifics in the main issue above
I'm gonna tackle this one this weekend! (if that's okay with you,
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. pub struct Foo; #[doc(hidden)] mod bar { trait Bar {} impl Bar for ::Foo {} } </ins>

Discussion:
The link to "FullOps" on this page is broken:
Background for anyone who wants to tackle this: is an unstable trait defined in a module of (specifically in ). It is an implementation detail that should not leak out. Because of the above, the fix is to not list the trait on the implementing type's page, not to generate a doc page for . Other examples of such traits are and on and , which are also listed on the respective pages with dead links.
I want to give it a try, however i don't know what is the right way to test changes. How can i build only the related docs? Make docs rebuilds everything, so it takes a while (even with the flag). How can i quickly test the html output for the docs without rebuilding everything? I tried rustdoc 'path/to/file' too, but it is not able to compile the doc for that given file
Unfortunately, this kind of change is just going to take forever to test. :/ You have to point it at a crate root, not just any rust file.
:( I will give a try to rustdoc once more. Compilations on my machine take around 1 hour, so i don't know if i can fix something that way.
I believe I have an explanation. The annotation on the modules ensures no documentation is created for the module or any traits or similar contained within it. However, when assessing whether s should be hidden on other pages the documentation compiler considers only the hiddenness of the itself, not its containing module. I suspect the existing behaviour is working as intended—consider the case of someone putting their (given public types Foo and Bar) in a doc-hidden module and then wondering where the went. I recommend the simple fix of putting on the s of the public-not-public traits.
Thanka for tracking this down! You are right that impls in private modules should generally be displayed since they are public in a sense. But I think the current state of affairs is very unsatisfying, since Rustdoc generates broken docs for perfectly valid code. Shouldn't it at the very least somit links that will wind up dead? And if both trait and implementing type are dic(hidden), as is the case here, it seems like a reasonable heuristic to treat the impl as hidden too.

I'm less sure about hidden traits in public types (e.g., RawFloat and f64) but if it's overridable it also seems sensible.
Putting my real-world-concerns hat on, I think this is really just a corner case where and “public” don't coincide. The Right Thing is to propagate from traits to s of those traits; I don't know how difficult that is to do, so I opted for recommending a simple fix which I'd confirmed to work.
Change:
a: &'tcx ty::Const<'tcx>, b: &'tcx ty::Const<'tcx>, ) -> RelateResult<'tcx, &'tcx ty::Const<'tcx>> { <del> debug!("{}.consts({:?}, {:?})", self.tag(), a, b); if a == b { return Ok(a); } let infcx = self.fields.infcx; let a = replace_if_possible(infcx.const_unification_table.borrow_mut(), a); let b = replace_if_possible(infcx.const_unification_table.borrow_mut(), b); // Consts can only be equal or unequal to each other: there's no subtyping // relation, so we're just going to perform equating here instead. let a_is_expected = self.a_is_expected(); match (a.val, b.val) { (ConstValue::Infer(InferConst::Var(a_vid)), ConstValue::Infer(InferConst::Var(b_vid))) => { infcx.const_unification_table .borrow_mut() .unify_var_var(a_vid, b_vid) .map_err(|e| const_unification_error(a_is_expected, e))?; return Ok(a); } (ConstValue::Infer(InferConst::Var(a_id)), _) => { self.fields.infcx.unify_const_variable(a_is_expected, a_id, b)?; return Ok(a); } (_, ConstValue::Infer(InferConst::Var(b_id))) => { self.fields.infcx.unify_const_variable(!a_is_expected, b_id, a)?; return Ok(a); } _ => {} } self.fields.infcx.super_combine_consts(self, a, b)?; Ok(a) </del> <ins> self.fields.infcx.super_combine_consts(self, a, b) </ins> } fn binders<T>(&mut self, a: &ty::Binder<T>, b: &ty::Binder<T>)

Discussion:
<short summary of the bugI tried this code: I expected to see this happen: It should build. Instead, this happened: rustc crashed with: Possible workaround: replace with . playground: rustc version: 1.39.0-nightly 2019-09-15
cc
Also ICEs without explicit feature gate enabled :/
Change:
|     +++ error[E0425]: cannot find value `y` in this scope <del> --> $DIR/suggest-let-for-assignment.rs:16:23 </del> <ins> --> $DIR/suggest-let-for-assignment.rs:22:23 </ins> | LL |     println!("y: {}", y); |                       ^ not found in this scope <del> error: aborting due to 7 previous errors </del> <ins> error: aborting due to 11 previous errors </ins> For more information about this error, try `rustc --explain E0425`.

Discussion:
I accidentally typoed an underscore instead of a space between and the name of the new variable I was trying to declare. If a binding isn't found, and it starts with (or frankly , if you forget/miss the space completely), it seems like it would be more likely to suggest ( plus a space) rather than the current suggestion of an additional . No response <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
interesting, I'd like to have a try. but might not solve it quicklly casuze I am new to rustc
sounds good! feel free to ask for help if you need it, but the implementation should be fairly simple. assign
Change:
#![feature(bool_to_option)] #![feature(crate_visibility_modifier)] #![feature(decl_macro)] <ins> #![feature(inner_deref)] </ins> #![feature(nll)] #![feature(or_patterns)] #![feature(proc_macro_internals)]

Discussion:
This is still in 's build script: But the use site has been moved here: This means that won't be rebuilt when that env var changes. For the record, I haven't seen a bug from this, was just curious where may be used and spotted the mismatch. cc
Found another one: is used in but it's still mentioned by . cc Could we automate ensuring this? e.g. by searching for in tidy.
Yeah, we can try I guess. Not sure :) Maybe the right solution is that Cargo would, other than some whitelist, remove unknown variables from rustc's environment -- and the whitelist can be expanded via the build script env-tracking.
hmm I wonder if abusing the file format (from ) or encoding this extra info in a comment, would be a good idea.
You mean such that if you use we automatically tell Cargo to rebuild on changes? (That's ). But yeah, I think that would be good. Ideally this would be "well-integrated" vs. the current state of everyone having to remember to do it.

(As discussed with on IRC.) Rustc should have an option to obtain a list, as part of building, of every environment variable that was requested via the or macros (tagged accordingly with "required" or "optional"), as well as providing a way to instrument intrinsics like called by scripts. This will make it more feasible to detect (and lint about) the usage of environment variables only set by newer build bits (e.g. Cargo) without an appropriate versioned dependency; for instance, it'd be possible to say "you use the environment variable without a dependency on a version of Cargo that supplies . This would also help people doing reproducible builds to see what environment variables might affect a build. This will never be perfect; it can't capture variables read from native code or from code that goes out of its way to bypass the normal mechanism (e.g. calling .) However, this would still catch many common cases.
Just following up to say that this is an accurate reflection of what we discussed. As said, it's part of a larger goal to detect usage of newer Cargo features on older versions of Cargo and let the user know which version of Cargo they need to upgrade to. For keys in , it's enough to simply keep a list of when a particular key was (since Cargo is the one parsing ). But if Cargo adds an environment variable, we need some compiler help to detect that the environment variable was used from Rust code.
I believe this may be a dupe of
They're related, though I think seems more narrow in scope.
Change:
} Some(Debugger::Lldb) => { <del> config.lldb_python.hash(&mut hash); </del> <ins> config.python.hash(&mut hash); </ins> config.lldb_python_dir.hash(&mut hash); env::var_os("PATH").hash(&mut hash); env::var_os("PYTHONPATH").hash(&mut hash);

Discussion:
Compiletest currently has two different arguments telling it which python to use. Since , both are always the same. We should change it to just one argument to simplify things. Mentoring instructions: Change to be a single argument, then change to use the updated arguments. are you interested in tackling this one too? :) label +A-rustbuild +A-testsuite +E-easy +E-mentor Originally posted by in <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
claim
Change:
issue_tracker_base_url = "https://github.com/rust-lang/rust/issues/" )] #![feature(core_intrinsics)] <del> #![feature(int_bits_const)] </del> #![feature(lang_items)] #![feature(nll)] #![feature(panic_unwind)]

Discussion:
Tracking issue for as introduced by Gated behind .
modify labels: +T-libs
Error: Label P can only be set by Rust team members Please let know if you're having trouble with this bot.
This has been in a few releases, is used in many places in rustc itself, and there's no open questions so far. Time to stabilize? merge
Team member has proposed to merge this. The next step is review by the rest of the tagged team members: [x] [ ] [x] [x] [x] [x] [ ] No concerns currently listed. Once a majority of reviewers approve (and at most 2 approvals are outstanding), 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.
: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. As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed. The RFC will be merged soon.
We agreed in the libs meeting just now to revert stablization, since the is significant throughout the ecosystem, through . :( We can stabilize it again once that is solved upstream.
Closing this since has been merged.
Change:
assert!(vd.into_iter().eq(vec)); } } <ins> let vec = Vec::from([(); MAXIMUM_ZST_CAPACITY - 1]); let vd = VecDeque::from(vec.clone()); assert!(vd.cap().is_power_of_two()); assert_eq!(vd.len(), vec.len()); } #[test] #[should_panic = "capacity overflow"] fn test_from_vec_zst_overflow() { use crate::vec::Vec; let vec = Vec::from([(); MAXIMUM_ZST_CAPACITY]); let vd = VecDeque::from(vec.clone()); // no room for +1 assert!(vd.cap().is_power_of_two()); assert_eq!(vd.len(), vec.len()); </ins> } #[test]

Discussion:
I expected VecDeque constructed from Vec to either work correctly or construction to panic if it is not possible. Instead: Introduced by . <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
cc
Not sure how severe this is, but figured that it's worth prioritizing.
claim
Assigning and removing as in the prioritization working group.
should fix this -- written before I saw this issue and claim, so I'm sorry if you were still working on it.
Change:
} #[test] <del> fn test_to_titlecase() { fn title(c: char) -> Vec<char> { c.to_titlecase().collect() } assert_eq!(title('a'), ['A']); assert_eq!(title('ö'), ['Ö']); assert_eq!(title('ß'), ['S', 's']); // not ẞ: Latin capital letter sharp s assert_eq!(title('ü'), ['Ü']); assert_eq!(title('💩'), ['💩']); assert_eq!(title('σ'), ['Σ']); assert_eq!(title('τ'), ['Τ']); assert_eq!(title('ι'), ['Ι']); assert_eq!(title('γ'), ['Γ']); assert_eq!(title('μ'), ['Μ']); assert_eq!(title('α'), ['Α']); assert_eq!(title('ς'), ['Σ']); assert_eq!(title('Ǆ'), ['ǅ']); assert_eq!(title('ﬁ'), ['F', 'i']); assert_eq!(title('ᾀ'), ['ᾈ']); } #[test] </del> fn test_is_control() { assert!('u{0}'.is_control()); assert!('u{3}'.is_control());

Discussion:
Converting a string to titlecase requires a word-breaking algorithm, which std does not provide. We do have the method for converting a single char to titlecase, if one can identify the first char of a word. This method requires a few kb of lookup tables. We might want to consider whether its wise to ship one without the other. This is marked for stabilization in 1.2 so we need to decide soon. cc
so I'm fine just deleting it, I don't think it's marked to be stable.
Change:
pub tracking_issue: Option<u32>, } <ins> impl Feature { fn check_match(&self, other: &Feature)-> Result<(), Vec<&'static str>> { let mut mismatches = Vec::new(); if self.level != other.level { mismatches.push("stability level"); } if self.level == Status::Stable || other.level == Status::Stable { // As long as a feature is unstable, the since field tracks // when the given part of the feature has been implemented. // Mismatches are tolerable as features evolve and functionality // gets added. // Once a feature is stable, the since field tracks the first version // it was part of the stable distribution, and mismatches are disallowed. if self.since != other.since { mismatches.push("since"); } } if self.tracking_issue != other.tracking_issue { mismatches.push("tracking issue"); } if mismatches.is_empty() { Ok(()) } else { Err(mismatches) } } } </ins> pub type Features = HashMap<String, Feature>; pub fn check(path: &Path, bad: &mut bool, quiet: bool) {

Discussion:
Currently, there in tidy that ensures that there is no library feature and language feature of the same name. Its presence in the documentation above. This check since , and has caused multiple additions that have both library and language components to be split up: / / / PR has challenged the status quo, by reusing the lang feature inside libraries provided to programs. It actually to the tidy check in order to get it passing. There has been about this in the thread of and the resolution was to allow to share the feature gate. So my question is: which purpose does this check serve? should the check be present, or should it be abolished? Should the feature gate be split up into a library component and a lang component?
IMO we should just kill the tidy check. For inclusive ranges we are stabilizing the lib and syntax separately, but if they had been under the same gate it would have been easy to split them up, like we are doing for const fn.
I too think we should lump things that are "the same underlying concept" under one feature gate.
Looks like the original code allowed for a 'joint features' whitelist, so it seems like it might have just been a sanity check that any intersection was intentional. Indeed, that script actually says that it's for doing some sanity checks. If for some reason that sanity check is still desirable, at minimum I'd be +1 to creating a whitelist rather than ad-hoc growing the if condition.
We can guard from that by doing a check for any joint features whether the tracking issue and stability status (stable or unstable) matches between lib and lang features.