jiebi/CodeConvo huggingface dataset:
Change:
bx.sext(cmp, ret_ty) } <ins> /// Codegen takes advantage of the additional assumption, where if the /// principal trait def id of what's being casted doesn't change, /// then we don't need to adjust the vtable at all. This /// corresponds to the fact that `dyn Tr<A>: Unsize<dyn Tr<B>>` /// requires that `A = B`; we don't allow *upcasting* objects /// between the same trait with different args. If we, for /// some reason, were to relax the `Unsize` trait, it could become /// unsound, so let's validate here that the trait refs are subtypes. pub fn validate_trivial_unsize<'tcx>( tcx: TyCtxt<'tcx>, source_data: &'tcx ty::List<ty::PolyExistentialPredicate<'tcx>>, target_data: &'tcx ty::List<ty::PolyExistentialPredicate<'tcx>>, ) -> bool { match (source_data.principal(), target_data.principal()) { (Some(hr_source_principal), Some(hr_target_principal)) => { let infcx = tcx.infer_ctxt().build(); let universe = infcx.universe(); let ocx = ObligationCtxt::new(&infcx); infcx.enter_forall(hr_target_principal, |target_principal| { let source_principal = infcx.instantiate_binder_with_fresh_vars( DUMMY_SP, BoundRegionConversionTime::HigherRankedType, hr_source_principal, ); let Ok(()) = ocx.eq_trace( &ObligationCause::dummy(), ty::ParamEnv::reveal_all(), ToTrace::to_trace( &ObligationCause::dummy(), hr_target_principal, hr_source_principal, ), target_principal, source_principal, ) else { return false; }; if !ocx.select_all_or_error().is_empty() { return false; } infcx.leak_check(universe, None).is_ok() }) } (None, None) => true, _ => false, } } </ins> /// Retrieves the information we are losing (making dynamic) in an unsizing /// adjustment. ///

Discussion:
I believe this is caused by . Does that look like anything to you? This doesn't seem to happen with the dist artifacts, only the settings used when testing in CI. The config used in CI is: EDIT: Almost certainly since it comes from . This is causing the reference test suite to fail. Using which is currently unreleased.
Yeah, it's a debug assertion after all. I'll look into it and relax the assertion
Change:
<ins> use std::ops::Index; struct Test; struct Container(Test); impl Test { fn test(&mut self) {} } impl<'a> Index<&'a bool> for Container { type Output = Test; fn index(&self, _index: &'a bool) -> &Test { &self.0 } } fn main() { let container = Container(Test); let mut val = true; container[&mut val].test(); //~ ERROR: cannot borrow data } </ins>

Discussion:
The compiler ices with error "Failed to unify obligation" when I try to compile the following code: I get the following error: : Backtrace:
Another version:
triage: p-medium
minimal version Note that if you pass in the closure to it doesn't ICE the compiler when I used , bud did ICE the compiler when I used /. i.e.
none of the programs provided seem to ICE with the latest nightly.
Change:
<ins> // run-rustfix #![allow(unused, nonstandard_style)] mod m { mod p { #[macro_export] macro_rules! nu { {} => {}; } pub struct other_item; } use ::nu; pub use self::p::{other_item as _}; //~^ ERROR unresolved import `self::p::nu` [E0432] //~| HELP a macro with this name exists at the root of the crate } fn main() {} </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. If you cannot produce a minimal reproduction case (something that would work in isolation), please provide the steps or even link to a repository that causes the problematic output to occur. --Given the following code: The current output is: <details<summaryIf the starting order is reversed, the suggestion puts the macro first in the tree</summary</detailsThis is suggesting to change the code to itself It needs to move the import into a tree; the easy way is to make a new statement (and let rustfmt clean that up); the medium way is to find an existing context; the hard way is when a tree root doesn't already exist (or isn't immediately a tree at that point) determine what the code is using and match that. Related: label +D-confusing +D-incorrect
In this case, the ideal solution is actually to write just and get the import from legacy-lexical-macro-scope into the namespace. I originally hit this with just multiple macros in the use tree, and removing the was the correct fix. I "simplified" for the error report to use a second non-macro item here (to reduce the number of diagnostics). So bonus challenge: handle this case properly and only emit a single help: <details
label +D-invalid-suggestion It's not producing invalid code, but it's surely suggesting a fix which will cause an error (the identical one).
Change:
// This place is not really used because this destination place // should never be used to take values at the end of the failure // block. <del> let dummy_place = Place { local: RETURN_PLACE, projection: ty::List::empty() }; </del> <ins> let dummy_place = self.temp(self.tcx.types.never, else_block.span); </ins> let failure_block; unpack!( failure_block = self.ast_block(

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
On a side note this is valid and compiles:
Yeah, this is very likely due to expr either not being recorded correctly when type-checking , or those not being used correctly when building MIR for . I will look into this later.
Minimized this a tiny bit: Still working on it though. Unrelated to try-blocks.
Change:
ty: cx.tcx.mk_opaque(def_id, ty::InternalSubsts::identity_for_item(cx.tcx, def_id)), proj_ty: proj_term, assoc_pred_span, <del> suggestion, suggest_span, </del> <ins> add_bound, </ins> }, ); }

Discussion:
Note: Switching back to 1.65 compiles fine : </p</details
label +E-needs-mcve
Sorry for the noise on this issue, but I just realized what I had done which apparently got around this issue. I fixed a new warning in my web server library by turning this.. into this
I caused this. Let me put up a fix.
Change:
"impl has stricter requirements than trait" ); <del> if let Some(span) = self.tcx.hir().span_if_local(trait_item_def_id) { let item_name = self.tcx.item_name(impl_item_def_id.to_def_id()); err.span_label(span, format!("definition of `{}` from trait", item_name)); </del> <ins> if !self.tcx.is_impl_trait_in_trait(trait_item_def_id) { if let Some(span) = self.tcx.hir().span_if_local(trait_item_def_id) { let item_name = self.tcx.item_name(impl_item_def_id.to_def_id()); err.span_label(span, format!("definition of `{}` from trait", item_name)); } </ins> } err.span_label(error_span, format!("impl has extra requirement {}", requirement));

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
cc
This brings up the question again with whether or not we should just feed itemname for RPITITs. I can't recall the other issues where this was a problem, but perhaps we should just do that and revert all the previous mitigations we introduced due to the fact that itemname is missing for RPITITs.
Just pushed a fix, I think you were always right about not feeding item_name, whenever you try to call it for RPITITs we should have never tried because the message we are trying to fill won't make any sense.
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. trait Trait1<'l0, T0> {} trait Trait0<'l0>  {} impl <'l0, 'l1, T0> Trait1<'l0, T0> for bool where T0 : Trait0<'l0>, T0 : Trait0<'l1> {} //~^ ERROR type annotations required: cannot resolve `T0: Trait0<'l0>` //~^^ NOTE required by `Trait0` fn main() {} </ins>

Discussion:
The following causes an ICE: Backtrace: With: I can confirm that this bug has been around since 1.0.0-alpha (though with a slightly different assertion violation; I accidentally posted that version originally).
Removing either constraint in the clause, or changing the lifetimes used in the clause to be the same causes the ICE to go away.
I guess we should change that error message to be different from "coherence failed to report ambiguity" to "trait selection failed". Your use-case isn't currently supported (). Not sure which error message to give, through.
A couple more examples of this (including a nightly regression) can be found in
With rustc 1.7.0, 1.8.0 and 1.9.0, the example fails to compile, but don't generate an ICE.
Added a regression test in
It's been awhile since I reported this and I'm woefully out of the loop on Rust development at this point, but I'm not fully understanding the fix. The current error message is that additional type annotations are required, but my understanding of the original problem is that this is a fundamental limitation of the typechecker. Is there a way to add in more type annotations here to make this compile? I tried playing around with this a bit, but I wasn't able to come up with anything concrete.
you're not wrong, the error message is poor.
it's a limitation of the existing solver, anyway. (also, sorry for the like 2+ year gap here :) just happened to be looking at this issue)
thanks for the clarification, hello, and no problem! :)
Change:
> **Note:** This list is likely to become out of date. We should auto-generate it > from `librustc/middle/lang_items.rs`. <ins> ### Deriving The `deriving` attribute allows certain traits to be automatically implemented for data structures. For example, the following will create an `impl` for the `Eq` and `Clone` traits for `Foo`, the type parameter `T` will be given the `Eq` or `Clone` constraints for the appropriate `impl`: ~~~ #[deriving(Eq, Clone)] struct Foo<T> { a: int, b: T } ~~~ The generated `impl` for `Eq` is equivalent to ~~~ # struct Foo<T> { a: int, b: T } impl<T: Eq> Eq for Foo<T> { fn eq(&self, other: &Foo<T>) -> bool { self.a == other.a && self.b == other.b } fn ne(&self, other: &Foo<T>) -> bool { self.a != other.a || self.b != other.b } } ~~~ Supported traits for `deriving` are: * Comparison traits: `Eq`, `TotalEq`, `Ord`, `TotalOrd`. * Serialization: `Encodable`, `Decodable`. These require `std`. * `Clone`, to perform deep copies. * `IterBytes`, to iterate over the bytes in a data type. * `Rand`, to create a random instance of a data type. * `ToStr`, to convert to a string. For a type with this instance, `obj.to_str()` has the same output as `fmt!("%?", obj)`. </ins> # Statements and expressions Rust is _primarily_ an expression language. This means that most forms of

Discussion:
As far as i see it, "deriving" is documented neither in the tutorial nor in the manual. Example:
Change:
let ty = instance.ty(cx.tcx); let sym = cx.tcx.symbol_name(instance).as_str(); <ins> debug!("get_static: sym={} instance={:?}", sym, instance); </ins> let g = if let Some(id) = cx.tcx.hir.as_local_node_id(def_id) { let llty = cx.layout_of(ty).llvm_type(cx);

Discussion:
For example: This can be a little more clearly seen with the IR generated for main: Note the lack of anywhere on .
Triage: this is still true today, though needs to be updated to , and there's now a warning about not being a valid foreign type, which is irrelevant to this particular issue.
claims it repros still.
Updated test code: Still fails to compile with the same errors mentioned in the top post along with the irrelevant invalid foreign type warning mentioned by
Change:
<ins> // Regression test for issue #91370. extern { //~^ `extern` blocks define existing foreign functions fn f() { //~^ incorrect function inside `extern` block //~| cannot have a body impl Copy for u8 {} } } fn main() {} </ins>

Discussion:
I'm seeing an internal compiler error on the following input, found by : Affected versions: I tried nightly 2021-11-28 and stable 1.56.1 and they both ICE. In stable 1.56.1 the error message is different though, I would say it's better: <details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
In one of the recent nightlies the error message has changed to <details<summary<strongBacktrace</strong</summary<p</p</details
Change:
/// The rust-demangler executable. pub rust_demangler_path: Option<PathBuf>, <del> /// The Python executable to use for LLDB. pub lldb_python: String, /// The Python executable to use for htmldocck. pub docck_python: String, </del> <ins> /// The Python executable to use for LLDB and htmldocck. pub python: String, </ins> /// The jsondocck executable. pub jsondocck_path: Option<String>,

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:
LL +     consume(7); | <del> warning: 5 warnings emitted </del> <ins> warning: unnecessary braces around `return` value --> $DIR/unused_braces.rs:55:12 | LL |     return { println!("!") }; |            ^^             ^^ | help: remove these braces | LL -     return { println!("!") }; LL +     return println!("!"); | warning: 6 warnings emitted </ins>

Discussion:
The false negative bisects to , so pretty obviously . FYI From skimming , that's an issue about const generics. It doesn't seem like the PR was supposed to have affected unused_braces situations outside of const generics position.
Change:
write!(w, "</table>") } <ins> struct Initializer<'a>(&'a str); impl<'a> fmt::Show for Initializer<'a> { fn fmt(&self, f: &mut fmt::Formatter) -> fmt::Result { let Initializer(s) = *self; if s.len() == 0 { return Ok(()); } try!(write!(f, "<code> = </code>")); write!(f, "<code>{}</code>", s.as_slice()) } } fn item_constant(w: &mut fmt::Formatter, it: &clean::Item, c: &clean::Constant) -> fmt::Result { try!(write!(w, "<pre class='rust const'>{vis}const  {name}: {typ}{init}</pre>", vis = VisSpace(it.visibility), name = it.name.as_ref().unwrap().as_slice(), typ = c.type_, init = Initializer(c.expr.as_slice()))); document(w, it) } fn item_static(w: &mut fmt::Formatter, it: &clean::Item, s: &clean::Static) -> fmt::Result { try!(write!(w, "<pre class='rust static'>{vis}static {mutability} {name}: {typ}{init}</pre>", vis = VisSpace(it.visibility), mutability = MutableSpace(s.mutability), name = it.name.as_ref().unwrap().as_slice(), typ = s.type_, init = Initializer(s.expr.as_slice()))); document(w, it) } </ins> fn item_function(w: &mut fmt::Formatter, it: &clean::Item, f: &clean::Function) -> fmt::Result { try!(write!(w, "<pre class='rust fn'>{vis}{fn_style}fn 

Discussion:
Here's what I think is wrong: keywords , and appear next to the name of the constant, when clearly they are redundant. the constants page through search brings the user to an empty page. value assigned to the constant appears along side its name. When reading the documentation of constants, the most important information is the name of the constant and its description. Having the declaration appear inline makes scanning for the name of harder. Better output would replace the declaration with the name of the constant followed by its type. Also it would move the declaration of the constant to the empty page mentioned in point 2 and have the identifier of the constant link to this page. All these points are relevant for statics as well. Example of ugly output: ! This page should show the definition and a description of the constant: !
Change:
file: &rustc_span::SourceFile, defining_crate: CrateNum, ) -> &'ll DILexicalBlock { <del> let file_metadata = file_metadata(cx, &file.name, defining_crate); </del> <ins> let file_metadata = file_metadata(cx, &file, defining_crate); </ins> unsafe { llvm::LLVMRustDIBuilderCreateLexicalBlockFile(DIB(cx), scope_metadata, file_metadata) } }

Discussion:
shows a pretty big regression between and . I don't know if this is expected, but I'm putting this out there in case others see the dent in perf charts and wonder what had happened. <hr/EDIT( we how have a for . , the other PR in the range, (but only for a small subset of runs).
cc
The range is so the candidates are: "Make the rustc respect the flag in incremental mode." "Add hash of source files in debug info" EDIT: oops, missed - so it's likely . Slow MD5 implementation? I'm curious, why does (merge commit for ) not have its own perf run? Is there a way to trigger one now?
is in the queue:
It looks like this was caused by . I'll start investigating why. I timed several compilations of locally in debug with and without .
For the record, from . I'll update the issue description to minimize potential confusion. Two things I'm seeing: are way worse regressions than , you can focus on the worse ones to get better contrast in measurements (e.g. even has "patched incremental" runs slowed down a lot, unlike many others, being another example I guess) detailed profile (if you click the percentage for a run) shows a lot of LLVM differences, e.g. for , and most of the regressions are , with effectively no ones, so I think we might be able to get away without a revert, just adding a flag controlling whether LLVM sees these hashes (assuming that's the source of the slowdown)
We have (), which at a glance looks right. looks like noise, and so does , so I believe this confirms the fix is complete. For the cost of MD5 hashing compared to SipHash, based on the changes to runs in the original regression, it looks insignificant.
Change:
let attrs = test::parse_attributes(source); assert parse_hidden(attrs) == false; } <ins> #[test] fn should_concatenate_multiple_doc_comments() { let source = ~"/// foon/// bar"; let desc = parse_desc(test::parse_attributes(source)); assert desc == Some(~"foonbar"); } </ins>

Discussion:
If document strings for rustdoc are written as a sequence of single line comments (i.e. ///) then rustdoc only uses the first line. The whole sequence should be joined to form a single attribute for further processing.
I would be happy to have a look at this (I guess maybe I caused the issue).
It seems like one way to fix this issue would be to have rustdoc concatenate all doc-attributes/doc-comments for an item and use the concatenated text as if it were from a single doc-attribute/comment. Currently rustdoc discards all but the first doc-attribute, and emits a warning that the others were discarded. However the warning is emitted using warn!(...) which means it doesn't actually display to the user unless they have turned on warn logging for rustdoc, which seems unlikely. Would this approach (concatenating all doc-comments) be ok?
Another approach would be to change the lexer so that it parses multiple adjacent lines that all start with /// as a single doc-comment.
Having rustdoc concatenate the attributes sounds good to me.
You're right, I ran rustdoc without warnings being logged. Are you referring to fn docmeta in That looks like it would be a sensible place to do the concatenation.
Yup. See the pull request - it makes multi-line comments work the same as comments (as a side effect of concatenating all kinds of doc-comment). Unfortunately multi-line comments seem a bit broken in general with rustdoc. In html output mode they are concatenated into a single line (I think due to some weirdness with pandoc).
Fixed by
Change:
ifdef CFG_ENABLE_DEBUG $(info cfg: enabling more debugging (CFG_ENABLE_DEBUG)) <del> CFG_RUSTC_FLAGS += </del> <ins> CFG_RUSTC_FLAGS += --cfg debug </ins> CFG_GCCISH_CFLAGS += -DRUST_DEBUG else CFG_GCCISH_CFLAGS += -DRUST_NDEBUG

Discussion:
says: "It's easy to add, in under 'ifdef CFGENABLEDEBUG'". If this happens, we also need to consider the build; i.e., make the bots use that flag sometimes.
Change:
match it.kind { hir::ItemKind::Fn(..) => tcx.ensure().fn_sig(def_id), hir::ItemKind::OpaqueTy(..) => tcx.ensure().item_bounds(def_id), <ins> hir::ItemKind::Const(ty, ..) | hir::ItemKind::Static(ty, ..) => { // (#75889): Account for `const C: dyn Fn() -> _ = "";` if let hir::TyKind::TraitObject(..) = ty.kind { let mut visitor = PlaceholderHirTyCollector::default(); visitor.visit_item(it); placeholder_type_error(tcx, None, &[], visitor.0, false, None); } } </ins> _ => (), } }

Discussion:
I'll jump straight into the minimum verifiable example: Try it out . Here is the standard error output: Being a complete beginner I don't really know what I can add to this report, and I have a workaround which I can use to avoid this problem. (I know what I can put in the place of ) Edit: () gives which seems not ideal.
Assigning as and removing .
There is a partial fix in , though it regresses diagnostics. I think it ought not to be too much work to address this, but I do not have time at the moment.
This ICEs since . modify labels: +regression-from-stable-to-stable
Change:
endif CFG_LIB_NAME_x86_64-apple-ios = lib$(1).a CFG_LIB_GLOB_x86_64-apple-ios = lib$(1)-*.a <del> CFG_LIB_SKIP_INSTALL_x86_64-apple-ios = 1 #lib$(1)-*.a </del> <ins> CFG_INSTALL_ONLY_RLIB_x86_64-apple-ios = 1 </ins> CFG_STATIC_LIB_NAME_x86_64-apple-ios=lib$(1).a CFG_LIB_DSYM_GLOB_x86_64-apple-ios = lib$(1)-*.a.dSYM CFG_CFLAGS_x86_64-apple-ios := $(CFG_IOSSIM_FLAGS_x86_64-apple-ios)

Discussion:
Full gist:
cc
cc since you've been contributing iOS patches. This same error still repros after with: Are you able to successfully build a cross-compiler?
there are 2 different things: building and installing. What fails is phase and I believe I have kind of dirty hack for it in my fork, but will try to find a correct solution and issue PR soon.
this one ?
yep
cool, would you mind submitting that PR?
since PR is going to be open for a while considering current bors queue, I have to mention that in general when you need up-to-date Rust for iOS you can either built it by yourself from or use a prebuilt version from It may lag a bit (usually <= 1 day) but it is guaranteed to build (as iOS is not on Rust official buildbots and master is broken sometimes).