jiebi/CodeConvo huggingface dataset:
Change:
<ins> error[E0279]: the requirement `for<'de> 'de : ` is not satisfied (`expected bound lifetime parameter 'de, found concrete lifetime`) --> $DIR/issue-54302.rs:23:5 | LL |     assert_deserialize_owned::<&'static str>(); |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | = note: required because of the requirements on the impl of `for<'de> Deserialize<'de>` for `&'static str` = note: required because of the requirements on the impl of `DeserializeOwned` for `&'static str` note: required by `main::assert_deserialize_owned` --> $DIR/issue-54302.rs:22:5 | LL |     fn assert_deserialize_owned<T: DeserializeOwned>() {} |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ error: aborting due to previous error For more information about this error, try `rustc --explain E0279`. </ins>

Discussion:
This is a regression between rustc 1.20.0 and 1.21.0. 20 correctly rejects this code with the following error.
Tagging P-high because this very much affects Serde.
Same issue using Serde traits: (One possible) output:
Even better, :
Perhaps we can bisect this regression? (e.g., with )
Bisected to correct behavior in nightly-2017-07-07 -- rustc 1.20.0-nightly ( 2017-07-06), incorrect behavior in nightly-2017-07-08 -- rustc 1.20.0-nightly ( 2017-07-07). That range is Looks like
visited for triage. Assigning to
thanks, very helpful!
I think the bug is here: In particular, I think the condition is not strong enough. doesn't consider region annotations, so we probably need to not use this logic if there are any regions. But I'm wondering if the whole concept is flawed. I'm a bit fearful of regions being introduced through associated type normalization.
I have a fix.
Of course, any approach that relies on any lifetimes in the affected trait-ref is fatally flawed - here's an example where the trait ref is the region-free .
I'm not really sure what your example is meant to illustrate. That said, running that on my branch gives an error: This seems like the error I would expect, more or less. We try to use the impl to prove that but we fail to do so (because of the side condition that it adds).
BTW, the check looks like it happened because I used there, and an explicit check when he changed in to note be made true by late-bound regions.
visited for triage. bug seems to be being dealt with, assuming that PR is eventually deemed as passing muster...
Yes, I think that the "no late-bound regions" check was basically a workaround for this same problem; I removed it in the PR since I think it has a "more correct" fix.
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. // aux-build:attr-on-trait.rs #![feature(proc_macro)] extern crate attr_on_trait; trait Foo { #[attr_on_trait::foo] fn foo() {} } impl Foo for i32 { fn foo(&self) {} } fn main() { 3i32.foo(); } </ins>

Discussion:
Given this procedural macro: and this crate: Building: I saw no output :( I find that is resolved, it just doesn't seem to get expanded!
cc
I saw this earlier and I've been thinking about it. I don't remember anything special in the invocation collector concerning trait methods though. Isn't there some codepath that strips attributes from trait methods, stuff like that doesn't make sense on them?
Not that I know of -- I'll do some debugging to figure out where the issue is (, , etc.).
Ok I've debugged this a bit and I think I've narrowed it down to resolve. The attribute is first resolved as and then resolved as which triggers to I think fill in a "dummy" invocation, which ends up effectively stripping the item. Still trying to figure out why this isn't resolved right.
In attempting to debug further I think I'm pretty far out of my league here. I think what's happening is that resolution is attempting to resolve in the "trait's namespace", but that predictably fails and it in theory should go up to the parent module namespace and then do resolution there again, right? What I've found though is that is returning because while the trait does have a parent which presumably points to the crate's module they both have an of . The loop in currently enforces which means that it can't go up one level. Does that ring any bells or Or maybe this is all a red herring?
Haven't looked into this yet, but this explanation makes sense. I believe the issue here is that shouldn't be called with a trait module. enforces for modules since in the normal, non-hygienic case, modules don't have lexical parents (except for the prelude). That is, However, due to hygiene, the following resolves: If this issue is as I expect, I can fix quickly tomorrow.
Ah ok, I'll leave you to it as I suspect you'll find it much more quickly than I will! If you run out of time though just let me know and I will resume digging!
Change:
STD_REF_MUT = "StdRefMut" STD_REF_CELL = "StdRefCell" STD_NONZERO_NUMBER = "StdNonZeroNumber" <ins> STD_PATH = "StdPath" STD_PATHBUF = "StdPathBuf" </ins> STD_STRING_REGEX = re.compile(r"^(alloc::([a-z_]+::)+)String$")

Discussion:
I tried this code (as package ): Run the following, which will break at , step the next 4 lines () to define the variables, then print twice -- the first time will succeed, the second time will fail: I expected to see this happen: would work the same no matter how many times I called it, instead everything seems to be undefined after the first call. Below I show that seems to work (including multiple times), works (including multiple times), but after a single call to , neither of these works anymore: Oddly, if I break on filename / line number instead of function name, it seems to work as expected: I'm using from a git checkout from yesterday:
Realized was not a but an ; have changed to . Don't think it changes the rest, behavior still the same with .
Works just fine in gdb for me: Rust-lldb doesn't want to load for me at all, but plain lldb works fine too. For reference I'm using lldb version 14.0.6.
If only gdb worked on aarch64-darwin! But thanks for prompting me to try other OS -- I can confirm that I do not see the bug using rust-lldb on x86_64-linux, so this may be isolated to one of darwin / aarch64 / aarch64-darwin. (Still repros for me on aarch64-darwin with lldb 16.0.6.)

If is a PathBuf, printing it from lldb does not give a string representation as I would expect. If I explicitly refer to it shows "None" for the inner OsString: If I use I finally get a vec representation.
I've details in .
Visited during wg-debugging triage. We were not able to conclusively repro but we're confident this is probably still an issue. Triaging as P-medium for now.
Change:
<ins> error[E0658]: a non-static lifetime is not allowed in a `const` --> $DIR/forbid-non-static-lifetimes.rs:9:22 | LL |     test::<{ let _: &'a (); 3 },>(); |                      ^^ | = note: see issue #44580 <https://github.com/rust-lang/rust/issues/44580> for more information = help: add `#![feature(const_generics)]` to the crate attributes to enable error[E0658]: a non-static lifetime is not allowed in a `const` --> $DIR/forbid-non-static-lifetimes.rs:23:16 | LL |     [(); (|_: &'a u8| (), 0).1]; |                ^^ | = note: see issue #44580 <https://github.com/rust-lang/rust/issues/44580> for more information = help: add `#![feature(const_generics)]` to the crate attributes to enable error: aborting due to 2 previous errors For more information about this error, try `rustc --explain E0658`. </ins>

Discussion:
Nightly on playground <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
we should forbid lifetimes in anonymous constants to avoid this issue.

results in
Could this be a duplicate of ?
:+1: This probably has the same fix. I do think that the issues are different enough to keep this one open though
Change:
<ins> error[E0572]: return statement outside of function body --> $DIR/issue-86721-return-expr-ice.rs:15:20 | LL |     fn foo(a: [(); return]); |                    ^^^^^^ error: aborting due to previous error For more information about this error, try `rustc --explain E0572`. </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. --<!-- 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
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-low
This is a regression considering it doesn't happen in beta.
Change:
#[test] #[cfg_attr(target_os = "emscripten", ignore)] <ins> fn wait_timeout_until_wait() { let m = Arc::new(Mutex::new(())); let c = Arc::new(Condvar::new()); let g = m.lock().unwrap(); let (_g, wait) = c.wait_timeout_until(g, Duration::from_millis(1), || { false }).unwrap(); // no spurious wakeups. ensure it timed-out assert!(wait.timed_out()); } #[test] #[cfg_attr(target_os = "emscripten", ignore)] fn wait_timeout_until_instant_satisfy() { let m = Arc::new(Mutex::new(())); let c = Arc::new(Condvar::new()); let g = m.lock().unwrap(); let (_g, wait) = c.wait_timeout_until(g, Duration::from_millis(0), || { true }).unwrap(); // ensure it didn't time-out even if we were not given any time. assert!(!wait.timed_out()); } #[test] #[cfg_attr(target_os = "emscripten", ignore)] fn wait_timeout_until_wake() { let pair = Arc::new((Mutex::new(false), Condvar::new())); let pair_copy = pair.clone(); let g = m.lock().unwrap(); let t = thread::spawn(move || { let &(ref lock, ref cvar) = &*pair2; let mut started = lock.lock().unwrap(); thread::sleep(Duration::from_millis(1)); started = true; cvar.notify_one(); }); let (g2, wait) = c.wait_timeout_until(g, Duration::from_millis(u64::MAX), |&notified| { notified }).unwrap(); // ensure it didn't time-out even if we were not given any time. assert!(!wait.timed_out()); assert!(*g2); } #[test] #[cfg_attr(target_os = "emscripten", ignore)] </ins> fn wait_timeout_wake() { let m = Arc::new(Mutex::new(())); let c = Arc::new(Condvar::new());

Discussion:
Yes, another incarnation of . and also have this issue. Note that is an error and has a test for it. cc
Does this also date back to 1.0, like did?
Yes. The fix would be technically a breaking change.
Change:
mod plumbing; pub use plumbing::QueryCtxt; use rustc_query_system::query::*; <ins> #[cfg(parallel_compiler)] pub use rustc_query_system::query::{deadlock, QueryContext}; </ins> mod keys; use keys::Key;

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 glacier <!-- 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 this is the alt master rustc, installed via <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
This features a parallel-compiler-only bug. It is a variant of It is ultimately a blocker for and might be a blocker for but itself does not need to be fixed any time soon.
Remark from
This is not a problem with the implementation logic of the deadlock handler, but a very hard-to-trace thread scheduling vulnerability. If we add the following non-functional statement in of the function, this problem will disappear. Get rid of in deadlock handler can fix this. I just submited a to fix a set of ui test failures, including this issue.
Change:
} } <del> // hidden trait for specializing iterator methods // could be generalized but is currently only used for StepBy trait StepBySpecIterator { type Item; fn spec_next(&mut self) -> Option<Self::Item>; } impl<I> StepBySpecIterator for StepBy<I> where I: Iterator, { type Item = I::Item; #[inline] default fn spec_next(&mut self) -> Option<I::Item> { if self.first_take { self.first_take = false; self.iter.next() } else { self.iter.nth(self.step) } } } impl<T> StepBySpecIterator for StepBy<ops::Range<T>> where T: Step, { #[inline] fn spec_next(&mut self) -> Option<Self::Item> { self.first_take = false; if !(self.iter.start < self.iter.end) { return None; } // add 1 to self.step to get original step size back // it was decremented for the general case on construction if let Some(n) = self.iter.start.add_usize(self.step+1) { let next = mem::replace(&mut self.iter.start, n); Some(next) } else { let last = self.iter.start.clone(); self.iter.start = self.iter.end.clone(); Some(last) } } } impl<T> StepBySpecIterator for StepBy<ops::RangeInclusive<T>> where T: Step, { #[inline] fn spec_next(&mut self) -> Option<Self::Item> { self.first_take = false; self.iter.compute_is_empty(); if self.iter.is_empty.unwrap_or_default() { return None; } // add 1 to self.step to get original step size back // it was decremented for the general case on construction if let Some(n) = self.iter.start.add_usize(self.step+1) { self.iter.is_empty = Some(!(n <= self.iter.end)); let next = mem::replace(&mut self.iter.start, n); Some(next) } else { let last = self.iter.start.clone(); self.iter.is_empty = Some(true); Some(last) } } } </del> // StepBy can only make the iterator shorter, so the len will still fit. #[stable(feature = "iterator_step_by", since = "1.28.0")] impl<I> ExactSizeIterator for StepBy<I> where I: ExactSizeIterator {}

Discussion:
The following snippet demonstrates the problem: It prints: I expect second iterator to produce the same result as for the third one.
Regression from 1.28.0 to 1.29.0. Introduced in
The problem is interaction between and . ignores the inner working of StepBy. Test-case reduced to using without .
From a cursory look, it seems to me that the problem is that and are out of sync. StepBy specifically allows for the underlying iterator, either or . If both and follow the same one, the bug shouldn't occur. In other words, if is specialized and overrides the default, then needs to be specialized as well.
Change:
let source = sess .source_map() .new_source_file(FileName::inline_asm_source_code(&buffer), buffer); <del> let source_span = Span::with_root_ctxt(source.start_pos, source.end_pos); let spans: Vec<_> = spans.iter().map(|sp| source_span.from_inner(*sp)).collect(); </del> <ins> let spans: Vec<_> = spans .iter() .map(|sp| { Span::with_root_ctxt( source.normalized_byte_pos(sp.start as u32), source.normalized_byte_pos(sp.end as u32), ) }) .collect(); </ins> err.span_note(spans, "instantiated into assembly here"); }

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. --Hi I got two confusions when trying to use and integrate some assembly codes. got the internal compiler error listed as below; error messages look wierd with arrows confusingly pointing to blankets or some existing labels. (If I just misunderstood them please correct me) Any Help would be appreciated very much :D func.S: bug.s: <!-- 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
You can't use with assembly code used by . This requires running a C pre-processor over the assembly code which can only be done with . However the assertion failure is still a real issue in the compiler.
! () Is it not allowed to use as comments?
It won't include , which is what the originally assembly code intended to do. It will instead just be parsed as a comment and ignored.
Ohh ok I get it. Thank you for your explanations :D
I can't reproduce the assertion failure in the latest rustc:
Maybe try this one? I try to update the rustc version, but the error still exists. I use and to check the assembly files that can and can't reproduce the ICE, and find some differences: their encodings differ with terminators, one with (with ICE) and another with only (without ICE). Also, error information about compiling with assembly files with displays arrows confusingly pointing to blankets, but for files with only , error info is the same as yours'. Arrows point to the beginning of the tags or instructions, which makes sense in a way. I don't know whether the terminator is the root cause. Hope that could help figure it out. The new meta info I get after updating the rustc version: <!-- 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</detailsThe files that can cause the compiler error: func.S -bug.S - The files that won't cause the compiler error: func.S -bug.S -
Change:
<ins> error: any use of this value will cause an error --> $DIR/issue-49296.rs:18:1 | LL | const X: u64 = *wat(42); | ^^^^^^^^^^^^^^^--------^ |                | |                dangling pointer was dereferenced | = note: #[deny(const_err)] on by default error: aborting due to previous error </ins>

Discussion:
produces without any additional info. If the value is not dereferenced, but instead fed to llvm, we get an ICE in trans: results in Even though it should be reporting a dangling pointer const eval error
Both samples now require The first reports a dereferenced dangling pointer and the second sample no longer triggers an ICE
Thanks for checking up on this! So all we need is a ui test for the first example, because I don't think we have a regression test for that error. The second one definitely has a bunch of tests.
Change:
fn check_stmt(&mut self, cx: &EarlyContext<'_>, s: &ast::Stmt) { if let StmtKind::Local(ref local) = s.kind { <del> self.check_unused_parens_pat(cx, &local.pat, true, false, (false, false)); </del> <ins> self.check_unused_parens_pat(cx, &local.pat, true, false, (true, false)); </ins> } <Self as UnusedDelimLint>::check_stmt(self, cx, s)

Discussion:
Rustc suggests incorrect fixes for #[warn(unusedparens)] for these patterns. No response Rustc version: (the same issue with the stable 1.73.0 rustc). <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
claim
Change:
} sidebar.push_str("</div>"); <ins> } else if let CtorKind::Fn = s.struct_type { sidebar .push_str("<h3 class="sidebar-title"><a href="#fields">Tuple Fields</a></h3>"); </ins> } }

Discussion:
Rustdoc should expose doc comments written on tuple fields: Tagging based on conversation on IRC.
This issue also applies to tuple variant fields:
It promises to be very interesting from a design point of view. We'll to think about how to render this nicely.
Change:
<ins> error: `$x:expr` may be followed by `$y:tt`, which is not allowed for `expr` fragments --> $DIR/same-sequence-span.rs:15:18 | LL |     (1 $x:expr $($y:tt,)* |                  ^^^^^ not allowed after `expr` fragments | = note: allowed there are: `=>`, `,` or `;` error: `$x:expr` may be followed by `=`, which is not allowed for `expr` fragments --> $DIR/same-sequence-span.rs:16:18 | LL |                $(= $z:tt)* |                  ^ not allowed after `expr` fragments | = note: allowed there are: `=>`, `,` or `;` error: `$x:expr` may be followed by `$y:tt`, which is not allowed for `expr` fragments --> $DIR/same-sequence-span.rs:20:1 | LL | proc_macro_sequence::make_foo!(); | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ not allowed after `expr` fragments | = note: allowed there are: `=>`, `,` or `;` error: `$x:expr` may be followed by `=`, which is not allowed for `expr` fragments --> $DIR/same-sequence-span.rs:20:1 | LL | proc_macro_sequence::make_foo!(); | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ not allowed after `expr` fragments | = note: allowed there are: `=>`, `,` or `;` error: aborting due to 4 previous errors </ins>

Discussion:
Steps to reproduce: Extract the archive Run Run The following generated macro is a likely source of error: However, directly putting this macro does not seem to cause a compiler crash: It appears that the crash only occurs when the macro-by-example generated from a proc-macro. The full error message: Using gives a similar result: You can try removing the first one or two parts in the macro pattern and the error disappears.
cc
cc
The offending code is here: TBH, I'm not really sure what it is checking, and I don't have time to look into it right now (work is busy)... Sorry about that. It seems that the procmacro is somehow generating some tokens or TokenTrees (especially in a [i.e. a token repetition]) that don't have spans somehow. is that even possible? It looks like pnkfelix wrote this code originally 4 years ago. It hasn't been touched in years. do you know if there have been any changes in proc_macros that could have exposed this behavior?