jiebi/CodeConvo huggingface dataset:
Change:
self.update_macro_reachable_def(hir_id, def_kind, vis, defining_mod); } } if let Some(exports) = self.tcx.module_exports(module_def_id) { for export in exports { if export.vis.is_accessible_from(defining_mod, self.tcx) { if let Res::Def(def_kind, def_id) = export.res { let vis = def_id_visibility(self.tcx, def_id).0; if let Some(hir_id) = self.tcx.hir().as_local_hir_id(def_id) { <del> self.update_macro_reachable_def( hir_id, def_kind, vis, defining_mod, ); </del> <ins> self.update_macro_reachable_def(hir_id, def_kind, vis, defining_mod); </ins> } } }

Discussion:
Seems to be something to do with Rocket. Having a on the internal function is causing the compiler to blow up. Version: Stack trace:
I think this issue might be better-suited for the Rocket repository.
Ah OK. The output told me to file an issue here so I thought it might be a compiler problem rather than something specific to Rocket. Can we leave it open for a bit just until it's confirmed as Rocket-specific?
Hm, this bug probably originates with interesting codegen in Rocket, but is likely a bug in rustc in the end. I would keep it here, though letting Rocket know about it might not be a bad idea.
I'm going to label this as P-high for now since it affects Rocket. cc re. macros & privacy.
Without looking too deeply I would wager that we're getting a here, although it could be any other which would be worrisome:
Would be great to have a reproducer that did not depend on Rocket and codegen, if it is possible.
Trying to get a simple reproducible example and am unable to :( It got a little time-consuming and I really need to get work done so have worked around it for now. I could possibly publish everything in a repo, but it would still be rocket + codegen and not a very simple example!
Latest nightly (2019-08-11) still panics, but with different error message:
Also as a sidenote: Rocket master does not ICE anymore. The ICE "was fixed" by so it may be a problem with decl_macro ?
I would still wan't not to ICE on the face of malformed input.
For future reference, when panicking or using for not finding what you expect it is a good idea to include in the message what the found value was. :)
I think you got me wrong. I haven't said, that this should be closed because upstream code has changed, but I said, that upstream does not ICE anymore, so I looked into it, what caused it to not ICE anymore.

I try to go that ;) Confirmed, that it is related to decl maros modify labels: +A-macros-2.0
I need your help with the tags here please ^^
<details<summaryBacktraces</summary<details<summary60960a260</summary</details<details<summarydddb7fca0</summary</details</details modify labels: -E-needs-mcve
What is the appropriate visibility scope for ? is failing because we get the following instead: In my mind the expected semantics of this could would be to scope to inside , but currently with a macro by example it would be scoped to the current module. I can implement either semantic. Edit: I'm talking out of my ass, matches my intuition. Don't know why I thought otherwise.
Change:
| LL | ...♭♮♯♰♱♲♳♴♵♶♷♸♹♺♻♼♽♾♿⚀⚁⚂⚃⚄⚅⚆⚈⚉4"; let _: () = 42;  let _: &str = "🦀☀☁☂☃☄★☆☇☈☉☊☋☌☍☎☏☐☑☒☓  ☖☗☘☙☚☛☜☝☞☟☠☡☢☣☤☥☦☧☨☩☪☫☬☭☮☯☰☱☲☳☴☵☶☷☸☹☺☻☼☽☾☿♀♁♂♃♄... |                                            --   ^^ expected `()`, found integer <del> |                                                     | </del> <ins> |                                            | </ins> |                                            expected due to this error: aborting due to previous error

Discussion:
In we account for the visible char width when calculating the label and span positions, but we do not do so for the vertical bar tying them together, causing the following output: where it should be (Found during )
I would like to solve this as a first time issue. Best with some pointers where to start :)
the code that draws the vertical lines is at and the one that draws the span labels is right below I think the error might be using instead of , but I'm not entirely certain. If this is your first time compiling , you probably want to read the , but the TL;DR: is "run to build the compiler up to the first stage and update the test output files". You might also want to wait until the linked PR is merged so you have a test case, unless you wish to come up with a new one (look for a test that has multiple labels in the same span and pad the source to the left with unicode chars on non-1 width).
Thank you! I did read the rustc guide, and even compiled it on my own once. But thanks for the direction, and the note to the PR. I'll do my best :wink:
Change:
use rustc::ty::{self, Ty, TypeAndMut, TypeFoldable}; use rustc_ast::ast::FloatTy; use rustc_span::symbol::sym; <ins> use rustc_target::abi::LayoutOf; </ins> use rustc::mir::interpret::{InterpResult, PointerArithmetic, Scalar}; use rustc::mir::CastKind;

Discussion:
Compiling this code on : results in ICE. Casting to anything smaller than /(, , , , , etc) also results in ICE. Casting to anything same size or larger(, , , , etc) works fine. Positive discriminant values also work fine. Version of rustc: (on rust playground) Compiler flags listed as used:
indicates that this was injected in Rust 1.40
Thanks for the report! Please always include the ICE message. This time, it seems to be
Change:
[items]: ../reference.html#items <ins> # Recursive macros A macro's expansion can include more macro invocations, including invocations of the very same macro being expanded.  These recursive macros are useful for processing tree-structured input, as illustrated by this (simplistic) HTML shorthand: ```rust # #![allow(unused_must_use)] macro_rules! write_html { ($w:expr, ) => (()); ($w:expr, $e:tt) => (write!($w, "{}", $e)); ($w:expr, $tag:ident [ $($inner:tt)* ] $($rest:tt)*) => {{ write!($w, "<{}>", stringify!($tag)); write_html!($w, $($inner)*); write!($w, "</{}>", stringify!($tag)); write_html!($w, $($rest)*); }}; } fn main() { #   // FIXME(#21826) use std::fmt::Write; let mut out = String::new(); write_html!(&mut out, html[ head[title["Macros guide"]] body[h1["Macros are the best!"]] ]); assert_eq!(out, "<html><head><title>Macros guide</title></head> <body><h1>Macros are the best!</h1></body></html>"); } ``` # Debugging macro code To see the results of expanding macros, run `rustc --pretty expanded`. The output represents a whole crate, so you can also feed it back in to `rustc`, which will sometimes produce better error messages than the original compilation. Note that the `--pretty expanded` output may have a different meaning if multiple variables of the same name (but different syntax contexts) are in play in the same scope. In this case `--pretty expanded,hygiene` will tell you about the syntax contexts. `rustc` provides two syntax extensions that help with macro debugging. For now, they are unstable and require feature gates. * `log_syntax!(...)` will print its arguments to standard output, at compile time, and "expand" to nothing. * `trace_macros!(true)` will enable a compiler message every time a macro is expanded. Use `trace_macros!(false)` later in expansion to turn it off. </ins> # Further reading The [advanced macros chapter][] goes into more detail about macro syntax. It

Discussion:
As of the original docs on recursive macros are gone. We should have an example that clearly illustrates the increased power vs. the built-in repetition operator.
Change:
} } <ins> function findParentElement(elem, tagName) { do { if (elem && elem.tagName === tagName) { return elem; } } while (elem = elem.parentNode); return null; } </ins> document.onkeypress = handleShortcut; document.onkeydown = handleShortcut; document.onclick = function(ev) {

Discussion:
Stable documentation (e.g. ): Click on to collapse everything Click on in Page will be scrolled to the . Nightly documentation (e.g. ): Click on to collapse everything Click on in Nothing will happen, because the is inside a collapsed outer section.
Another example: Click the word in the description on the page Nothing happens, making it appear that the link is broken. Since trait impls are collapsed by default, AFAIK there is no way to properly link to them. I'm guessing this would need to be implemented in and , and check if the block is hidden?
Change:
```rust let captured_var = 10; <del> let closure_no_args = |&:| println!("captured_var={}", captured_var); </del> <ins> let closure_no_args = || println!("captured_var={}", captured_var); </ins> <del> let closure_args = |&: arg: i32| -> i32 { </del> <ins> let closure_args = |arg: i32| -> i32 { </ins> println!("captured_var={}, arg={}", captured_var, arg); arg // Note lack of semicolon after 'arg' };

Discussion:
and are obsolete, but is not.
I think I spotted the problem, testing...
Fix in
Change:
<ins> error[E0432]: unresolved import `self::nu` --> $DIR/issue-99695.rs:11:20 | LL |     pub use self::{nu, other_item as _}; |                    ^^ no `nu` in `m` | = note: this could be because a macro annotated with `#[macro_export]` will be exported at the root of the crate instead of the module where it is defined help: a macro with this name exists at the root of the crate | LL ~     use ::nu; LL ~ pub use self::{other_item as _}; | error: aborting due to previous error For more information about this error, try `rustc --explain E0432`. </ins>

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: <details<summaryIf the starting order is reversed, the suggestion puts the macro first in the tree</summary</detailsThis is suggesting to change the code to itself It needs to move the import into a tree; the easy way is to make a new statement (and let rustfmt clean that up); the medium way is to find an existing context; the hard way is when a tree root doesn't already exist (or isn't immediately a tree at that point) determine what the code is using and match that. Related: label +D-confusing +D-incorrect
In this case, the ideal solution is actually to write just and get the import from legacy-lexical-macro-scope into the namespace. I originally hit this with just multiple macros in the use tree, and removing the was the correct fix. I "simplified" for the error report to use a second non-macro item here (to reduce the number of diagnostics). So bonus challenge: handle this case properly and only emit a single help: <details
label +D-invalid-suggestion It's not producing invalid code, but it's surely suggesting a fix which will cause an error (the identical one).
Change:
<ins> error[E0277]: expected a `FnMut<(char,)>` closure, found `String` --> $DIR/issue-104961.rs:4:19 | LL |     x.starts_with("hi".to_string() + " you") |       ----------- ^^^^^^^^^^^^^^^^^^^^^^^^^ the trait `Pattern<'_>` is not implemented for `String` |       | |       required by a bound introduced by this call | = note: the trait bound `String: Pattern<'_>` is not satisfied = note: required for `String` to implement `Pattern<'_>` note: required by a bound in `core::str::<impl str>::starts_with` --> $SRC_DIR/core/src/str/mod.rs:LL:COL help: consider borrowing here | LL |     x.starts_with(&("hi".to_string() + " you")) |                   ++                         + error[E0277]: expected a `FnMut<(char,)>` closure, found `String` --> $DIR/issue-104961.rs:9:19 | LL |     x.starts_with("hi".to_string()) |       ----------- ^^^^^^^^^^^^^^^^ the trait `Pattern<'_>` is not implemented for `String` |       | |       required by a bound introduced by this call | = note: the trait bound `String: Pattern<'_>` is not satisfied = note: required for `String` to implement `Pattern<'_>` note: required by a bound in `core::str::<impl str>::starts_with` --> $SRC_DIR/core/src/str/mod.rs:LL:COL help: consider borrowing here | LL |     x.starts_with(&"hi".to_string()) |                   + error: aborting due to 2 previous errors For more information about this error, try `rustc --explain E0277`. </ins>

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 --
claim
The code here: Seems we can only get more context from , with only we can not know whether the current code snippet is an ident or a more complicated expression. The current is . An completed solution should make sure we get something like in ? A hack I'm thinking is checking whether contains spaces, if so we suggest it like:
I guess we have more similar issues for other suggestions come from .
This is an similar case, but we handle it well: Output is: The codepath is different, we take care parenthesis here, with :
Change:
<ins> //@ check-pass #![recursion_limit = "1024"] // Really high recursion limit ^ // Test that ensures we're filtering projections by def id before matching // them in `match_projection_projections`. use std::ops::{Add, Sub}; pub trait Scalar {} pub trait VectorCommon: Sized { type T: Scalar; } pub trait VectorOpsByValue<Rhs = Self, Output = Self>: VectorCommon + Add<Rhs, Output = Output> + Sub<Rhs, Output = Output> { } pub trait VectorView<'a>: VectorOpsByValue<Self, Self::Owned> + VectorOpsByValue<Self::Owned, Self::Owned> { type Owned; } pub trait Vector: VectorOpsByValue<Self> + for<'a> VectorOpsByValue<Self::View<'a>> { type View<'a>: VectorView<'a, T = Self::T, Owned = Self> where Self: 'a; } pub trait MatrixCommon { type V: Vector; } fn main() {} </ins>

Discussion:
I have a linear algebra based project () which has a set of Scalar, Vector and Matrix traits that refer to each other via associated traits. On stable (rustc 1.77.1) this builds fine, but on beta (1.78.0) and nightly (1.79.0) the build hangs (). A MRE is: If I look at the compiler log with RUSTCLOG=TRACE I see an endless repitition of text like: Note that if I remove the trait everything builds fine. The bug does not exist in stable: : The bug exists in beta and nightly: : : <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summaryBacktrace</summary<phere is some more of the logs: </p</details
IIUC that's from cc (it also only happens with the old solver ofc)
I'm fascinated that this wasn't fixed by . Perhaps there's somewhere else we need to be calling instead of in the solver...
Oh lol, I found the bug.
Change:
} (GenericArgKind::Type(v1), GenericArgKind::Type(v2)) => { <del> let ok = self.at(cause, param_env).eq(v1, v2)?; obligations.extend(ok.into_obligations()); </del> <ins> TypeRelating::new( self, QueryTypeRelatingDelegate { infcx: self, param_env, cause, obligations: &mut obligations, }, ty::Variance::Invariant, ) .relate(&v1, &v2)?; </ins> } (GenericArgKind::Const(v1), GenericArgKind::Const(v2)) => { <del> let ok = self.at(cause, param_env).eq(v1, v2)?; obligations.extend(ok.into_obligations()); </del> <ins> TypeRelating::new( self, QueryTypeRelatingDelegate { infcx: self, param_env, cause, obligations: &mut obligations, }, ty::Variance::Invariant, ) .relate(&v1, &v2)?; </ins> } _ => {

Discussion:
mullvad-vpn build fails after jnix crate upgrade to v0.2.0 I tried this code: sudo pacman -Russnc mullvad-vpn sudo rm -rf /var/cache/mullvad-vpn/ sudo rm -rf /var/log/mullvad-vpn/ git clone cd mullvad-vpn makepkg -si I expected to see this happen: build completes without errors Instead, this happened: rustc panicks at 'assertion failed: data.isempty()', :
cc
ping icebreakers-cleanup-crew
Currently running
prints: searched nightlies: from nightly-2020-02-11 to nightly-2020-02-18 regressed nightly: nightly-2020-02-16 searched commits: from to regressed commit: source code: modify labels: -E-needs-bisection
modify labels: -E-needs-mcve
triage: P-high. Removing nomination.
I'm also getting this error. : Backtrace:
Change:
}; let mut deduped: SsoHashSet<_> = Default::default(); <del> let mut canonical = SelectionContext::with_query_mode(selcx.infcx(), TraitQueryMode::Canonical); </del> result.obligations.drain_filter(|projected_obligation| { if !deduped.insert(projected_obligation.clone()) { return true; } <del> // If any global obligations always apply, considering regions, then we don't // need to include them. The `is_global` check rules out inference variables, // so there's no need for the caller of `opt_normalize_projection_type` // to evaluate them. // Note that we do *not* discard obligations that evaluate to // `EvaluatedtoOkModuloRegions`. Evaluating these obligations // inside of a query (e.g. `evaluate_obligation`) can change // the result to `EvaluatedToOkModuloRegions`, while an // `EvaluatedToOk` obligation will never change the result. // See #85360 for more details projected_obligation.is_global(canonical.tcx()) && canonical .evaluate_root_obligation(projected_obligation) .map_or(false, |res| res.must_apply_considering_regions()) </del> <ins> false </ins> }); if use_cache {

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. --I tried this code (minimized from [this test] in my library): [this test]: I expected to see this happen: Compile without errors. Instead, this happened: Compiled with errors: Note that it says is not implemented for , but then lists it as an existing implementation. It most recently worked on: 1.55.0 : <!-- 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 --
modify labels: +regression-from-stable-to-stable
Bisects to . cc searched nightlies: from nightly-2021-07-01 to nightly-2021-10-01 regressed nightly: nightly-2021-09-03 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.0</summaryHost triple: x86_64-apple-darwin Reproduce with: </details
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-high
Any advancements on this issue? I currently can't upgrade to Rust 1.56 due to this exact problem
I might try my hand at diagnosing it, but someone with more context would definitely be faster at it.
Sorry for the delay in getting to this. I've opened with a fix.
I noticed that this regression was found in the 1.56 beta crater run: https://crater- Was it just overlooked at that time?
Seems kinda major to Yeah, this seems rather significant. It's right there in the results. https://crater-
Change:
} /// Return `a` > `b` lexicographically (Using partial order, `Ord`) <del> pub fn gt<A: Ord, T: Iterator<A>>(mut a: T, mut b: T) -> bool { </del> <ins> pub fn gt<A: Ord, T: Iterator<A>, S: Iterator<A>>(mut a: T, mut b: S) -> bool { </ins> loop { match (a.next(), b.next()) { (None, None) => return false,

Discussion:
They're currently very restricted as they only work with a single iterator type for both arguments, so, e.g. doesn't work. It should be easy to just add another parameter for the second argument.
Change:
<ins> error[E0070]: invalid left-hand side of assignment --> $DIR/failed-to-get-layout-for-type-error-ice-92979.rs:69:39 | LL |         &mut position[position.len()] = f32::from_be_bytes(demo(p)); |         ----------------------------- ^ |         | |         cannot assign to this expression | help: consider dereferencing here to assign to the mutably borrowed value | LL |         *&mut position[position.len()] = f32::from_be_bytes(demo(p)); |         + error: aborting due to 1 previous error For more information about this error, try `rustc --explain E0070`. </ins>

Discussion:
: Same in 1.52.0-nightly, same in 1.51.0. : <details<summary<strongBacktrace</strong</summary<p</p</detailsGood luck! <3
This happens on top of too much code for me to take the time to minimalize this issue, sorry. Though I'll try to file the fixing patch.
Wait! I made it! This issue revolves around L.31. Comment to see the ice go away. Interestingly, comment L.40 (or the whole impl L.37-45) to see ice go away as well. Commenting L.47-56 does not make ice go away. Commenting L.13-22 should raise another error (as L.31 is supposed to go there), but doesn't. Actually, the real fix is to replace L.31 with: Have fun!
Minimized with , then a bit by hand: <details<summaryDetails</summary<pIcemelter version: v0.2.0 label +S-bug-has-mcve </p</details
fixed by . we previously used to eagerly error but did not consider them as part of the cache key. So using a cache key from an evaluation with different can result in buggy behavior
Change:
//~^ WARN unused attribute #![path = "3800"] //~ WARN unused attribute #![automatically_derived] //~ WARN unused attribute <del> #![no_mangle] //~ WARN unused attribute </del> <ins> #![no_mangle] </ins> #![no_link] //~ WARN unused attribute // see issue-43106-gating-of-derive.rs #![should_panic] //~ WARN unused attribute

Discussion:
Steps to reproduce: 1) make an new crate, set crate type to 2) put a simple function in : 3) build with 4) copy the command line used from above step, and run it as-is example: As you can see, the first time in step 3) has no warnings, however, step 4) cause complains is unused, which isn't true. Step 4) can be replaced by: modify , so that it cause rebuild run again rustc 1.35.0-nightly ( 2019-04-16)
I have same error on today's nightly too
Same for me
I see the same warning text during a build for crate type “staticlib” using nightly 1.36.0 commit 2019-04-18
I will bisect this and then pass the baton to to fix this.
Bisection claims , (). cc
My guess is that should be a attribute? It was declared twice before and the variant got removed.
Also our scheme to track unused attributes does not work the incremental compilation, which is probably why it only happens with that.
cc
A fix is up. I this still nightly only or do we need to backport?
Seems to be nightly-only still
I get this with regular on a crate type with nightly
can you try with the latest nightly? This was only closed yesterday, so today's nightly should contain the fix.
My case () is no longer reproducible on 2019-05-21 nightly.
I no longer see the ~error~ warning with .
Yep it seems it's fixed. sorry I missed that it was merged yesterday. thanks!
Change:
<ins> // Regression test for <https://github.com/rust-lang/rust/issues/121986>. // Check that `tests_revision_unpaired_stdout_stderr` don't accidentally get confused by // paths containing periods. //@ check-pass fn main() {} </ins>

Discussion:
Running on my checkout with the current master commit fails with tons of errors. here's the last few screens of messages:
Is the check looking for in the full path? My rustc checkout is in a directory called (it's my 2nd of 3 checkouts), and I suspect tidy gets confused by that.
It does CC
That code should probably use .
Oops, I will try to fix this ASAP
Submitted a fix for this at .