jiebi/CodeConvo huggingface dataset:
Change:
fn rpaths_to_flags(rpaths: &[String]) -> Vec<String> { let mut ret = Vec::new(); for rpath in rpaths { <del> ret.push(format!("-Wl,-rpath,{}", &(*rpath))); </del> <ins> if rpath.contains(',') { ret.push("-Wl,-rpath".into()); ret.push("-Xlinker".into()); ret.push(rpath.clone()); } else { ret.push(format!("-Wl,-rpath,{}", &(*rpath))); } </ins> } return ret; }

Discussion:
generates linker options of the form . This fails if contains commas, because separates options on commas, so the linker ends up getting a bad path and spurious extra parameters. The solution is to use which passes the next option through literally, so the full rpath can be specified with . The form is fairly verbose, and only needed when there are commas. (This comes up when building with , because it generates paths of the form where "flavors" are things like "shared", "static", "pic", etc.)
Fixed in 1.16
Change:
ConstVal::Value(miri) => const_val_field( self.tcx, self.param_env, instance, variant_opt, field, miri, cv.ty, <del> ).unwrap(), </del> <ins> ).expect("field access failed"), </ins> _ => bug!("{:#?} is not a valid adt", cv), }; self.const_to_pat(instance, val, id, span)

Discussion:
I recently updated my nightly toolchain for rust, and compiled a project I was working on. Previously I was on the version, and updated to the version. I encountered a compiler error when dealing with statements and Associated Constants, centered around alignment issues of the associated constant. After some testing, I managed to create a simple example with the code below: : : I've also tested and encountered this error on the following versions: nightly-2018-04-27-x8664-pc-windows-msvc nightly-2018-04-28-x8664-pc-windows-msvc nightly-2018-04-29-x8664-pc-windows-msvc nightly-2018-04-30-x8664-pc-windows-msvc
Sounds like some alignment check is getting the alignment from the wrong side of an assignment. I hope it wasn't introduced in a beta backported bugfix, we need to check that.
Ok, It's just in nightly, not in beta! I'll try to bisect
Change:
<ins> error[E0659]: `V` is ambiguous --> $DIR/issue-105069.rs:2:5 | LL | use V; |     ^ ambiguous name | = note: ambiguous because of multiple potential import sources note: `V` could refer to the variant imported here --> $DIR/issue-105069.rs:1:5 | LL | use self::A::*; |     ^^^^^^^^^^ note: `V` could also refer to the variant imported here --> $DIR/issue-105069.rs:3:5 | LL | use self::B::*; |     ^^^^^^^^^^ error: aborting due to previous error For more information about this error, try `rustc --explain E0659`. </ins>

Discussion:
thread 'rustc' panicked at ': inconsistent resolution for an import', <details<summaryBacktrace</summary</detailsRegression in nightly-2018-12-30 <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Same error message as , but this one is self-contained and might be a separate bug.
claim
how about make this to an error with diagonostic? Seems we don't have a chance to insert , because the is before the later . If we change code to this: It will be:
Could we register an exactly in the place we ICE?
Yes, this is also a solution, and then we can report error in the same function .
Change:
///   to be the same size as the pointer was allocated with. (Because similar to ///   alignment, [`dealloc`] must be called with the same layout `size`.) /// * `length` needs to be less than or equal to `capacity`. <ins> /// * The first `length` values must be properly initialized values of type `T`. /// * `capacity` needs to be the capacity that the pointer was allocated with. /// * The allocated size in bytes must be no larger than `isize::MAX`. ///   See the safety documentation of [`pointer::offset`]. /// /// These requirements are always upheld by any `ptr` that has been allocated /// via `Vec<T>`. Other allocation sources are allowed if the invariants are /// upheld. </ins> /// /// Violating these may cause problems like corrupting the allocator's /// internal data structures. For example it is normally **not** safe

Discussion:
has this to say about a better way to turn a into a : A strict reading, if I understand correctly, says that these two statements are contradictory. The documentation says that it is safe to create a and then use to create a out of its pointer. But the documentation says that, when creating a , must have previously been allocated via precisely and only , not for some other type —not even if happens to be transmutable from , not even if and are ABI-compatible, not only if is a wrapper around , but only itself. I suspect it was meant to say it must have previously been allocated by , not ; after all, if it could only have been allocated by in the first place, the next bullet point would be redundant (because obviously has the same alignment as ).
label A-docs
Relevant: looks like it will fix this if approved, by explicitly allowing allocation using something other than Vec<T(which can be a Vec<Uor even manual allocation)
Hm, that PR does remove the text I pointed out, but it also adds this text: Isn’t that equally problematic (albeit a slightly different but related problem, since it’s talking about the contents of the memory rather than its ), since it is actually fine for them to be properly initialized values of some other type that is suitably bytewise-compatible (for a proper choice of wording for “suitably compatible”) with but is not actually itself? Or does “properly initialized values of type ” actually also cover that (i.e. does it mean “bytes containing valid representations of ” and not “memory regions which have been constructed as s”?).
Rust doesn't have typed memory, types only have effect on accesses, so if some memory can be interpreted as some type T and it's valid at that type, it's a properly initialized value of type T. Nothing remembers the "original type" of some data. Just like how you can cast a to a and use them interchangeably. This is a safe operation if you use , too.
Change:
container.map(|container| crate::clean::ContainerTy::Regular { ty: container, args, <ins> has_self, </ins> arg: index, }), ))),

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. --I found out about the ICE when my crate could not have its documentation online on (). I managed to narrow it down to the code below. All of the code here builds fine (, ), but on the latest stable and nightly it fails when doing . Originally, came from a separate crate, . To my surprise, using the dependency instead of replicating the symbols to this crate results in a more informative top-level error message of the ICE. With we can instead do: The full project can also be found in . Reproduced on more than one toolchain and platform, among which: Without the dependency: with the dependency : <!-- 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 --
this went build -ice in Regression in
is , cc author:
claim
Minimized: label S-has-mcve A-cross-crate-reexports
WG-prioritization assigning priority (). label -I-prioritize +P-critical
Keeping it open until the fix is backported to beta.
The fix has been backported to beta () and to stable (). Closing.
Change:
/// Names the thread-to-be. Currently the name is used for identification /// only in panic messages. /// <ins> /// For more information about named threads, see /// [this module-level documentation][naming-threads]. /// </ins> /// # Examples /// /// ```

Discussion:
One can specify the stack size of a thread via . It looks like looks at the env var and attempts to parse it into an integer. If it's not specified or can't parse, it falls back to 2MB. Should we update the thread documentation to mention what the default stack size is and mention that environment variable?
Relevant discussion on IRC
Don't forget that the stack size of the main thread is not determined by Rust.
Opened a PR:
Change:
<ins> // force-host // no-prefer-dynamic #![crate_type = "proc-macro"] #![feature(proc_macro_span, proc_macro_hygiene, proc_macro_quote)] extern crate proc_macro; use proc_macro::{quote, Span, TokenStream}; fn assert_same_span(a: Span, b: Span) { assert_eq!(a.start(), b.start()); assert_eq!(a.end(), b.end()); } // This macro generates a macro with the same macro definition as `manual_foo` in // `same-sequence-span.rs` but with the same span for all sequences. #[proc_macro] pub fn make_foo(_: TokenStream) -> TokenStream { let result = quote! { macro_rules! generated_foo { (1 $$x:expr $$($$y:tt,)* $$(= $$z:tt)*) => {}; } }; // Check that all spans are equal. let mut span = None; for tt in result.clone() { match span { None => span = Some(tt.span()), Some(span) => assert_same_span(tt.span(), span), } } result } </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?
Change:
impl<'a> ParserAnyMacro<'a> { crate fn make(mut self: Box<ParserAnyMacro<'a>>, kind: AstFragmentKind) -> AstFragment { let ParserAnyMacro { site_span, macro_ident, ref mut parser, arm_span } = *self; <ins> let snapshot = &mut parser.clone(); </ins> let fragment = match parse_ast_fragment(parser, kind) { Ok(f) => f, Err(err) => { <del> emit_frag_parse_err(err, parser, site_span, macro_ident, arm_span, kind); </del> <ins> emit_frag_parse_err(err, parser, snapshot, site_span, macro_ident, arm_span, kind); </ins> return kind.dummy(site_span); } };

Discussion:
This is a regression from stable to beta and nightly. This code is wrong (missing semicolons): Stable prints: Beta and nightly both print: Notice that not only is all the useful information gone, but the compiler aborts after the first error instead of finding the rest. It does not matter whether is on or off. cc
cc me
So this fell through the cracks, and was a stable to nightly/beta regression. It still is a regression, in a way, but only of diagnostics. Could you take a look?
Nominating for prioritization.
So this part of the (previous) stable message: feels like a bug to me anyhow. This part: is sort of good. It'd be nice to preserve a backtrace, at least. And ideally we'd suggest adding a .
Given how much time has past, we're going to call this P-medium for now. However, will try to write up some mentoring instructions (or maybe fix it). He has a plan. =) triage: P-medium
I think the best path forward here is to try parsing an expression macro expansion as a statement before emitting an error. If the macro expansion parses as a statement successfully, we can emit a more helpful error suggesting that the user add a semicolon to the macro invocation.
I'm interested in this but I need informations to understand what to do :)
Current output:
Diagnostics meeting triage: lowering priority as the current error is pretty good, even if not ideal yet.
Current output: (Notice that we recover -- it's not a fatal error now.)
Change:
/// This version of parse arg doesn't necessarily require /// identifier names. <del> fn parse_arg_general(&mut self, require_name: bool) -> PResult<'a, Arg> { </del> <ins> fn parse_arg_general(&mut self, require_name: bool, is_trait_item: bool) -> PResult<'a, Arg> { </ins> maybe_whole!(self, NtArg, |x| x); if let Ok(Some(_)) = self.parse_self_arg() {

Discussion:
This code works correctly on nightly and stable but not on 2018 edition, where it returns the error Changing it to solves it. Is this an intended change? I couldn't find anything about it in the edition guide.
Yes, this was done in
So apparently it was part of . In that case we should at least fix the error message, since it doesn't explain the source of the error at all.
Change:
<ins> // edition:2018 // Regression test for #95307. // The ICE occurred on all the editions, specifying edition:2018 to reduce diagnostics. pub trait C { async fn new() -> [u8; _]; //~^ ERROR: functions in traits cannot be declared `async` //~| ERROR: using `_` for array lengths is unstable //~| ERROR: in expressions, `_` can only be used on the left-hand side of an assignment } fn main() {} </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<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
minimized: claim
I am not sure if I am able to solve this ICE -- it has to do with the way that in traits are treated as async fn in some places, but not lowered as async fn in other places. That means there's a DefId that is not associated with a HIR Id, but I can't exactly track it down. release-assignment
I'm working on a return position impl traits change that is going to make it easier to lowering return position impl traits in traits and that would make async fns in traits easy. All this is in my todo list. I should be able to accomplish some of these things soon. not sure if you were going to work on this, but we can talk about this in Zulip if you want.
Triage: The ICE doesn't occur on the latest nightly, bisecting shows fixed it but I'm not 100% sure what PR did, perhaps ? Marking .
Change:
<ins> error[E0594]: cannot assign to immutable thread-local static item --> $DIR/thread-local-mutation.rs:11:5 | LL |     S = "after"; //~ ERROR cannot assign to immutable |     ^^^^^^^^^^^ error: aborting due to previous error For more information about this error, try `rustc --explain E0594`. </ins>

Discussion:
On rustc 1.31.0-nightly ( 2018-10-07) and x8664-unknown-linux-gnu, we see the following surprising behavior: In release mode it seems the write has not happened in the place that it should. Mentioning threadlocal tracking issue: .
Ah, apparently this is missing a . With the behavior is correct. We need to make sure mutating a thread_local static that does not have does not compile.
cc Did fix this by any chance?
It looks like this is fixed on nightly; I'm guessing is the reason. We probably should add some regression tests for the cases listed here.
Change:
use rustc_hir::intravisit::{walk_generics, Visitor as _}; use rustc_hir::lang_items::LangItem; use rustc_hir::{Constness, GenericArg, GenericArgs}; <del> use rustc_middle::ty::subst::{self, InternalSubsts, Subst, SubstsRef}; </del> <ins> use rustc_middle::ty::subst::{self, GenericArgKind, InternalSubsts, Subst, SubstsRef}; </ins> use rustc_middle::ty::GenericParamDefKind; use rustc_middle::ty::{self, Const, DefIdTree, Ty, TyCtxt, TypeFoldable}; use rustc_session::lint::builtin::AMBIGUOUS_ASSOCIATED_ITEMS;

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
Change:
pred.remap_constness(tcx, &mut param_env); if self.can_use_global_caches(param_env) { <del> if let Some(res) = tcx.selection_cache.get(&param_env.and(pred), tcx) { </del> <ins> if let Some(res) = tcx.selection_cache.get(&(param_env, pred), tcx) { </ins> return Some(res); } } <del> self.infcx.selection_cache.get(&param_env.and(pred), tcx) </del> <ins> self.infcx.selection_cache.get(&(param_env, pred), tcx) </ins> } /// Determines whether can we safely cache the result

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 <!-- 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. --: This crashes nightly, beta and stable <!-- 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 --
Looks like this is happens during codegen which is why this didn't show up in the test (note the ´check-pass`) ...?
Hmm... this should be normalized somewhere above codegen I think? Curious to investigate though. claim
I suspect that this is caused by a bug in how we handle higher-ranked region variables (possibly during trait selection caching).
Change:
use rustc_data_structures::fx::{FxHashMap, FxHashSet, FxIndexMap}; use rustc_errors::{Applicability, DiagnosticArgValue, DiagnosticId, IntoDiagnosticArg}; use rustc_hir::def::Namespace::{self, *}; <del> use rustc_hir::def::{self, CtorKind, DefKind, LifetimeRes, PartialRes, PerNS}; </del> <ins> use rustc_hir::def::{self, CtorKind, DefKind, LifetimeRes, NonMacroAttrKind, PartialRes, PerNS}; </ins> use rustc_hir::def_id::{DefId, LocalDefId, CRATE_DEF_ID, LOCAL_CRATE}; use rustc_hir::{BindingAnnotation, PrimTy, TraitCandidate}; use rustc_middle::middle::resolve_bound_vars::Set1;

Discussion:
Using cargo 1.71.0-nightly ( 2023-05-02) or cargo 1.69.0 ( 2023-04-12), I get a crash when trying to generate documentation from this excerpt of the Matrix Rust SDK: <details<summary<strongBacktrace</strong</summary</details
Change:
|                                                        ^^ | = note: lifetime arguments must be provided before type arguments <ins> = help: reorder the arguments: lifetimes, then types: `<'a, 'b, 'c, T, U, V>` </ins> error[E0747]: lifetime provided when a type was expected --> $DIR/suggest-move-types.rs:82:56

Discussion:
The current diagnostics are a little ad hoc and rely on counting the number of mismatches (e.g. they will only produce an error for the first mismatch). It would be nice to produce diagnostics like: cc <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
This is follow up work for
Please give more context on this. I am not sure the error message of which test should be improved.
This is more of the kind of issue opened to avoid forgetting about finishing some work, sorry for the confusion. That is, this is leaving a TODO to themselves about improving the diagnostics from .
Ok. I see. Thanks for the explanation.
That said, if is too busy to work on this, you could talk to them on Discord or Zulip to see what their plans were, and maybe turn this into a mentored issue.
The idea is essentially this. We currently emit errors telling the user that the generic arguments they provide are in the wrong order: However, what we'd like to do is suggest reordering the parameters, and let rustfix automatically apply the suggestion. I don't have the bandwidth to work on this at the moment, or any time soon, so if anyone is interested in tackling it, I'll be happy to mentor the issue.
would you mind if I take this up?
you're very welcome to! Let me know if you need any guidance in tackling this issue!
claim
Change:
usize, (), u32, <ins> u64, </ins> bool, std::string::String, crate::metadata::ModChild,

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. --: I see similar behavior in stable : The example always succeeds to compile the first time, but uses a large amount of time and memory. : Upon incremental re-compilation, I almost always see one of the following errors. I saw other open issues with a similar error message as the 1.46.0 output below, but in this one the error is affected by the value the array was filled with. : Running sometimes yields a different yet similar error: On 1.46.0: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<pOn 1.46.0: </p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
do you know if this is still a problem for you? claim
On 1.66.0, I still get an error upon incremental recompilation with the same code: <details<summary<strongBacktrace</strong</summary</details
Oh wow I didn't know anyone actually hit this so long ago! I turned this into a much nicer panic a few months ago:
Change:
source_map: Option<Lrc<SourceMapperDyn>>, /// If true, hides the longer explanation text short_message: bool, <del> /// If true, will normalize line numbers with LL to prevent noise in UI test diffs. </del> <ins> /// If true, will normalize line numbers with `LL` to prevent noise in UI test diffs. </ins> ui_testing: bool, }

Discussion:
Part of To support lines in the first column of UI test output, we have to make use of the flag and update the library. Relevant : The relevant PR in the annotate-snippet library and a new version needs to be released. Once that's done, we have to pass as a second argument to . <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
modify labels: A-diagnostics E-help-wanted
claim
Change:
) .optflag("", "force-rerun", "rerun tests even if the inputs are unchanged") .optflag("", "only-modified", "only run tests that result been modified") <ins> .optflag("", "nocapture", "") </ins> .optflag("h", "help", "show this message") .reqopt("", "channel", "current Rust channel", "CHANNEL") .optopt("", "edition", "default Rust edition", "EDITION");

Discussion:
passes fails On recent master (commit ), with to avoid building LLVM: Extra spin/Side note: Contrary to the above, with , both and pass well: and . All the same when invoking with instead of . Also discussed at https://rust- <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I think is not actually passing through to libtest, it's just acting as a filter on the tests (like would). looks like today the only way to configure this is through an env variable: changing that to accept seems useful
claim
Wow. Thank you.