jiebi/CodeConvo huggingface dataset:
Change:
} } <del> /// Maps a `Result<T, E>` to `U` by applying a provided default fallback /// function to a contained [`Err`] value, or a provided function to a /// contained [`Ok`] value. </del> <ins> /// Maps a `Result<T, E>` to `U` by applying fallback function `default` to /// a contained [`Err`] value, or function `f` to a contained [`Ok`] value. </ins> /// /// This function can be used to unpack a successful result /// while handling an error.

Discussion:
The type signature of : Note how is the function that gets applied to the variant. Then, the docstring (emphasis mine): I think this is a very unfortunate choice of words and should be changed.
are you interested in making a PR to fix it? :) there are instructions in https://rustc-dev-
I could, but I think I'd prefer to bikeshed a bit first as to how it should be described.
To me these functions are so confusing that I practically never use them, the arguments are in the wrong order ... as repeatedly noted in both the and that it. It can't be changed, of course :/ I rather like the way it's documented in the corresponding method on :
How about It explains in the same order as the function name () and doesn't overload the meaning of "default" in the context of the unfortunate function argument.
Made a pull request using 's suggestion, only replacing "applying " with "applying function " to be consistent with the earlier part of the sentence.
Change:
/// }; /// /// // Back on our current thread, we wait for the value to be set <del> /// while live.load(Ordering::Acquire) { </del> <ins> /// while !live.load(Ordering::Acquire) { </ins> ///     // The spin loop is a hint to the CPU that we're waiting, but probably ///     // not for very long ///     hint::spin_loop();

Discussion:
Hi, I was reading the when I stumbled upon this example (using the form with no hidden items): I think that the values for AtomicBool might be inverted, because this program never terminates when run in the playground. Should this be fixed or is there something I'm missing?
good catch, thanks! Would you like to fix it yourself? There are instructions at https://rustc-dev-; the command to test your changes is .
I'd love to! Do I just make a PR that references this issue then?
yup, that would be great :)
Change:
} fn main() { <del> let foo = BuildData { //~ ERROR missing field: `bar` </del> <ins> let foo = BuildData { //~ ERROR missing field `bar` in initializer of `BuildData` </ins> foo: 0 }; }

Discussion:
E0063 doesn't specify which constructor the field is missing from, leading the user to guess in case of nested constructors. The printed output also fails to highlight the relevant constructor. On :
Change:
} } <del> #[derive(Debug, Copy, Clone, HashStable)] </del> <ins> #[derive(Debug, Copy, Clone, HashStable, TypeFoldable, TypeVisitable)] </ins> pub enum UpvarArgs<'tcx> { Closure(GenericArgsRef<'tcx>), Coroutine(GenericArgsRef<'tcx>),

Discussion:
<!-- [31mICE[0m: Rustc '--edition=2018 -ooutputfile -Zdump-mir-dir=dir' 'thread 'rustc' panicked at 'we captured CapturedPlace {'', 'thread 'rustc' panicked at 'we captured CapturedPlace {'' File: --snippet: 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 --
probably also caused by ?
yep ill put up a fix in a few
Change:
// Is the repetition empty? if len == 0 { if seq.op == quoted::KleeneOp::OneOrMore { <del> // This should be impossible because the macro parser would not // match the given macro arm. cx.span_bug(sp.entire(), "this must repeat at least once"); </del> <ins> // FIXME: this really ought to be caught at macro definition // time... It happens when the Kleene operator in the matcher and // the body for the same meta-variable do not match. cx.span_fatal(sp.entire(), "this must repeat at least once"); </ins> } } else { // 0 is the initial counter (we have done 0 repretitions so far). `len`

Discussion:
Given this test file: stable Rust errors like this: while on 1.36.0-nightly ( 2019-05-21) running on x86_64-unknown-linux-gnu:
caused by cc
Yay, we have a test case.
Hmm... interesting... yeah, I guess we have a test case. I will open a PR to revert and add the test case. Thanks ! But this raises a bigger point that has been growing on me for a while now: there are a ton of checks that are currently only done at macro invocation time (or are not done at all) that really would make more sense to do a macro definition time. Checking that the Kleene operator used in the body is the same as that in the matcher Checking that all meta-variables used in the body are defined and in scope Checking that all meta-variables used in the body are repeating at the right depth Checking that the body of a macro is actually valid rust syntax (to the extent that we can, anyway) So far, I have been holding off on attempting to fix these because they could involve building a whole language, and it seems that at some point we want to just use macros... Thoughts?
Opened
there are a ton of checks that are currently only done at macro invocation time (or are not done at all) that really would make more sense to do a macro definition time. If the defined macro produces an error with any possible input, then we should probably report it at definition time, at least as a quality of implementation measure (perhaps as a warning for a start). I have more confidence in reporting errors related to the macro definition language itself (meta-variables, repetitions, etc.), than in errors for produced tokens (which are not necessarily supposed to be Rust code, with eager expansion they may be consumed by another macro, for example).
Ok, makes sense. I will open another issue with these items so we can track them.
Change:
pub(super) fn parse_ty_for_where_clause(&mut self) -> PResult<'a, P<Ty>> { self.parse_ty_common( AllowPlus::Yes, <del> AllowCVariadic::Yes, </del> <ins> AllowCVariadic::No, </ins> RecoverQPath::Yes, RecoverReturnSign::OnlyFatArrow, None,

Discussion:
<!-- [31mICE[0m: Rustc '-Zunstable-options --edition=2024 -ooutputfile -Zdump-mir-dir=dir' 'error: internal compiler error: should have been handled elsewhere', 'error: internal compiler error: should have been handled elsewhere' 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: --
also repros with or with 2015 if you remove the :)
Regression in nightly-2020-12-20 fetching (via remote github) commits from max(, 2020-12-17) to ending github query because we found starting sha: getcommitsbetween returning commits, len: 9 commit[0] 2020-12-18: Auto merge of - ehuss:update-cargo, r=Mark-Simulacrum commit[1] 2020-12-18: Auto merge of - GuillaumeGomez:str-to-symbol, r=jyn514 commit[2] 2020-12-19: Auto merge of - mibac138:fn-fat-arrow-return, r=davidtwco commit[3] 2020-12-19: Auto merge of - davidtwco:issue--const-param-attrs, r=lcnr commit[4] 2020-12-19: Auto merge of - JohnTitor:rollup-a31s996, r=JohnTitor commit[5] 2020-12-19: Auto merge of - jackh726:binder-refactor-part-2, r=lcnr commit[6] 2020-12-19: Auto merge of - CDirkx:ipaddr-const, r=oli-obk commit[7] 2020-12-19: Auto merge of - matthewjasper:revert-eval-order, r=nikomatsakis commit[8] 2020-12-19: Auto merge of - Nadrieril:usefulness-merging, r=varkor
This is also kinda bad because rustc does not tell you what you did wrong (theres no error shown) mvce:
very likely
Change:
<ins> Future incompatibility report: Future breakage diagnostic: warning: impl method assumes more implied bounds than the corresponding trait method --> $DIR/resolve-re-error-ice.rs:17:16 | LL |     fn key_set(&self) -> Subject<'a, Keys<K, V>, (), R> { |                ^^^^^     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ help: replace this type to make the impl signature compatible: `Subject<'_, std::collections::hash_map::Keys<'_, K, V>, (), R>` | = warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release! = note: for more information, see issue #105572 <https://github.com/rust-lang/rust/issues/105572> note: the lint level is defined here --> $DIR/resolve-re-error-ice.rs:4:10 | LL | #![allow(implied_bounds_entailment)] |          ^^^^^^^^^^^^^^^^^^^^^^^^^ </ins>

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. --Possibly related to ? in The error message is in building but I can't reproduce with just building that crate, which is odd. <!-- 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 --
label +E-needs-mcve
I'm pretty sure I know how to make an MCVE for this. claim
Ah, lol, it's because hasn't landed, and a recent ReError PR made it delay a bug that should've been handled more gracefully. If you build assertor with (or add ) then it ICEs similarly.
Change:
// not for MSVC or macOS if builder.config.llvm_static_stdcpp && !target.contains("freebsd") && <del> !target.contains("windows") && </del> <ins> !target.contains("msvc") && </ins> !target.contains("apple") { let file = compiler_file(builder, builder.cxx(target).unwrap(),

Discussion:
I saw this failure in rayon CI: I'm on Linux, but I tried this build under Wine: It seems intention in was that this should be statically linked, but that was clobbered by in at least. The same error occurs on (via Wine again for me).
Probably the culprit is here:
As immediate workaround I suggest adding to the PATH, it should be installed on most of the Windows CI.
Thanks! It works.
triage: P-high, has PR, removing nomination.
Sadly, that didn't work for me: "The procedure entry point ZNSt13futurebase12ResultbaseC2Ev could not be located in the dynamic link library C:Usersxxx.rustuptoolchainsnightly-x8664-pc-windows-gnubinrustcdriver-" Just posting as an FYI, not expecting a solution.
FWIW it was fixed in nightly but not yet in beta.
Did this fix make it into stable? I'm getting that error in rustc 1.59.0 ( 2022-02-23). Cross-compiling from Linux: Trying to run under Wine 7.0. Wine error messages: Please, statically link this stuff. (Trying to find the correct version of . MinGW has four different versions. Correct versions seem to be the ones in 9.3.win32)
It was linked statically in the past, must be regression. Does it work on other versions for you? There are 2 versions shipped in Ubuntu: posix and win32. Posix is the correct one. BTW those libraries come from GCC, not MinGW.
Upon closer inspection you are not having problem running rustc but with artifacts built with rustc. In this case this entirely different issue and you need to find which crate in your dependency tree has linked dynamic libstdc++.
Yes. I was using a deprecated package that pulled in some DLLs. Once I got rid of that package, the problem disappeared.
two questions: 1) how did you find the offending package, 2) which one was it? I'm getting the same thing on
Looked through the build logs with "grep" for the package name.
I couldn't find a specific dependency that caused the issue, but upgrading rust from to fixed it for me.
Change:
<ins> // run-check // aux-build:proc-macro-type-error.rs extern crate proc_macro_type_error; use proc_macro_type_error::hello; #[hello] //~ERROR mismatched types fn abc() {} fn x(_: &mut i32) {} macro_rules! bla { () => { x(123); //~^ ERROR mismatched types //~| SUGGESTION &mut 123 }; ($v:expr) => { x($v) } } fn main() { bla!(); bla!(456); //~^ ERROR mismatched types //~| SUGGESTION &mut 456 } </ins>

Discussion:
The tokens generated by procmacro (e.g. from ) use , which makes some suggestions produce invalid output: It's a bit tricky, because this callsite span does point into the current crate (to ), so this situaiton isn't detected in the same way as external .
Looks like should be used in more places. That one detects this span by checking if is a dummy or imported.
I'm working on a fix specifically for these typeck/borrowing suggestions. Not sure how many other suggestions have the same problem.
this is a prevalent problem. We need to add metadata to spans to distinguish call sites explicitly in an easy way and always ignore suggestions in them.
Change:
<ins> // edition:2018 // build-pass // compile-flags: -Z mir-opt-level=2 -L. // aux-build:issue_76375_aux.rs #![crate_type = "lib"] extern crate issue_76375_aux; pub async fn g() { issue_76375_aux::f(true); h().await; } pub async fn h() {} </ins>

Discussion:
Compiling with I get since two nightlies:
Triage: It's now compiled fine with the latest nightly, I think it's fixed by .
It works now, thank you.
This should be open until the test is .

<!-- 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. --Code is from glaciers , original ticket: The code still ICEs when checking with <!-- 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. --repo is @ <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Triage: It's now compiled fine with the latest nightly, perhaps it's fixed by .

As , the MIR inliner seems to fail when dealing with opaque return types. Test case: Invocation: <details<summaryICE:</summary</details
I'm not sure how async closures desugar, so this could be way off base, but this looks very similar to the other ICEs tracked in . Does this look like another instance of that issue to you?
The immediate cause of this is the fact that we call during inlining: If we do this, we should also be normalizing the substs we pass to , so that we reveal any opaque types. However, it looks like the opaque type occurs within a binder (due the opaque type appearing in the return type of an fn pointer), so I think lazy normalization may be required to fix this in the general case.
Triage: It's now compiled fine with the latest nightly, I think it's fixed by .
Change:
<ins> // Copyright 2017 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. #![feature(associated_consts)] trait Foo { const BAR: i32; fn foo(self) -> &'static i32 { //~^ ERROR the trait bound `Self: std::marker::Sized` is not satisfied &<Self>::BAR } } fn main() {} </ins>

Discussion:
My code is about 500 lines long. I'm running up against an assignment deadline, so I don't have time right now to make a minimal demonstration. But if needed I can do so after Thursday, if someone hasn't gotten to it already. Sorry to dump and run. I normally try to be better about bug reports. :/ I expect this to be related to my copy paste error with repeated if clause: EDIT: Removed code, as there is a minimal example below.
Minimal example: Gives output:
I like to check back in on my issues from time to time to ensure that they haven't become invalid. I found that this issue still exists in the 2017/12/11 nightly ().

The following code ICEs on x8664 linux Suspect that it's this line (expecting that a struct with size 8 has 1 field) ICE message: cc
This isn't fixed, example should have had a or a attribute to make sure that the function is exported.
. CC
These "components" are not exactly struct fields, but rather hardware registers. The alignment padding probably triggers an edge case, I'll have to look deeper.

I found out that doesn't work, so I got a bit creative and tried this (reduced example): Which lead to this: It just prints an error on stable (1.17.0): And of course:
I ran into this with declarative macros on
Panics with the same error on 1.18.0 stable now:
Now this works, but it breaks proc-macro derives on the same item (parsing fails). Should I report that bug to a different location? It sort of feels like it's rustc's fault, as it's passing the proc-macro invalid syntax. I think it's odd that a macro can legally expand to invalid syntax...
That sounds a rust-lang/rust problem, yes. Have you filed an issue? I'd love to see a short example of the failure.
I've opened another issue for it:

$ RUST_BACKTRACE=1 rustc $ cat $ rustc --version --verbose
Looks like this was fixed. Output with current nightly as per playground:
Yeah, this was fixed. Marking as E-needstest.
Change:
bcx.val_to_str(val)); let _indenter = indenter(); <del> do enter_match(bcx, dm, m, col, val) |p| { </del> <ins> // Collect all of the matches that can match against anything. let matches = do enter_match(bcx, dm, m, col, val) |p| { </ins> match p.node { ast::pat_wild | ast::pat_tup(_) => Some(~[]), ast::pat_ident(_, _, None) if pat_is_binding(dm, p) => Some(~[]), _ => None } <del> } </del> <ins> }; // Ok, now, this is pretty subtle. A "default" match is a match // that needs to be considered if none of the actual checks on the // value being considered succeed. The subtlety lies in that sometimes // identifier/wildcard matches are *not* default matches. Consider: // "match x { _ if something => foo, true => bar, false => baz }". // There is a wildcard match, but it is *not* a default case. The boolean // case on the value being considered is exhaustive. If the case is // exhaustive, then there are no defaults. // // We detect whether the case is exhaustive in the following // somewhat kludgy way: if the last wildcard/binding match has a // guard, then by non-redundancy, we know that there aren't any // non guarded matches, and thus by exhaustiveness, we know that // we don't need any default cases. If the check *isn't* nonexhaustive // (because chk is Some), then we need the defaults anyways. let is_exhaustive = match matches.last_opt() { Some(m) if m.data.arm.guard.is_some() && chk.is_none() => true, _ => false }; if is_exhaustive { ~[] } else { matches } </ins> } // <pcwalton> nmatsakis: what does enter_opt do?

Discussion:
This should print , but prints . The problem seems to be the pattern, since if this is replaced by aokok_` is not important.)
Confirmed. Bugs where we actually generate the wrong code are pretty bad, so fixing this is probably decently high priority. Not sure it actually fits for a milestone, though?
OK, I've figured out what is going on. The problem is that the matcher is too strict when deciding what patterns are included in some condition. Essentially the problem is that it decides that the condition that are relevant are "length 1" and "length 0" and decides that [2, .. ] is the only pattern that matches "length 1", which is obviously bogus. Fixing this seems a bit tricky, since we need to be able to properly expand out the patterns while still properly handling bindings. Note that this seems like a degenerate case, since the last pattern could just be replaced with a , but there are more complicated and interesting things where this happens too.
Oh, no, there is a pretty simple solution to this. The trick is, when checking submatches generated by a vector length check, set it up so that if none of the subpatterns match, it goes to the next vector length check. I'm explaining it poorly, but it is a really simple fix.
Simple fix has problems, though. So have a more complex fix. Which also has problems. Still investigating.
OK, have it all fixed. Just trying to document it well at this point.
Change:
mod arm_base; mod bitrig_base; mod dragonfly_base; <ins> mod emscripten_base; </ins> mod freebsd_base; mod haiku_base; mod linux_base;

Discussion:
After following the steps in the , running gives the following output: See for discussion. believes it to be an issue with invoking without enabling shell expansion.
Invoking fixes the error above, but another error pops up (see below).
Here is a workaround: instead of invoking , invoke . (Wow, it takes a long time—90 seconds until it fails in optimisation for a very basic thing seems inordinate!)
Same, when trying to invoke given command directly, getting instead:
Ah, this seems to be rather related to
Indeed. PR is work in progress. Also emscripten 1.35.0 (latest pre-build binary) does not work (see llvm assertion above). I haven't had the chance to try out emscripten 1.37.0 ()
Yep, that's what was suggested in that other issue and I can confirm it works.
For the sake of completeness, I finally had the time to test everything. This works for windows: Get emscripten 1.37.0: VS 2013 Community (required by emscripten) Rewire rustc to : Workaround for rust 1.14: Fix: PR I guess should check for a minimal required emscripten version, but this is probably out of scope.
Thanks for the investigations and the patch
Looks like the fix is merged.
I get the same error. Unless I run rustc from the same cmd windows I used to run emsdk activate. Running emsdk activate with --global doe not seem to change anything. This may just be how it is intended to work.
Did you run emsdk activate --global in elevated cmd? That's what it would take for it to work and permanently store generated environment variables in registry.
Change:
<ins> // check-pass pub trait Foo { type Bar; } pub trait Broken { type Assoc; fn broken(&self) where Self::Assoc: Foo; } impl<T> Broken for T { type Assoc = (); fn broken(&self) where Self::Assoc: Foo { let _x: <Self::Assoc as Foo>::Bar; } } fn main() { let _m: &dyn Broken<Assoc=()> = &(); } </ins>

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. --code from cc <!-- 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. --: Note that is required to reproduce the ICE <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
cc maybe you have an idea why this still crashes with ?
No, I don't unfortunately. The version of version I worked on is meant to be called before typecheck has finished and where normalization could still fail. This call seems to occur during codegen, where normalization should (in theory) always succeed (or rather errors should have been caught earlier), but I'm not that familiar with the later stages of the compiler, so I might be missing something.
This normalization is happening in an optimization pass () which can run on MIR that can never be codegenned. In this case, the method impl has an impossible-to-satisfy clause, so it can never actually be called or codegenned. The optimization pass should be changed to use - it can just do nothing if it fails.
Thanks for pointing out the problem. Would you like to open a PR for this or are you ok with me trying to fix this?
Feel free to open a PR