jiebi/CodeConvo huggingface dataset:
Change:
lhs, rhs, expected, <del> DontAllowOverloadedOperators); </del> <ins> BinopAssignment); </ins> let lhs_t = fcx.expr_ty(lhs); let result_t = fcx.expr_ty(expr);

Discussion:
OS: Ubuntu 12.04 x86 rustc -v rustc 0.9-pre ( 2013-12-24 01:56:30 -0800) host: i686-unknown-linux-gnu Full error message: 30:14 error: binary operation + cannot be applied to type v += move; ^~~~~ error: internal compiler error: no type for node 81: expr move (id=81) in fcx 0xb3970ef8 This message reflects a bug in the Rust compiler. We would appreciate a bug report: task 'rustc' failed at 'explicit failure', task '<main' failed at 'explicit failure', Source:
Change:
... LL |     let c = unsafe { *mut_ptr() }; |                      ---------- you could clone this value <del> help: consider removing the dereference here | LL -     let c = unsafe { *mut_ptr() }; LL +     let c = unsafe { mut_ptr() }; | </del> error[E0507]: cannot move out of a raw pointer --> $DIR/issue-20801.rs:36:22

Discussion:
Cloning the pointer doesn't make sense in that situation and would cause a type mismatch error. I'm not sure whether any of the two current suggestions should be kept or removed in this case. No response No response <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Note that this works: It works because is a place expression and then we attach to that, which then reborrows the String. I don't think we should suggest , which may have undesirable or unexpected effects in the case of things like types that handle backing buffers, instead of issuing a safe which will recreate the backing allocation correctly.
I didn't know that was possible, thanks for letting me know. I guess that the best approach would then be to change the suggestion accordingly as below?
Correct. Also, we could mention in the error for pointers, but we shouldn't recommend it. It's unsafe code, we should strive to preserve the "you break it, you buy it" / "do your own research" experience for that.
The relevant section of diagnostic code is here but it will require some restructuring to account for the fact that the suggestion will not be doing things like stripping parentheses, but suggesting adding them if they don't exist.
claim It looks good for me to make a try.
Change:
ImportResolver { r: self }.resolve_imports() } <del> fn resolve_macro_invocation(&mut self, invoc: &Invocation, invoc_id: ExpnId, force: bool) -> Result<Option<Lrc<SyntaxExtension>>, Indeterminate> { let parent_scope = self.invocation_parent_scopes[&invoc_id]; </del> <ins> fn resolve_macro_invocation( &mut self, invoc: &Invocation, eager_expansion_root: ExpnId, force: bool ) -> Result<Option<Lrc<SyntaxExtension>>, Indeterminate> { let invoc_id = invoc.expansion_data.id; let parent_scope = match self.invocation_parent_scopes.get(&invoc_id) { Some(parent_scope) => *parent_scope, None => { // If there's no entry in the table, then we are resolving an eagerly expanded // macro, which should inherit its parent scope from its eager expansion root - // the macro that requested this eager expansion. let parent_scope = *self.invocation_parent_scopes.get(&eager_expansion_root) .expect("non-eager expansion without a parent scope"); self.invocation_parent_scopes.insert(invoc_id, parent_scope); parent_scope } }; </ins> let (path, kind, derives, after_derive) = match invoc.kind { InvocationKind::Attr { ref attr, ref derives, after_derive, .. } => (&attr.path, MacroKind::Attr, self.arenas.alloc_ast_paths(derives), after_derive),

Discussion:
This code ([playpen]) compiles on stable but not on nightly and beta: [playpen]: Standard Error Edit: Removed macro Originally posted by in
modify labels: A-macros A-resolve C-bug T-compiler
I updated the snippet to remove the module.
This is a regression from (cc Slightly more minimized reproduction will look like this: performs eager expansion on its arguments and hygienic context of produced by such expansion looks like it was produced by the opaque for some reason, so it's resolved at ' definition site. It maybe either some issue with hygiene infra interacting with eager expansion, but it also may be caused by incorrect spans produced by .
(I'm currently looking into the details.) UPD: I have a fix locally, will submit tomorrow.
Fixed in

() Errors: If either the recursion () or the is removed (), this compiles exactly as expected. Additionally, if I explicitly name my crate, it works as expected, but would be vulnerable to crate renames in user code (can't reproduce in playground because it doesn't build a library).
If you try and build Rustup, you get a similar failure, but without recursion or . Seems that just using another macro and is enough in some circumstances
cc for the hygiene macro in
This code () compiles on stable but not on nightly and beta:
Please, file a separate issue for the regression, I'll prioritize it over pre-existing issues (which the original issue seems to be).
Thanks, I filed it in
Fixed in
Thanks for your work on this!
Change:
RUN . /scripts/android-ndk.sh &&  download_and_make_toolchain android-ndk-r15c-linux-x86_64.zip arm 14 <del> # Note: # Do not upgrade to `openjdk-9-jre-headless`, as it will cause certificate error # when installing the Android SDK (see PR #45193). This is unfortunate, but # every search result suggested either disabling HTTPS or replacing JDK 9 by # JDK 8 as the solution (e.g. https://stackoverflow.com/q/41421340). :| </del> RUN dpkg --add-architecture i386 &&  apt-get update &&  apt-get install -y --no-install-recommends  libgl1-mesa-glx  libpulse0  libstdc++6:i386  <del> openjdk-8-jre-headless  tzdata </del> <ins> openjdk-9-jre-headless  tzdata  wget  python3 </ins> COPY scripts/android-sdk.sh /scripts/ <del> RUN . /scripts/android-sdk.sh &&  download_and_create_avd 4333796 armeabi-v7a 18 5264690 </del> <ins> COPY scripts/android-sdk-manager.py /scripts/ COPY arm-android/android-sdk.lock /android/sdk/android-sdk.lock RUN /scripts/android-sdk.sh </ins> ENV PATH=$PATH:/android/sdk/emulator ENV PATH=$PATH:/android/sdk/tools

Discussion:
We already had at least two different CI issues caused by the Android SDK's sdkmanager: a new license was and sdkmanager failed to accept it with the old command the emulator was updated to a broken (at least for us) version, causing all builds to fail The root cause of those issues is that sdkmanager doesn't support any kind of pinning (as far as I can tell), and any change Google makes can break our CI. Should we develop a pinning mechanism and use it for all the Android SDK components? cc
Change:
} fn should_run_successfully(&self) -> bool { <ins> let pass_mode = self.pass_mode(); </ins> match self.config.mode { <del> RunPass | Ui => self.pass_mode() == Some(PassMode::Run), </del> <ins> Ui => pass_mode == Some(PassMode::Run), RunPass => pass_mode == Some(PassMode::Run) || pass_mode.is_none(), </ins> mode => panic!("unimplemented for mode {:?}", mode), } }

Discussion:
With the change in function shouldrunsuccessfully() of commit : RunPass =true, Ui == Some(PassMode::Run), RunPass | Ui =self.effectivepass_mode() == Some(PassMode::Run), The test cases under run-pass directory are tested for building only, the compiled test cases are not running any more. Does it work as design?
Oh. This is bad. Will fix today. cc (on vacation)
Fixed in
Change:
Option<&'tcx FxHashMap<ItemLocalId, Region>> { desc { "looking up a named region" } } <del> query is_late_bound_map(_: LocalDefId) -> Option<&'tcx FxHashSet<LocalDefId>> { </del> <ins> query is_late_bound_map(_: LocalDefId) -> Option<&'tcx FxIndexSet<LocalDefId>> { </ins> desc { "testing if a region is late bound" } } /// For a given item (like a struct), gets the default lifetimes to be used

Discussion:
The following diff: if done in between s, makes the second check fail with: Aside: that error is printed twice, which is also curious. To reproduce, the following snippet fails on the Playground: I've reported it over to avoid defining a duplicate issue, but now that I've noticed it's a regression, I prefer to risk it being a dup than it going unnoticed. I've also mentioned this over: https://rust- This is causing major breakage with users of who have switched to Rust or up, as showcased by: modify labels: +regression-from-stable-to-stable -regression-untriaged
The bug also reproduces when the is above the impl, but only when that does not change the spans of the impl. It also reproduces when the is add in a different file, or when a or an is instead. This suggests to me that this is somehow related to the overall set of DefIds changing. It does not reproduce when the function is non-async. any ideas? Where there any big refactorings during that time frame that could be the cause of this?
Maybe something related to generators / async functions generates numeric IDs based raw DefIndex values which are then not hashed in a stable way?
Bisection seems to point to
That does sound related. might have an idea.
WG-prioritization assigning priority (). label -I-prioritize +P-critical
Let's keep this open until the backporting situation of the fix is clarified.
was backported to 1.63.0-beta in -- ready to close?
Is this worth a stable backport? The experience of developing async code with this issue isn’t great.
I tried a stable backport locally just to see, but it's non-trivial -- builds on changes from and at least, but that's as far as I investigated before giving up. Maybe a more targeted fix for 1.62.0 could be developed though.
Backported to stable.
Change:
let er = scalar.valid_range_exclusive(bx.cx()); if er.end != er.start <del> && scalar.valid_range.end() > scalar.valid_range.start() </del> <ins> && scalar.valid_range.end() >= scalar.valid_range.start() </ins> { // We want `table[e as usize ± k]` to not // have bound checks, and this is the most

Discussion:
I tried this code: I expected to see this happen: no bounds check Instead, this happened (with ) However adding more variants to the enum makes the bound check go away: generates: Here's a godbolt link to play around further: The MIR of the two cases is identical, but the llvm IR in ZST case is lacking , which I assume (heh!) leads to the bounds check being preserved. (However i don't actually understand LLVM, I'm just reading the diff...) rustc 1.50.0 This sounds very closely related to , but I'm not actually sure if it is. Please reroute as appropriate. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Removing any attributes from the enum also leads to the optimization occurring as expected ().
We don't emit the enum range assumption if the range only contains one element:
claim
Change:
pub const CODEGEN_WORKER_ID: usize = ::std::usize::MAX; <ins> /// `FatalError` is explicitly not `Send`. #[must_use] pub struct WorkerFatalError; </ins> fn spawn_work<B: ExtraBackendMethods>(cgcx: CodegenContext<B>, work: WorkItem<B>) { let depth = time_depth();

Discussion:
Ok, so rustc outputting to /dev/null is a bit pathelogical but it used to not ICE the compiler. If you checkout and from dir tests/suite/futurescore run: rustc --crate-type lib -o /dev/null Then rustc is vexed: (ICEs on stable and nightly) The irony is that this is in the test suite of a rust code minimisation project.... Let me minimise the reproduction of the problem...
Thanks to rust-reduce I managed to get the repro down to: Interestingly it doesn't ICE on playground - I'm guessing playground is on linux?
Indeed
triage: P-medium, removing nomination tag, assigning self.
hmm. I nonetheless see an ICE on my own Linux machine. (There is probably some other reason the ICE does not replicate on the playpen.)
Change:
<ins> // fixed by #66361 // error-pattern: aborting due to 3 previous errors impl W <s(f;Y(;] </ins>

Discussion:
I'm seeing an internal compiler error on the following input (found by ): This error does not occur on stable or beta, nor on a nightly from last week.
The panic is being thrown from here: That code assumes that will always return . However, in this case calls , which returns from here:
cc
Seems fixed in the latest nightly(), marked as E-needstest
I'll add a test for this
Change:
<ins> error[E0310]: the parameter type `T` may not live long enough --> $DIR/issue-53475.rs:10:1 | LL | impl<T> CoerceUnsized<Foo<dyn Any>> for Foo<T> {} | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ...so that the type `T` will meet its required lifetime bounds | help: consider adding an explicit lifetime bound... | LL | impl<T: 'static> CoerceUnsized<Foo<dyn Any>> for Foo<T> {} |       +++++++++ error: aborting due to previous error For more information about this error, try `rustc --explain E0310`. </ins>

Discussion:
into causes an internal compiler panic This causes an internal compiler error: This seems related to , except this is using
:
This is not specific to . The following produces the same kind of error.
modify labels: +regression-from-stable-to-stable The ICE happens on stable regardless of having the feature gate or not (the ICE does not requires a nightly compiler to reproduce)
Change:
<ins> // check-pass // compile-flags: -Z query-dep-graph // edition:2018 // Regression test for ICE related to `await`ing in a method + incr. comp. (#64964) struct Body; impl Body { async fn next(&mut self) { async {}.await } } // Another reproduction: `await`ing with a variable from for-loop. async fn bar() { for x in 0..10 { async { Some(x) }.await.unwrap(); } } fn main() {} </ins>

Discussion:
Hyper fails to compile on Rust master () <details</details
fyi
I also get this with on futures-rs <details</details
getting this while trying to compile rust itself(): <details</details
Confirming bisection range is
guessing it's PR attempting rust compilation with reverted like so: <details</detailsthis might take a while...
It's not it, surprisingly enough(for me). (manually)Reverting that PR fails the same. (that is, applied this on top of rust commit ) <details</details<details</details
? This PR adds to typeck-table which is stable-hashed, and the hyper ICE is happening on by querying that table, which looks relevant.
I've reversed-applied the patch from (aka reverted PR ) on top of rust like this , and the results are(74mins later, at least): it passed!(failed later, on clippy_lints, but that's unrelated) So that's the problematic PR, thanks Since rust got updated compared to my previous try, I'll re-apply this PR on top of what already worked just now to see if it indeed fails with it! <sWill post new comment with the update.</sConfirmed the ICE is back with that PR, using 's test-case: <details</details
Minimized test-case:
Thanks self-assigning to look into this (since I caused it with ) - if anyone else wants to look into fixing also, please feel free.
I have a WIP fix:
Change:
} } } <del> self.ensure_complete_parse(false); </del> <ins> self.ensure_complete_parse(false, "statement"); </ins> Some(ret) } fn make_ty(self: Box<ParserAnyMacro<'a>>) -> Option<P<ast::Ty>> { let ret = panictry!(self.parser.borrow_mut().parse_ty()); <del> self.ensure_complete_parse(true); </del> <ins> self.ensure_complete_parse(false, "type"); </ins> Some(ret) } }

Discussion:
This compiles: I expected this to be rejected, simply because doesn't parse as a type.

afaik, it's because the context where you're using the macro (expr, item, etc.) stopped parsing before that token. We should mention that context.
Is this fixed? I think this was fixed the referenced pull request.
I'd prefer a message like
Change:
<ins> // run-pass #[repr(u32)] pub enum Foo { // Greater than or equal to 2 A = 2, } pub enum Bar { A(Foo), // More than two const variants B, C, } fn main() { match Bar::A(Foo::A) { Bar::A(_) => (), _ => unreachable!(), } } </ins>

Discussion:
<!-- Thank you for filing a regression report! A regression is something that changed between versions of Rust but was not supposed to. Please provide a short summary of the regression, along with any information you feel is relevant to replicate it. --This code: () Panics with the message from inside futures-rs. The code driving this particular object is also in futures-rs , but this code couldn't possibly result in the panic that we see. That would require the Join future to get polled after it was completed, but that future is only ed, so this should never happen. This is a regression from stable to beta, bisected to PR . It still exists in nightly. <details<summaryBacktrace</summary<p</p</details modify labels: +regression-from-stable-to-beta -regression-untriaged <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Note that this regression is in the newly-promoted-to-beta 1.57, not 1.56 which is being released as stable this week.
Minimized:
claim
label: -A-async-await
Assigning as and removing .
(Posted in the fix PR as well for redundancy) For the record, while I may have seen I do not recall ever reviewing the change it links to (), which is where the bug was introduced (I was tipped off by the closures which did not exist in the version of that PR I reviewed).
the fix still needs a backport
This was backported in
Change:
} let outlives_environment = OutlivesEnvironment::new(param_env); <del> infcx .resolve_regions_and_report_errors(impl_c.def_id.expect_local(), &outlives_environment); </del> <ins> infcx.check_region_obligations_and_report_errors( impl_c.def_id.expect_local(), &outlives_environment, ); </ins> }); }

Discussion:
into causes an internal compiler panic This causes an internal compiler error: This seems related to , except this is using
:
This is not specific to . The following produces the same kind of error.
modify labels: +regression-from-stable-to-stable The ICE happens on stable regardless of having the feature gate or not (the ICE does not requires a nightly compiler to reproduce)
Change:
assert_eq!(span.lo().0, 4); assert_eq!(span.hi().0, 5); <del> // A non-empty span at the last byte should advance to create an empty // span pointing at the end of the file. </del> <ins> // Reaching to the end of file, return a span that will get error with `span_to_snippet` </ins> let span = Span::with_root_ctxt(BytePos(4), BytePos(5)); let span = sm.next_point(span); assert_eq!(span.lo().0, 5); <del> assert_eq!(span.hi().0, 5); </del> <ins> assert_eq!(span.hi().0, 6); assert!(sm.span_to_snippet(span).is_err()); </ins> <del> // Empty span pointing just past the last byte. </del> <ins> // Reaching to the end of file, return a span that will get error with `span_to_snippet` </ins> let span = Span::with_root_ctxt(BytePos(5), BytePos(5)); let span = sm.next_point(span); assert_eq!(span.lo().0, 5); <del> assert_eq!(span.hi().0, 5); </del> <ins> assert_eq!(span.hi().0, 6); assert!(sm.span_to_snippet(span).is_err()); </ins> }

Discussion:
This malformed code () hangs the compiler: Found by fuzzing with a . must be defined as a named-field struct (not a tuple struct or unit struct), although it can have 0 fields. must be the last token to produce the hang: No opening brace (note that braces are required for literals of named-field structs) No closing delimiters Not even a comment If I understand correctly, the hang occurs in LateResolutionVisitor, with never finishing (while calling various functions such as and ) This also hangs. I'm guessing it's the same bug. : with: <details</summary<p</p</detailsregressed nightly: nightly-2022-10-21 regressed commit: (PR ) label +regression-from-stable-to-nightly +I-hang <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
claim
I can not reproduce it with latest code, did I missed anything?
Great cactch Confirmed the error is only triggered by commit: The root cause is I changed the edge corner case in : We think won't return a span which outside of source file, so is a valid one, then will always return a valid span, and we get from when reaching the end of source. So, there is a loop in previous , which will run infinitely loop: Lucky, my another PR merged at last day, this PR refactored this function:
Verif, I no longer get a hang after rollup Do you want to add one or two of these as tests?
Yes, we'd better add a testcase for it. I'm thinking whether we sould in when reaching to the end of source, so that may get an error.
This testcase seems not easy to be : If so, the trigger point will do not exist,
label -I-prioritize
There's an alternative kind of annotation for patterns that should work for this case:
Change:
[dependencies] env_logger = { version = "0.4", default-features = false } log = "0.3" <del> pulldown-cmark = { version = "0.0.14", default-features = false } </del> <ins> pulldown-cmark = { version = "0.1.0", default-features = false } </ins> html-diff = "0.0.4" [build-dependencies]

Discussion:
generates different HTML under and not. Not only does this trigger what's effectively a spurious warning, but it doesn't render correctly either. cc , marking this as p-high
This was fixed by google/pulldown-cmark rustdoc just needs to update its version of pulldown-cmark.
The thread in that issue says it was released in 0.0.15. we're pulling in 0.0.14 for rustdoc, but also 0.1.0 for mdbook. I'll see if i can update the dependency for rustdoc and pull it in.
updates Pulldown for rustdoc and fixes this.
I am not sure this actually fixes the warnings, as they use different IDs and such. I'm testing this locally right now though; expect an update in ~20 minutes