jiebi/CodeConvo huggingface dataset:
Change:
"compile-fail | run-fail | run-pass-valgrind | pretty | debug-info | codegen | rustdoc  codegen-units | incremental | run-make | ui | js-doc-test | mir-opt | assembly", ) <ins> .reqopt( "", "suite", "which suite of compile tests to run. used for nicer error reporting.", "SUITE", ) </ins> .optopt( "", "pass",

Discussion:
When compiletest fails, it prints an error summary like this at the end: However, there is one very important bit of information that I cannot gleam from this information: what are the host and target architectures that were tested! Figuring this out requires scrolling up quite a bit to where this test beings (and carefully not scrolling up too far because then one might look at the wrong test). See for an example where this confused people. I have also been confused by this multiple times in the past, e.g. using the name of the CI runner to incorrectly deduce what the architecture(s) are (and not realizing that some of our runners run tests for quite a few different targets). So I think in case of a failure, that summary at the end should repeat the important information that is printed at the top of the test run:
Cc
And also it would be nice if when it ignored a test because it was the wrong platform, it showed some indication of that, because otherwise it looks like it ran the test and it passed. Perhaps show a question mark ()? (We already use for tests that were ignored because they were already run and passed.)
AFAIK should already be used for all kinds of "ignored", including directives.
Turns out these messages are printed by bootstrap, not compiletest: However, detecting failures and exiting is done a few layers deeper: In case of failure, never returns or unwinds (except if fail-fast is off). I am not sure how to best adjust this to print an error before exiting (or to always print an error after the process finished, whether it succeeded or failed). any advice? If we just want this to happen when fail-fast is off, that would be easy, but I am not sure if that ever applies.
Change:
<ins> // run-pass #![feature(const_evaluatable_checked)] #![feature(const_generics)] #![allow(incomplete_features)] trait Foo {} impl<const N: usize> Foo for [(); N] where Self: FooImpl<{ N == 0 }> {} trait FooImpl<const IS_ZERO: bool> {} impl FooImpl<{ 0u8 == 0u8 }> for [(); 0] {} impl<const N: usize> FooImpl<{ 0u8 != 0u8 }> for [(); N] {} fn foo<T: Foo>(_v: T) {} fn main() { foo([]); foo([()]); } </ins>

Discussion:
Successor of and . This code: Gives this error message (on nightly): It'd be great if this could work so that you can implement a trait differently for different values of type parameters. cc who suggested to open a new issue for this.
background: his error was introduced in as the previous state was unsound, see
With this test is now working as expected. Marking as .
if I try this: I get this error: Using the nightly from playground
you need full for this, we should probably add a note here which recommends using and here.
alright that works. I'll file a PR
Change:
vis: Visibility, attrs: Vec<Attribute> ) -> PResult<'a, StructField> { <ins> let mut seen_comma: bool = false; </ins> let a_var = self.parse_name_and_ty(lo, vis, attrs)?; <ins> if self.token == token::Comma { seen_comma = true; } </ins> match self.token { token::Comma => { self.bump(); } token::CloseDelim(token::Brace) => {} token::DocComment(_) => { <ins> let previous_span = self.prev_span; </ins> let mut err = self.span_fatal_err(self.span, Error::UselessDocComment); self.bump(); // consume the doc comment <del> if self.eat(&token::Comma) || self.token == token::CloseDelim(token::Brace) { </del> <ins> let comma_after_doc_seen = self.eat(&token::Comma); // `seen_comma` is always false, because we are inside doc block // condition is here to make code more readable if seen_comma == false && comma_after_doc_seen == true { seen_comma = true; } if comma_after_doc_seen || self.token == token::CloseDelim(token::Brace) { </ins> err.emit(); } else { <ins> if seen_comma == false { let sp = self.sess.codemap().next_point(previous_span); err.span_suggestion(sp, "missing comma here", ",".into()); } </ins> return Err(err); } }

Discussion:
I had this code: The actual error of course here, would be that there is a missing comma after the . However the error message given by the compiler was: error: expected , or , found -- | 16 | #[doc = "The id of the parent core"] | ^ | = help: struct fields should be separated by commas This isn't a particularly important issue, but as mentioned by someone I spoke to regarding this error, the error messages given by the compiler are usually very helpful, and I feel it is worth maintaining this standard.
to fix this, should emit the error for a useless doc comment and a missing comma / brace if it encounters both - right now doc comment errors override missing seperators completely. attributes work fine because they are not parsed as a single doc comment token.
Can I take this one if nobody is working on that?
go ahead! Feel free to ask for help if you need. If this is your first contribution, take a look at for setting up the environment.
, Now console output is coming like this Now I have three quick questions for you. 1) In the case when a is missing for middle fields of , should we avoid showing warning, because we have not parsed below fields yet? 2) Should I consider creating a new entry in enum to handle warning? 3) If we have decided to show both and warning, how important it is to show missing warning before warning?
I would elide the missing comma error. Create a PR with in its body so that I'm assigned as reviewer and we can discuss in the context of the code. It seems like you're in the right path. Depending on how the code is laid out, you might be able to try to consume a without failing if it isn't there depending on the success or failure of the previous field.
PR raised
Change:
fragment: Option<Range<Size>>, ); fn set_dbg_loc(&mut self, dbg_loc: Self::DILocation); <ins> fn clear_dbg_loc(&mut self); </ins> fn insert_reference_to_gdb_debug_scripts_section_global(&mut self); fn set_var_name(&mut self, value: Self::Value, name: &str); }

Discussion:
<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. --I tried this code: Setting a breakpoint on in rust-gdb results in gdb stopping before 's stack slot is initialized, and gdb dereferences it to print wrong values based on : Note the incorrect different values of as I step past initialization. The breakpoint should trigger just after that , not before it. The other functions in that program indeed do it correctly. Oddly, it seems like the operator is necessary for my repro, though maybe that has something to do with the hidden var. (Note that vs is necessary to actually avoid accidental correct values of due to stack reuse, so the other functions can't print wrong as written. But I'm just looking at where the breakpoint hits in disassembly.) Here's relevant llvm-dwarfdump from this binary, with a pointing at at the () rather than the : This looks pretty related to and Like , the repro hits on 1.71 but not 1.70. I'm filing separately because, unlike it, disabling SingleUseConsts doesn't seem to fix the breakpoint. I'm not 100% sure I'm disabling it right - you can see my command above. <!-- 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<summaryBacktrace</summary<p</p</details
I'm not familiar with github's notification rules, so pinging
Thanks for the tag, I wouldn't have seen this otherwise. From , we can see that the "prologue end" marker that tells the debugger where to stop is indeed placed on the mov I suspect this is due to the desugaring of the ? operator since the column number provided is 29.
label +A-debuginfo
Sure enough, ConstDebugInfo is in there.
I guess you probably saw, but does suggest that the bisect is somehow misleading.
Yes, getting the values wrong at function entry is especially bad because it messes up conditional breakpoints.
Disabling the pass doesn't do anything here because the is created by when it removes . Otherwise this is identical to .

The easiest way to fix this would be for DILocation to carry a "this is not a statement" flag that overrides LLVM's usual line based inference of statement markers. I'll run it by the LLVM folks and see what they say.
Actually, in this particular case, because the const is a ZST I think we can do better today without LLVM changes.
Thanks for reporting this. The linked PR will fix this particular degenerate case.
Change:
}); if (found === true) { styleElem.href = newHref; <del> // If this new value comes from a system setting or from the previously // saved theme, no need to save it. if (saveTheme === true) { updateLocalStorage("rustdoc-theme", newTheme); } </del> } }

Discussion:
Repro: Clear local-storage for Set system theme to light Visit change theme to Visit note that the theme has been set to following the system Visit see that the theme changes back to because the stored theme was never updated Visit then change the system theme to dark, updating the displayed theme to , and then change the system theme back to light, updating the displayed theme to Visit see that the theme is now because the stored theme was updated This affects the plan we have for to follow rustdoc's theme setting, , I assumed that rustdoc would update the stored theme whenever it changes so we could synchronize off that. Missing the initial setting based on the fact that is the "default" theme loaded before the JS runs seems like a bug. cc
Error: Label rustdoc-ui can only be set by Rust team members Please let know if you're having trouble with this bot.
I'll implement this
Change:
let ty = self.typeck_results.borrow().expr_ty_adjusted(expr); let ty = self.resolve_vars_if_possible(ty); if ty.has_non_region_infer() { <del> assert!(self.is_tainted_by_errors()); </del> self.tcx.ty_error() } else { self.tcx.erase_regions(ty)

Discussion:
Found by mutating with a <details<summary<strongFull output including backtrace</strong</summary<p</p</detailsnightly-2022-05-28: changed from no ICE to ICE "index out of bounds" Most likely for the same reason as nightly-2022-07-13: changed from ICE "index out of bounds" to ICE "assertion failed: self.istaintedbyerrors()" From something in , most likely label +A-inline-assembly <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
That assertion is probably unnecessarily strict, since doesn't check that errors are emitted from other items anyways. Instead, it can probably be turned into a delayed bug or just removed altogether, since already delays a bug.
claim
Change:
// Mark all dynamic libraries and executables as compatible with ASLR // FIXME #17098: ASLR breaks gdb <del> // cmd.arg("-Wl,--dynamicbase"); </del> <ins> if sess.opts.debuginfo == NoDebugInfo { cmd.arg("-Wl,--dynamicbase"); } </ins> // Mark all dynamic libraries and executables as compatible with the larger 4GiB address // space available to x86 Windows binaries on x86_64.

Discussion:
This should be as simple as passing to the linker for both libraries and executables. However, the necessary relocations are never generated by MinGW or MinGW-w64 for executables so nothing is actually randomized without also passing . The switch is also broken and results in a messed up entry point, but it may not actually be required.
Hi, I found this issue while looking for an old reference, but I thought you might be interested in a possible fix. We needed for Tor's hardening options and after some back and forth settled on a working binutils patch which is here (works for 2.24 and is being submitted upstream shortly): This patch has not been reviewed at all, since no one at Tor feels sufficiently capable. Hopefully the binutils folks will have something to say, but as language developers you might too. (edit: fix link to patch)
We ended up working around it for the time being by doing a dllexport of main in order to force it to output a relocation section, since the executable counts as a library. I would really like to have this fixed properly though so I'll look into it some more when I have time.
Needs to be disabled again due to .
Note that recent binutils may have support for high entropy ASLR. ( was accepted last year. See ) It would be good to check if mingw-w64 would contain the patch when we re-enable ASLR.
Triage: not sure if anything has changed here, but I don't think so.
Triage: same as in 2016
Change:
/// let s = "hello".to_string(); /// is_hello(s); /// ``` <ins> /// /// # Generic Impls /// /// - `From<T> for U` implies `Into<U> for T` /// - `into()` is reflexive, which means that `Into<T> for T` is implemented /// </ins> #[stable(feature = "rust1", since = "1.0.0")] pub trait Into<T>: Sized { /// Performs the conversion.

Discussion:
Part of Here's what needs to be done to close out this issue: is great, but has a lot of abbreviations, so the wording could be cleaned up a bit. should compare itself to , and should show a sample implementation. needs far better docs, as it is one of the most misunderstood traits in Rust. Specifically it should talk about its relationship with . It also needs an example implementation. needs a lot of work; it should talk about its usage in , it should show an example implementation, and general improvement. is mostly fine, but "generic impls" should say "implementations" and it should be above examples.
I am happy to mentor anyone who wants to tackle this issue.
I would be keen to give this one a go I'm interested in understanding this section better.
Awesome, ! Let me know if I can help you help me in any way
Hey , Just a couple of questions: the issue description for the trait you say to have the generic implementations above the examples, It turns out all of the traits have the examples above the generic implementations. Should I move the generic implementations above the examples for all of the traits? adding sample implementation do you like to make a generic example or use a common example from the std lib? I only ask because I have become familiar with through the usage within the package in creating paths and was thinking of using this as an example. What are your thoughts? relationship with is where I am having a bit of trouble explaining this concisely. Are we wanting to have a brief summarization of the section in the book and do we need to reciprocate or align with the documentation for the trait? I only ask as I feel to explain the difference I am describing the trait a bit and do not want to introduce a second differing description. Thanks :smile:
Hey ! Yes, that'd be great! Ideally, we'd have both: one extremely simple example for people to be able to copy/paste, and one more realistic example. Feel free to submit one or both yes it's tough! The second edition of the book does not have that chapter; synchronizing these API docs is the right way to go
OK great :smile: I will hopefully have something in today to start picking apart.

:+1:
Hey , I had a look at the [RFC] mentioned in the contribution guide and couldn't find anything on the guidelines for line length. I only ask as one of the Travis builds failed due to the line exceeding 100 chars, so was wondering what I should be aiming for. Thanks again! :smile: [RFC]:
Standard library docs are wrapped to 80 characters. :)
This is now done!
Change:
let target = self.target; assert!(builder.config.extended); <ins> /* run only if llvm-config isn't used */ if let Some(config) = builder.config.target_config.get(&target) { if let Some(ref _s) = config.llvm_config { builder.info(&format!("Skipping LlvmTools stage{} ({}): external LLVM", stage, target)); return None; } } </ins> builder.info(&format!("Dist LlvmTools stage{} ({})", stage, target)); let src = builder.src.join("src/llvm"); let name = pkgname(builder, "llvm-tools");

Discussion:
since , Rust failed to package properly when LLVM is configured as external dependency (with explicit in ) the error is because buildrust tries to copy: to . But as LLVM was external, the directory is empty. I think there is two possibilities: doesn't package llvm-tools componment if LLVM is external package it, but uses the right directory I will make a PR if someone told me the direction to take.
I think we should probably package it, cc
I'd personally err on the side of skipping it, if we try to package it we're gonna have to deal with a whole array of local installs and filenames, and it's not actually used anyway
Change:
<ins> // issue#121613 #![feature(more_qualified_paths)] struct S {} struct Foo; trait A { type Assoc; } impl A for Foo { type Assoc = S; } fn f() {} fn main() { <Foo as A>::Assoc {}; f(|a, b| a.cmp(b)); //~^ ERROR: type annotations needed //~| ERROR: this function takes 0 arguments but 1 argument was supplied } </ins>

Discussion:
<!-- [31mICE[0m: Rustc '' 'thread 'rustc' panicked at 'range end index 1 out of range for slice of length 0'', 'thread 'rustc' panicked at 'range end index 1 out of range for slice of length 0'' 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<!-- query stack: [typeck] type-checking [analysis] running analysis passes on this crate --
Regression in nightly-2022-06-04 commit[0] 2022-06-02: Auto merge of - nnethercote:lazify-SourceFile-lines, r=Mark-Simulacrum commit[1] 2022-06-02: Auto merge of - spastorino:simplify-universal-impl-trait-lowering, r=cjgillot commit[2] 2022-06-03: Auto merge of - matthiaskrgr:rollup-5cfxc85, r=matthiaskrgr commit[3] 2022-06-03: Auto merge of - c410-f3r:z-errors, r=petrochenkov commit[4] 2022-06-03: Auto merge of - cjgillot:remove-label-lt-shadow, r=petrochenkov commit[5] 2022-06-03: Auto merge of - Dylan-DPC:rollup-nswmgmx, r=Dylan-DPC commit[6] 2022-06-03: Auto merge of - lcnr:path-generics-diagnostics, r=estebank commit[7] 2022-06-03: Auto merge of - Dylan-DPC:rollup-2yxo7ce, r=Dylan-DPC commit[8] 2022-06-03: Auto merge of - bjorn3:serde_json, r=wesleywiser commit[9] 2022-06-03: Auto merge of - notriddle:notriddle/human-readable-signals, r=yaahc ERROR: no CI builds available between and within last 167 days
It appears I'm hitting this one as well. Tacking this on for good measure. <details</details
Looks like it was originally introduced by (and was renamed later to without any change in functionality). I'd PR a fix but I'm not entirely sure how it's supposed to work. Is this masking a deeper bug or can one simply do something like: Derp, missed there was a PR. indeed fixes this on my end. Thanks for the quick fix on this!
Change:
# versions (section 9) CFG_PRERELEASE_VERSION=.1 <del> CFG_FILENAME_EXTRA=4e7c5e5c </del> <ins> # Append a version-dependent hash to each library, so we can install different # versions in the same place CFG_FILENAME_EXTRA=$(shell printf '%s' $(CFG_RELEASE) | $(CFG_HASH_COMMAND)) </ins> ifeq ($(CFG_RELEASE_CHANNEL),stable) # This is the normal semver version string, e.g. "0.12.0", "0.12.0-nightly"

Discussion:
This value has not changed in a long time, but to support sxs installation in a single dir it needs to. It should just be hashed from the value of .
So should we pipe the value through e.g. md5sum? That could be awkward on BSDs, where the hash programs have a . I think we can patch over the differences by adding a check to the configure script. Something like this: then in the Makefile we have: But if there's a simpler way then I'm all ears.
Change:
fn should_trans_locally<'a, 'tcx>(tcx: TyCtxt<'a, 'tcx, 'tcx>, def_id: DefId) -> bool { <ins> if let ty::TyFnDef(_, _, f) = tcx.item_type(def_id).sty { if let Some(adt_def) = f.sig.output().skip_binder().ty_adt_def() { if adt_def.variants.iter().any(|v| def_id == v.did) { // HACK: ADT constructors are translated in-place and // do not have a trans-item. return false; } } } </ins> if def_id.is_local() { true } else {

Discussion:
Not on 1.15. cc
Fun note: another bug fixed on my shimmir branch. Not that I really want to merge it to 1.16/1.17.
Minified: I think we should just have the first commit of shimmir to fix this.
triage: P-high
Change:
// check-pass <ins> // compile-flags: -Zvalidate-mir // Using -Zvalidate-mir as a regression test for #107346. </ins> trait Duh {}

Discussion:
[ ] Previous Stable [ ] Current Stable [ ] Current Beta [ ] Current Nightly No response
searched toolchains through Regression in
I wonder if this is cc ?
very likely :thinking: will revert if we don't figure out how to fix this in the near future
<details<summarycompiler logs</summary</detailsedit: my bad I'm experiencing
WG-prioritization assigning priority (). label -I-prioritize +P-medium
bisection tested with , seems to point to commit searched nightlies: from nightly-2023-01-15 to nightly-2023-02-09 regressed nightly: nightly-2023-01-27 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.5</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </detailsit's a rollup of:
I already bisected this one (see second comment :D) any should we revert now? it's still ICEing
yeah, wanted to revert this since looking at this a few days ago :sweat_smile: but for that I want to update the comment for why we're avoiding opaque types which is effort, so I've put it off for a while. Should get to it over the next few days
Change:
<ins> //! This test used to ICE because, while an error was emitted, //! we still tried to remap generic params used in the hidden type //! to the ones of the opaque type definition. //@ edition: 2021 #![feature(type_alias_impl_trait)] use std::future::Future; type FutNothing<'a> = impl 'a + Future<Output = ()>; //~^ ERROR: unconstrained opaque type async fn operation(_: &mut ()) -> () { //~^ ERROR: concrete type differs from previous call(operation).await } async fn call<F>(_f: F) where for<'any> F: FnMut(&'any mut ()) -> FutNothing<'any>, { //~^ ERROR: expected generic lifetime parameter, found `'any` } fn main() {} </ins>

Discussion:
<!-- [31mICE[0m: Rustc '--edition=2021 -ooutputfile -Zdump-mir-dir=dir' 'error: internal compiler error: unexpected region kind in opaque type: RePlaceholder(!2BoundRegion { var: 0, kind: BrNamed(DefId(0:12 ~ 9DABD1FCA6B4214B1AFB7E3E0DCCB52B1F226FCDBDC62026B721AA5FB17BF76D[c411]::call::'any), 'any) })', 'error: internal compiler error: unexpected region kind in opaque type: RePlaceholder(!2BoundRegion { var: 0, kind: BrNamed(DefId(0:12 ~ 9DABD1FCA6B4214B1AFB7E3E0DCCB52B1F226FCDBDC62026B721AA5FB17BF76D[c411]::call::'any), 'any) })' 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<!-- query stack: [mirborrowck] borrow-checking [mirborrowck] borrow-checking [typeofopaque] computing type of opaque [typeof] computing type of [checkwellformed] checking that is well-formed [checkmodtypewf] checking that types are well-formed in top-level module [analysis] running analysis passes on this crate --
cc could be related to
yea I have just locally started hitting this in tests/ui/impl-trait/impl-fn-predefined- while rebasing