jiebi/CodeConvo huggingface dataset:
Change:
<ins> //@ check-pass //! Tests that we do not regress rust-lang/rust#125811 #![feature(transmutability)] fn assert_transmutable<T>() where (): std::mem::BikeshedIntrinsicFrom<T> {} enum Uninhabited {} enum SingleInhabited { X, Y(Uninhabited) } enum SingleUninhabited { X(Uninhabited), Y(Uninhabited), } fn main() { assert_transmutable::<Uninhabited>(); assert_transmutable::<SingleInhabited>(); assert_transmutable::<SingleUninhabited>(); } </ins>

Discussion:
<!-- [31mICE[0m: Rustc '' 'thread 'rustc' panicked at 'assertion failed'', 'thread 'rustc' panicked at 'assertion failed'' 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: [tagforvariant] computing variant tag for enum [evaluateobligation] evaluating trait selection obligation --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
That is the transmutability check asking for the discriminant of an uninhabited variant. I'm not sure what that code is doing with this information, but probably it makes sense to just remove the assertion and treat uninhabited variants like niched variants -- writing their discriminant is a NOP, but then the validation we do will definitely fail as the uninhabited variant cannot actually be represented in-memory. Cc
claim
Change:
macro_rules! weak_lang_items { ($($name:ident, $item:ident, $sym:ident;)*) => ( <del> pub static WEAK_ITEMS_REFS: SyncLazy<FxHashMap<Symbol, LangItem>> = SyncLazy::new(|| { let mut map = FxHashMap::default(); </del> <ins> pub static WEAK_ITEMS_REFS: SyncLazy<StableMap<Symbol, LangItem>> = SyncLazy::new(|| { let mut map = StableMap::default(); </ins> $(map.insert(sym::$name, LangItem::$item);)* map });

Discussion:
Since a few weeks we are getting an unrelated failure in a ui test where the order of two diagnostics changes. It is not entirely random, since it only changes if there are compiler changes, but we should still find and fix it <details<summary<iClick to see the possible cause of the failure (guessed by this bot)</i</summary</detailsOriginally posted by in
The first time I've seen it was in The second time in
This happened to me in too.
This could be happening because , declared here: is being traversed here: and thus we get non-determinism in the output... Two obvious solutions: change to a sorted map structure in the declaration, or normalize the order before traversing in the loop in
cc
Change:
LL | /// Link to [field@X::y] |              ~~~~~~ <del> error: incompatible link kind for `S::A` </del> <ins> error: unresolved link to `S::A` </ins> --> $DIR/disambiguator-mismatch.rs:93:14 | LL | /// Link to [field@S::A] <del> |              ^^^^^^^^^^ this link resolved to a unit variant, which is not a field </del> <ins> |              ^^^^^^^^^^ this link resolves to the variant `A`, which is not in the value namespace </ins> | <del> help: to link to the unit variant, prefix with `variant@` </del> <ins> help: to link to the variant, prefix with `variant@` </ins> | LL | /// Link to [variant@S::A] |              ~~~~~~~~

Discussion:
I'm probably planning on working on this, I found it while I was working on . The issue is that rustdoc looks up in the value namespace, which returns a Ctor, not a Variant. Turns out giving doc comments unimpeded access to the rustc resolver might not be a perfect idea This seems slightly (but not very) tricky to fix, mainly an ironing out of semantics - do we pretend that in the value namespace doesn't exist? Or do we let you reference it, but taking care not to say that there's a conflict between (the constructor) and (the variant) and that you have to disambiguate it? <!-- 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. --(current master): <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
i'm not sure why we would want this - you can't document the constructor separately from the variant, so i would expect rustdoc to hide it from intra-doc links
(or alternatively we could make an alias for )
First of all, I can reproduce this problem with a unit-like struct. Second of all, This is an observable fact. To see it, use glob exports. Most crates probably won't do this... but most crates probably won't need disambiguators at all. These things are in the value namespace, and that's a fact that can be observed in the surface language, so we probably shouldn't pretend otherwise.
Change:
use crate::parse::token::{self, Nonterminal, DelimToken}; use crate::parse::parser::{Parser, TokenType, PathStyle}; use crate::tokenstream::{TokenStream, TokenTree}; <ins> use crate::source_map::Span; </ins> use log::debug; use smallvec::smallvec;

Discussion:
Given the following we currently emit We should emit at least the following We might also want to provide suggestions when it makes sense (like turning the attr into an outer attr).
Hey , I tried to solve this with a little help of on a rust meetup. I wasn't able to run because of the following message. But I started to add some code you can read here: is this going into the right direction?
thank you for taking a look at this! You should be able to run the tests with . Use to update the relevant files. The code you've written would generate the following output: Instead, we'd want this to be a single error. What you'd want to do is 1) get the span for the prior attribute from 2) expand to also hold an extra field and 3) change the following to be This lets you point at the prior span in the same error. The second part of this ticket is changing the linked code to no longer use , but rather synthesize a new span from the first 's span to the closing . You can use to do so. Finally, we change the above to be something like
Are you still working on this? I'm thinking of giving it a try.
Go on! I don’t have so much time atm so just go there step by step while learning rust. If you want so solve it - awesome
Change:
// Find all the requirements that come from a local `impl` block. let mut skip_list: FxHashSet<_> = Default::default(); let mut spanned_predicates = FxHashMap::default(); <del> for (p, parent_p, impl_def_id, cause) in unsatisfied_predicates .iter() .filter_map(|(p, parent, c)| c.as_ref().map(|c| (p, parent, c))) .filter_map(|(p, parent, c)| match c.code() { ObligationCauseCode::ImplDerivedObligation(data) if matches!(p.kind().skip_binder(), ty::PredicateKind::Clause(_)) => { Some((p, parent, data.impl_or_alias_def_id, data)) </del> <ins> for (p, parent_p, cause) in unsatisfied_predicates { // Extract the predicate span and parent def id of the cause, // if we have one. let (item_def_id, cause_span) = match cause.as_ref().map(|cause| cause.code()) { Some(ObligationCauseCode::ImplDerivedObligation(data)) => { (data.impl_or_alias_def_id, data.span) </ins> } <del> _ => None, }) { match self.tcx.hir().get_if_local(impl_def_id) { </del> <ins> Some( ObligationCauseCode::ExprBindingObligation(def_id, span, _, _) | ObligationCauseCode::BindingObligation(def_id, span), ) => (*def_id, *span), _ => continue, }; // Don't point out the span of `WellFormed` predicates. if !matches!(p.kind().skip_binder(), ty::PredicateKind::Clause(_)) { continue; }; match self.tcx.hir().get_if_local(item_def_id) { </ins> // Unmet obligation comes from a `derive` macro, point at it once to // avoid multiple span labels pointing at the same place. Some(Node::Item(hir::Item {

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 via  and some manual item deletion: I can take a quick look into this one I guess. claim
Change:
}; // Arguments types <del> for &argument_type in inputs { signature.push(type_metadata(cx, argument_type, syntax_pos::DUMMY_SP)); </del> <ins> if cx.sess().target.target.options.is_like_msvc { // FIXME(#42800): // There is a bug in MSDIA that leads to a crash when it encounters // a fixed-size array of `u8` or something zero-sized in a // function-type (see #40477). // As a workaround, we replace those fixed-size arrays with a // pointer-type. So a function `fn foo(a: u8, b: [u8; 4])` would // appear as `fn foo(a: u8, b: *const u8)` in debuginfo, // and a function `fn bar(x: [(); 7])` as `fn bar(x: *const ())`. // This transformed type is wrong, but these function types are // already inaccurate due to ABI adjustments (see #42800). signature.extend(inputs.iter().map(|&t| { let t = match t.sty { ty::TyArray(ct, _) if (ct == cx.tcx().types.u8) || (cx.layout_of(ct).size(cx).bytes() == 0) => { cx.tcx().mk_imm_ptr(ct) } _ => t }; type_metadata(cx, t, syntax_pos::DUMMY_SP) })); } else { signature.extend(inputs.iter().map(|t| { type_metadata(cx, t, syntax_pos::DUMMY_SP) })); </ins> } if sig.abi == Abi::RustCall && !sig.inputs().is_empty() {

Discussion:
Backstory in (comment 16 has dmajor's analysis). In summary: when building on windows, rustc can generate symbol names into the .pdb file that microsoft's DIA library doesn't like. In particular, it can result in calls to to crash with a divide-by-zero. This is a bug in the DIA library which I reported to a friend at Microsoft and which has been fixed. However, older versions of the DIA library still have this problem, so rustc should probably be updated to not generate such symbols. This bug results in the mozilla-central crashing which in turn generates a bad .sym file which causes windows debug tests to blow up. For now I have a workaround patch ready to land that catches the div-by-zero in suggested that if there is some runtime workaround (e.g. setting rustflags or something) that can avoid this problem, we should do that instead - so if there is anything I can try along those lines, please let me know. /cc
Thanks for the report. It looks like we are doing this on purpose for arrays we don't know the size of. I'll try to find out if we can do something else here.
So the real culprit here is the that is assigned to every function. It seems that MSDIA has a problem with fixed-size arrays of or anything zero-sized. Fixed-size arrays of any other type (including , interestingly) are handled without crashes. Here's a table of various types and sizes I've tested: My proposed fix/workaround is to adapt parameter types within , so that fixed-size arrays are replaced with pointers when compiling against MSVC. is anyway, so things don't get worse at least.
Change:
<ins> warning: trait objects without an explicit `dyn` are deprecated --> $DIR/dynless-turbofish-e0191-issue-91997.rs:4:13 | LL |     let _ = MyIterator::next; |             ^^^^^^^^^^ | = warning: this is accepted in the current edition (Rust 2015) but is a hard error in Rust 2021! = note: for more information, see <https://doc.rust-lang.org/nightly/edition-guide/rust-2021/warnings-promoted-to-error.html> = note: `#[warn(bare_trait_objects)]` on by default help: if this is an object-safe trait, use `dyn` | LL |     let _ = <dyn MyIterator>::next; |             ++++           + error[E0191]: the value of the associated type `Item` in `Iterator` must be specified --> $DIR/dynless-turbofish-e0191-issue-91997.rs:4:13 | LL |     let _ = MyIterator::next; |             ^^^^^^^^^^ help: specify the associated type: `MyIterator::<Item = Type>` error: aborting due to 1 previous error; 1 warning emitted For more information about this error, try `rustc --explain E0191`. </ins>

Discussion:
Given the following code: %20%7B%0A%20%20%20%20let%20%20%3D%20MyIterator%3A%3Anext%3B%0A%20%20%20%20%2F%2Flet%20%20%3D%20MyIterator%3CItem%3D()%3E%3A%3Anext%3B%0A%7D) The current output is: But when when I write , it gets interpreted as comparison expressions like and it fails to compile with a lot of "cannot find value in this scope" and "cannot find crate in the list of imported crates". The suggestion is confusing because it is unclear how to apply it. The error goes away if you use directly: produces the error one would expect: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I think it gets evaluated as an expression because you are missing a . If you add them, then you get a new error message ():
I see, let me rephrase the issue: The suggestion is "help: specify the associated type: " where "help: specify the associated type: " with a double colon would be correct.
Triage: Suggestion is correct for code using (which all code written in Rust =2021 uses). For code written without in Rust <2021: No change. As mentioned, the suggestion should use an expression-style path (i.e., one with turbofishes).
claim
Working on tests before creating a PR. Multiple tests exist already that have an odd hardcoded expectation for error output, so I'll be double checking those make sense with these changes, and adding a few tests of my own. Otherwise, this really does seem like it was a simple two character fix, unless I missed something somewhere.
Yeah, it's a pretty easy one. Adding before is always correct — not only in expression contexts but also in type contexts since turbofish is also possible in type positions (e.g., ) — albeit redundant. Omitting before in type contexts would be a possible "optimization". However, it really isn't worth doing here.

Consider the following code which is ill-formed even after specifying the assoc ty. () would only be well-formed if we defined an inherent associated type () on which doesn't work yet anyway () and is pretty niche) or once we support arbitrary shorthand projections ().
Change:
}; } <del> arith_red!(simd_reduce_add_ordered: vector_reduce_add, vector_reduce_fadd, true, add, 0.0); </del> <ins> arith_red!(simd_reduce_add_ordered: vector_reduce_add, vector_reduce_fadd, true, add, -0.0); </ins> arith_red!(simd_reduce_mul_ordered: vector_reduce_mul, vector_reduce_fmul, true, mul, 1.0); arith_red!( simd_reduce_add_unordered: vector_reduce_add, vector_reduce_fadd_reassoc, false, add, <del> 0.0 </del> <ins> -0.0 </ins> ); arith_red!( simd_reduce_mul_unordered: vector_reduce_mul,

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. --Code generation for generates an extra floating-point add that adds +0.0 to the result: The problem seems to be because the compiler uses +0.0 as the starting value of instead of -0.0. Comparing LLVM code generation for the two cases, we get the more efficient version when using -0.0: This generates the following assembly for AArch64: To me, this behaviour seems to be caused by using +0.0 instead of -0.0 here in the compiler:
This sounds somewhat related to
Yeah, this is fixed by
wait, not in the... sec, will PR.
Change:
// Check if the method call actually calls the libcore // `IntoIterator::into_iter`. <del> let def_id = cx.typeck_results().type_dependent_def_id(expr.hir_id).unwrap(); match cx.tcx.trait_of_item(def_id) { Some(trait_id) if cx.tcx.is_diagnostic_item(sym::IntoIterator, trait_id) => {} _ => return, }; </del> <ins> let trait_id = cx .typeck_results() .type_dependent_def_id(expr.hir_id) .and_then(|did| cx.tcx.trait_of_item(did)); if trait_id.is_none() || !cx.tcx.is_diagnostic_item(sym::IntoIterator, trait_id.unwrap()) { return; } </ins> // As this is a method call expression, we have at least one argument. let receiver_ty = cx.typeck_results().expr_ty(receiver_arg);

Discussion:
<!-- [31mICE[0m: Rustc '--crate-type=lib -ooutputfile -Zdump-mir-dir=dir' 'thread 'rustc' panicked at 'called on a value'', 'thread 'rustc' panicked at 'called on a value'' 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: [lintmod] linting top-level module [analysis] running analysis passes on this crate --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
cc
claim
The ICE occurs due to the on this line: The underlying reason is that typeck result is tainted due to the bad arg type in the user's code and therefore returns .
Change:
let mut href = String::new(); clean_srcpath(&self.scx.src_root, &p, false, |component| { cur.push(component); <del> fs::create_dir_all(&cur).unwrap(); </del> root_path.push_str("../"); href.push_str(&component.to_string_lossy()); href.push('/'); }); <ins> fs::create_dir_all(&cur)?; </ins> let mut fname = p.file_name() .expect("source has no filename") .to_os_string();

Discussion:
After a simple , I tried to generate the crate documentation. I really don't know why I get this error. The problem seems to be here but what's wrong? ^^' The source is on glitch: !/nom- Feel free to ping me if you need to ask me more!
Is this a fluke or is your drive actually full? Is it a regular drive or a network share?
Oops! I didn't see the error message. My fork is stored on Glitch, it's a virtual drive I guess. I must have reached the storage limit authorized by Glitch. edit: ahah, that's it! !
That's not very nice as output... I'll write something a bit better.
As you requested here's the backtrace:
This ICE was changed into a proper error message by . This issue can be closed as a duplicate of .
Ok, thanks! I'll close it!
Change:
use rustc_ast::ast::*; use rustc_ast::token::{self, Token}; use rustc_ast::visit::{self, FnKind}; <ins> use rustc_ast::walk_list; </ins> use rustc_expand::expand::AstFragment; use rustc_hir::def_id::LocalDefId; use rustc_hir::definitions::*;

Discussion:
I'm seeing an internal compiler error on the following input (found by ):
Report from cargo-bisect-rustc: searched nightlies: from nightly-2020-03-09 to nightly-2020-04-03 regressed nightly: nightly-2020-03-16 searched commits: from to regressed commit:
Maybe due to cc
Fixed by
Change:
/// compilation on error, merely emits a non-fatal error and returns `None`. pub fn expr_to_spanned_string<'a>( cx: &'a mut ExtCtxt<'_>, <del> mut expr: P<ast::Expr>, </del> <ins> expr: P<ast::Expr>, </ins> err_msg: &str, ) -> Result<(Symbol, ast::StrStyle, Span), Option<DiagnosticBuilder<'a>>> { <del> // Update `expr.span`'s ctxt now in case expr is an `include!` macro invocation. expr.span = expr.span.apply_mark(cx.current_expansion.id); </del> // Perform eager expansion on the expression. // We want to be able to handle e.g., `concat!("foo", "bar")`. let expr = cx.expander().fully_expand_fragment(AstFragment::Expr(expr)).make_expr();

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:
<ins> #![feature(never_type, specialization)] #![allow(incomplete_features)] use std::iter::{self, Empty}; trait Trait { type Out: Iterator<Item = u32>; fn f(&self) -> Option<Self::Out>; } impl<T> Trait for T { default type Out = !; //~ ERROR: `!` is not an iterator default fn f(&self) -> Option<Self::Out> { None } } struct X; impl Trait for X { type Out = Empty<u32>; fn f(&self) -> Option<Self::Out> { Some(iter::empty()) } } fn f<T: Trait>(a: T) { if let Some(iter) = a.f() { println!("Some"); for x in iter { println!("x = {}", x); } } } pub fn main() { f(10); } </ins>

Discussion:
This snippet is found in . Reduced: :
Nitpick: There's no need to put the two into different functions, you can put them both in .
Like , when using an anonymous binding (), the above code :
No longer ICEs since

With specialization, it is possible to define a default associated type that does not fulfill its trait bounds. Here is a minimal example, that surely should not compile, but does with rustc 1.35.0-nightly: Unsurprisingly, adding the main function causes an ICE. Error message and backtrace (compiled at the playground):
Triage: the latest nightly rejects the code, marking as E-needs-test.

This code generates an ICE with this message. Replacing by makes the code to compile and run fine, which is strange because ! does not implements . By removing the specialization the compiler refuses to compile the code with the error:
The ICE has been fixed in the latest nightly, marked as E-needstest
Thanks Indeed, the example compiles fine in nightly ( 2019-11-12), however, replacing the main function by these two generates the same ICE.
ah, thanks for the update! I confirmed it ()
Triage: the ICE doesn't occur anymore with the latest nightly, marking as E-needs-test.

I was attempting to figure out the feature landscape for , and I found this ICE when playing with it and specialization:
The given code builds fine on current nightly.
This is still an ICE on current nightly when not .
This code compiles without a problem whether I do or using current nightly: . Tested on Windows 10 x64 and Ubuntu x64.
Really? But on the playground, the ICE still appears. Can you check the above link?
Yes, I get an ICE in the playground when I just build.
It does ICE when using instead of .
You need or , not . It seems like a still ICE to me.
Triage: the latest nightly rejects the code without an ICE. Marking as E-needs-test.