jiebi/CodeConvo huggingface dataset:
Change:
/// ``` /// /// ``` <del> /// #![feature(once_is_completed)] </del> /// use std::sync::Once; /// use std::thread; ///

Discussion:
Implemented in
The documentation needs to be made slightly more strict. For example: Should be replaced with The distinction is important, because at the exact moment this function returns might already be executed/resolved, without it necessarily happening “immediately after”. To avoid people shotgunning their feet off, I would suggest to add some guidance on how this should be used. For example, doing something useful based on this function returning a is somewhat likely to be a bug. And yet, examples do not really result in such an impression.
CC for nagisa’s comment above.
It's been 9 months since this was implemented. Can this be stabilized now?
Is there anything preventing this method from being stabilized? It looks like there was some bikesheding in but it's now been just past a year since initial adoption.
Note that I am personally no longer directly interested in having this method: in , I ended-up copy-pasting the whole of anyway. That said, this does look like straightforward addition, which allows to do more with the thing, without actually expanding it's surface area greatly.
Change:
<del> Subproject commit 130f9488d3b861e02c9282b686eec717e30912cf </del> <ins> Subproject commit 07ac10277ea5ad42efbb914da5844e0ab08efbf4 </ins>

Discussion:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool miri has failing tests. A follow-up PR to the repository is needed to fix the fallout. cc do you think you would have time to do the follow-up work? If so, that would be great! cc the PR reviewer, and -- nominating for prioritization.
I suspect miri just needs a compiletest update cc
triage: P-medium. Removing nomination label.
So, the compiletest-update was semver-breaking?
The failure seems to be a panic in cargo...?
not quite, nightly rustc broke compiletest and we play catch up with that since the nightly feature is "current nightly" the cargo panic you're seeing is an osx bug in cargo that got fixed
Is this a recent bug? It looks (in Miri CI) as if the bug occurred with stable cargo.
this bug appeared in nightly and got fixed on the next day. Could you cargo version from CI (after installing master toolchain)?
It's recent, but not on stable, maybe you're seeing something else.
FWIW, the trouble was that Travis on the auto branch used a beta cargo, not a stable one, due to caching.
Change:
pub(super) fn parse_lit(&mut self) -> PResult<'a, Lit> { self.parse_opt_lit().ok_or_else(|| { <ins> if let token::Interpolated(inner) = &self.token.kind { let expr = match inner.as_ref() { token::NtExpr(expr) => Some(expr), token::NtLiteral(expr) => Some(expr), _ => None, }; if let Some(expr) = expr { if matches!(expr.kind, ExprKind::Err) { self.diagnostic() .delay_span_bug(self.token.span, &"invalid interpolated expression"); return self.diagnostic().struct_dummy(); } } } </ins> let msg = format!("unexpected token: {}", super::token_descr(&self.token)); self.struct_span_err(self.token.span, &msg) })

Discussion:
Note that must not exist in order to reproduce this error: The first error is what I would expect, but the second is a bit confusing and weird: Perhaps instead of emitting (/ERROR/)delayspanbug` since an error should have already occurred. If for some reason an error had not already been emitted, the compiler would crash; otherwise, it would just show the original error. Originally posted by in
Note that is stable now (though it hasn't reached the stable channel yet), so this no longer requires a feature flag.
Mentoring instructions: in , check if the token is a and the expression is an error; if so, use instead of .
Hi I was searching for a first issue and i have a question : What does ? Because the function that you pin must return a but has return type Sorry if i misread something
delayspanbug means "if the compiler finishes running without first reporting another error, panic". It's useful here because error tokens should always report in an error being reported. I think anything you return is probably fine as long as it doesn't cause further cascading errors :)
i fixed it but for adding a test case : i run into an edge case the output message of the macro : include_str! is not normalized with $DIR the ui test is working only for me. Have you a tip or i have to create an issue ? Thanks
you can use : https://rustc-dev- But I'm surprised $DIR doesn't work :/ that does seem like a bug.
Sorry I was not clear : the $DIR is working for the But the path is not replace for the error comment in the because the path read by include_str is in the error message
don't put the whole name in the .rs file - you just need to put a substring. Something like .
Change:
} else { &self.build.config.target }; <del> // If --target was specified but --host wasn't specified, don't run // any host-only tests </del> <ins> // Determine the actual targets participating in this rule. // NOTE: We should keep the full projection from build triple to // the hosts for the dist steps, now that the hosts array above is // truncated to avoid duplication of work in that case. Therefore // the original non-shadowed hosts array is used below. </ins> let arr = if rule.host { <del> if self.build.flags.target.len() > 0 && self.build.flags.host.len() == 0 { &hosts[..0] </del> <ins> // If --target was specified but --host wasn't specified, // don't run any host-only tests. Also, respect any `--host` // overrides as done for `hosts`. if self.build.flags.host.len() > 0 { &self.build.flags.host[..] } else if self.build.flags.target.len() > 0 { &[] </ins> } else { <del> hosts </del> <ins> &self.build.config.host[..] </ins> } } else { targets

Discussion:
This is the reason of nightly packaging failing. I strongly suspect my own for that, although I don't yet know why the artifact is skipped in the first place. I'll investigate further.
Indeed: In  we have some logic to presumably shave off some test time by checking if the rule is host-only, limiting the cross product to hosts array if applicable. However after the hosts array only consists of the build triple, so the output of host rules is effectively filtered to build-triple-only. My apologies. Patch pending.
Opened . Before : (some additional debug info by me, not present in the PR) After , before : After:
Change:
// Try to find a definition in the current session, using the previous `DefIndex` // as an initial guess. let opt_def_id = tcx.cstore.def_path_hash_to_def_id(krate, raw_def_id.index, hash); <ins> debug!("def_path_to_def_id({:?}): opt_def_id = {:?}", hash, opt_def_id); </ins> e.insert(opt_def_id); opt_def_id }

Discussion:
This seems to be an incremental error‽ We need an external crate for this to work. Haven't managed it to work in an internal mod only :/ Also this only happens with . Haven't managed to get it running with sadly extern crate (let's call it f) code Then just remove and add afterwards again (or the other way round, it doesn't matter). This script does it for you: <!-- 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<pand with RUST_BACKTRACE=full the LLVMing assert vanishes </p</details
searched nightlies: from nightly-2020-12-08 to nightly-2020-12-10 regressed nightly: nightly-2020-12-10 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.0</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </detailscc
Assigning as discussed as part of the and removing .
I've fixed the issue locally, and I'm working on a PR.
Opened
Change:
ty::Slice(_) => (this, " because slices are always foreign"), ty::Array(..) => (this, " because arrays are always foreign"), ty::Tuple(..) => (this, " because tuples are always foreign"), <ins> ty::RawPtr(ptr_ty) => { emit_newtype_suggestion_for_raw_ptr( full_impl_span, self_ty, self_ty_span, ptr_ty, &mut err, ); (format!("`{}`", ty), " because raw pointers are always foreign") } </ins> _ => (format!("`{}`", ty), ""), }; let msg = format!("{} is not defined in the current crate{}", ty, postfix); if *is_target_ty { // Point at `D<A>` in `impl<A, B> for C<B> in D<A>`

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: <!-- The following is not always necessary. --Ideally the output should look like: <!-- If the problem is not self-explanatory, please provide a rationale for the change. --<!-- If dramatically different output is caused by small changes, consider also adding them here. 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. The output might also be different depending on the Edition. --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
This could use some work, too, I think. Maybe "impl mentions type from outside the current crate" might be a sufficient replacement, though we should probably make sure that wording is compatible with current coherence rules. Though, in this case, for a non- self type like , we could then replace that^ message with something even more specific. I'm a bit skeptical of mentioning "try implementing on " when we have , since implementing something for and can have very different meanings depending on the signatures inside the trait.
Let's improve this case! claim
This was actually closer to my original error I got, it uses a type alias to create some extra confusion:
Amazing example :) thanks, I'm on it
This is a reproducible example without serde!
Change:
span: tcx.def_span(trait_item_id), }) } <del> } else if tcx.fn_trait_kind_from_def_id(trait_ref.def_id).is_some() { </del> <ins> } else if let Some(target_kind) = tcx.fn_trait_kind_from_def_id(trait_ref.def_id) { </ins> // FIXME: This doesn't check for malformed libcore that defines, e.g., // `trait Fn { fn call_once(&self) { .. } }`. This is mostly for extension // methods.

Discussion:
Importantly note that the closure passed to foo is ; does not ICE. : <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Regression in ()
Change:
- Operating System > Target OS = linux - Operating System > Linux kernel version = 3.2.101 - Binary utilities > Version of binutils = 2.32 <ins> - Binary utilities > binutils extra config = --enable-compressed-debug-sections=none -- (*) </ins> - C-library > glibc version = 2.17.0 - C compiler > gcc version = 8.3.0 - C compiler > C++ = ENABLE <ins> (*) Compressed debug is enabled by default for gas (assembly) on Linux/x86 targets, but that makes our `compiler_builtins` incompatible with binutils < 2.32. </ins> ### `powerpc-linux-gnu.config` For targets: `powerpc-unknown-linux-gnu`

Discussion:
Hashbrown crate starts fail when running with: Full log file can be found in . <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summaryLog</summary<p</p</details<!-- If you know when this regression occurred, please add a line like below, replacing with one of stable, beta, or nightly. modify labels: +regression-from-stable-to-{channel} -regression-untriaged --
That's probably introduced by , but I haven't looked further yet.
Quick repro: and then edit: this repro is incorrect (I'm investigating)
I can reproduce with a simple hello-world when running in an older container. I think it's related to the user having binutils < 2.32, which would be fixed by Our new i586-gnu cross toolchain appears to be compressing by default, like the option, but I don't know why it's happening on this one and not any of our other crosstool-ng builds.
I found this commit in binutils: ;a=commit;h= That is, gas (the assembler) enables compression by default only on Linux/x86, which is why we haven't had this problem with other crosstool-ng toolchains. I'll explicitly turn that off.
great detective work thanks! :)
Change:
severity: ChangeSeverity::Warning, summary: "The "codegen"/"llvm" profile has been removed and replaced with "compiler", use it instead for the same behavior.", }, <ins> ChangeInfo { change_id: 118724, severity: ChangeSeverity::Info, summary: "`x install` now skips providing tarball sources (under 'build/dist' path) to speed up the installation process.", }, </ins> ];

Discussion:
Right now when doing a local , we first compress the artifacts with max compression ratio, just to immediately unpack them again when installing them to disk. Making the compression level less aggressive or skipping it altogether can probably save 5-10 minutes on an x.py install. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
cc You probably want to use the gzip'd artifacts which are less intensely compressed.
tbh it seems strange that we're compressing these at all - why not put them into an uncompressed .tar archive when using ?
or even better, copy them directly from the build directory to the install directory without going through a .tar archive first.
claim
Skipping the compressions and archiving in favor of directly copying the artifacts seems like a reasonable solution for . But it requires significant changes to how we currently handle . I'm planning to do a comprehensive review on bootstrapping from all angles(including T-bootstrap issues) and make a roadmap for future development. To avoid conflicts(e.g, if we have improvement ideas on dist/install modules, implementing this might increase the technical debt which will require more effort from the team), I will postpone this task for now and re-prioritize it once we have organized the plans.
Change:
use something::Foo; // error: unresolved import `something::Foo`. ``` <del> Please verify you didn't misspell the import name or the import does exist in the module from where you tried to import it. Example: </del> <ins> Paths in `use` statements are relative to the crate root. To import items relative to the current and parent modules, use the `self::` and `super::` prefixes, respectively. Also verify that you didn't misspell the import name and that the import exists in the module from where you tried to import it. Example: </ins> ```ignore <del> use something::Foo; // ok! </del> <ins> use self::something::Foo; // ok! </ins> mod something { pub struct Foo;

Discussion:
Exemple code: Error is: The compiler should detect that "self" is missing. Note this is an error I do all the time as a beginner.
Even without doing an analysis of what could have likely been intended this error message could mention that paths in are absolute by default, unless they start with or .
Ran into this a few days ago, would love to the messaging here improved :+1:
The linked PR adds the information to the long diagnostics, at least. Note that if you just have an then the error message is markedly different: I wonder if some consolidation would be in order.
Fixed in .
Change:
{ let mut violations = vec![]; <del> if self.supertraits_reference_self(trait_def_id) { violations.push(ObjectSafetyViolation::SupertraitSelf); </del> <ins> for def_id in traits::supertrait_def_ids(self, trait_def_id) { if self.predicates_reference_self(def_id, true) { violations.push(ObjectSafetyViolation::SupertraitSelf); } </ins> } debug!("astconv_object_safety_violations(trait_def_id={:?}) = {:?}",

Discussion:
the following generates a compiler error on all current versions: RUST_BACKTRACE hangs for me, but emits: error: internal compiler error: Unexpected type in full type resolver: FreshTy(0) This is greatly cut down from a real world example, and a blocking issue for me
This is a regression of the release (over ) of rust.
triage: P-medium Pretty old regression, barely qualifies. =) However, says he has a fix.
Oh sorry, disregary my comment above, the issue is reproducible on 1.3.0 as well as on stable 1.0.0. Its not a regression, at least not one from a stable rust release.
Change:
let lpCmdLine = c::GetCommandLineW(); let szArgList = c::CommandLineToArgvW(lpCmdLine, &mut nArgs); <ins> // szArcList can be NULL if CommandLinToArgvW failed, // but in that case nArgs is 0 so we won't actually // try to read a null pointer </ins> Args { cur: szArgList, range: 0..(nArgs as isize) } } }

Discussion:
I'm looking at , and trying to find out the thread-safety of . Along the way, I noticed that , despite I'm allergic to Windows, so I've no idea what might cause this dangerous return value.
While it may be nice to have a comment to this effect, I don't think that this is a problem. The only time we actually look at the pointer is during iteration, and that only happens if the count/range returns an item. In the case that NULL is returned the count will be 0, so the pointer is never looked at. Additionally, ignores NULL pointer arguments, so I don't think that there's actually a problem here. All that being said, though, a comment would be nice.
Change:
); } _ => { <del> let spans = if ty.span.from_expansion() || r.span.from_expansion() { ( ty.span.with_hi(ty.span.lo() + BytePos(1)), ty.span.with_lo(ty.span.hi() - BytePos(1)), ) </del> <ins> let spans = if let Some(r) = r.span.find_ancestor_inside(ty.span) { Some((ty.span.with_hi(r.lo()), ty.span.with_lo(r.hi()))) </ins> } else { <del> (ty.span.with_hi(r.span.lo()), ty.span.with_lo(r.span.hi())) </del> <ins> None </ins> }; <del> self.emit_unused_delims(cx, spans, "type", (false, false)); </del> <ins> self.emit_unused_delims(cx, ty.span, spans, "type", (false, false)); </ins> } } }

Discussion:
Reported by here: (Note that but does not fix this bug.)
searched nightlies: from nightly-2021-01-07 to nightly-2021-12-24 regressed nightly: nightly-2021-09-12 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.0</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
This regression was introduced in . cc
Not a fix, but if I make this change then there is no longer an ICE and I get
Thanks for opening the issue If someone finds a fix but doesn't know how to add the test, this pull request which solves a similar ICE has an example of how to add a test when there is a missing newline:
Change:
<ins> // Copyright 2018 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. // Test case from #39963. #![feature(nll)] #[derive(Clone)] struct Foo(Option<Box<Foo>>, Option<Box<Foo>>); fn test(f: &mut Foo) { match *f { Foo(Some(ref mut left), Some(ref mut right)) => match **left { Foo(Some(ref mut left), Some(ref mut right)) => panic!(), _ => panic!(), }, _ => panic!(), } } fn main() { } </ins>

Discussion:
UPDATE: This now works in NLL land. and should be separate borrows into the same structure. Note that changing to makes it borrow check, and changing to in the struct also makes it borrow check. This makes me think it's something to do with the special casing of .
This is intentional. rust-lang/rfcs.
no... it isn't. This is incorrect behavior. It should treat and as separate borrows. (as seen by the fact that it works in the outer match statement)
I'm afraid is right, we really dumbed down . Proof: while .
then it's a bug with the specification (and the issue should be left open).
given that this works: , rust should be able to figure out the difference between a moving deref and a non-moving; it can already figure out mutable vs. non-mutable.
Sure, the equivalent of your code with a type instead of a works: The current borrowck is sort-of in maintenance mode, so this is unlikely to be fixed before MIR borrowck.
Nominating. I suggest we retag this as C-enhancement rather than C-bug. I separately suggest that we prioritize it as P-medium. (It does not need to land as part of the initial MIR-borrowck / NLL work.)
(looking at , I am wondering: what's the difference between C-feature-request and C-enhancement? Should we collapse those two labels into one...?)
In the NLL / MIR borrow checker, we decided to just be smarter around . Therefore, .
I think I would be happy to just add a test for this (with ) and close this issue.
Change:
fn visit_estr_uniq(&mut self) -> bool { true } fn visit_estr_slice(&mut self) -> bool { true } fn visit_estr_fixed(&mut self, <del> _sz: uint, _sz: uint, </del> <ins> _sz: uint, _sz2: uint, </ins> _align: uint) -> bool { true } fn visit_box(&mut self, _mtbl: uint, _inner: *TyDesc) -> bool { true }

Discussion:
Former-XXXes say "is this right?"
Clearing milestone because it's not obviously blocking anything. -- what test case(s) would answer the question you asked in a comment ("is this right?")?
Visiting for triage; FIXMEs are still there.

We should add some sort of special comment like . Here is the hashcode of the current snapshot. The build system can then issue warnings if such a comment exists and is not still the current snapshot.
do you still feel that this would be useful?
Still seems useful to me.
Still very useful.
(bug triage) This would be nice, but is not a blocker.
Change:
hir::ItemKind::Const(..) => { NonUpperCaseGlobals::check_upper_case(cx, "constant", &it.ident); } <del> // we only want to check inherent associated consts, trait consts // are linted at def-site. hir::ItemKind::Impl(hir::Impl { of_trait: None, items, .. }) => { for it in *items { if let hir::AssocItemKind::Const = it.kind { NonUpperCaseGlobals::check_upper_case(cx, "associated constant", &it.ident); } } } </del> _ => {} } }

Discussion:
I believe the old behavior from nightly-2023-04-19 is correct. The repro has nothing to do with trait impls so I believe was not supposed to have affected it.
Bisects to .
How on earth did that happen? It was like a five-line change. :laughing: EDIT: got a fix, will post soon.
Probably something to do with the hygeine of the span on the versus the . if you can't fix this then ping me and I'll look at it, but we probably should fix it sooner than later.
Actually, you're probably right.
Oh, no, that's not it. You're missing a call to in the visitor.
Change:
<ins> // This is a regression test for https://github.com/rust-lang/rust/issues/118047 // build-pass // compile-flags: -Zmir-opt-level=0 -Zmir-enable-passes=+DataflowConstProp #![crate_type = "lib"] pub struct State { inner: bool } pub fn make() -> State { State { inner: true } } </ins>

Discussion:
Reduced from : Compilation should crash with this error: Because we are trying to generate an LLVM bitcast from to . The MIR dump looks like this: I haven't been able to figure out how to produce this MIR without DataflowConstProp.
Thes standard library also works as a reproducer. Simply building a hello world with this will assert:
You asked about this crash before when I had a messy reproducer. Pinging you now because it's a lot smaller. it is now