jiebi/CodeConvo huggingface dataset:
Change:
#![feature(nonzero_ops)] #![feature(let_chains)] #![feature(lint_reasons)] <del> #![cfg_attr(not(bootstrap), feature(trait_upcasting))] </del> <ins> #![feature(trait_upcasting)] </ins> // Configure clippy and other lints #![allow( clippy::collapsible_else_if,

Discussion:
hello everyone, I got this error when I bootstrap the current rust-beta branch: There was a lot of pushing and reverting changesets relevant to the c literals stabilization, I tried to get an overview of what backport might be missing here, but I failed and am at a loss. I am on linux x86_64, with musl as my libc, I doubt the later is causing the issues.
What are you using as your bootstrap compiler? We only support using the previous release.
I think I understand what is going on. If you try to bootstrap 1.77 from 1.76, it will fail. We were intending to have c-string literals stabilized in 1.76, but that got reverted. However, the revert did not include the appropriate parts of I can probably put something together to fix it.
Posted with a fix.
Change:
<del> error[E0552]: incorrect `repr(packed)` attribute format: `packed` takes exactly one parenthesized argument, or no parentheses at all --> $DIR/issue-83921-ice.rs:6:8 | LL | #[repr(packed())] |        ^^^^^^^^ error[E0589]: invalid `repr(align)` attribute: `align` needs an argument --> $DIR/issue-83921-ice.rs:10:8 | LL | #[repr(align)] |        ^^^^^ help: supply an argument here: `align(...)` error[E0693]: incorrect `repr(align)` attribute format: `align` takes exactly one argument in parentheses --> $DIR/issue-83921-ice.rs:14:8 | LL | #[repr(align(2, 4))] |        ^^^^^^^^^^^ error[E0693]: incorrect `repr(align)` attribute format: `align` takes exactly one argument in parentheses --> $DIR/issue-83921-ice.rs:18:8 | LL | #[repr(align())] |        ^^^^^^^ error[E0552]: invalid representation hint: `i8` does not take a parenthesized argument list --> $DIR/issue-83921-ice.rs:22:8 | LL | #[repr(i8())] |        ^^^^ error[E0552]: invalid representation hint: `u32` does not take a parenthesized argument list --> $DIR/issue-83921-ice.rs:26:8 | LL | #[repr(u32(42))] |        ^^^^^^^ error[E0552]: invalid representation hint: `i64` does not take a value --> $DIR/issue-83921-ice.rs:30:8 | LL | #[repr(i64 = 2)] |        ^^^^^^^ error: aborting due to 7 previous errors Some errors have detailed explanations: E0552, E0589, E0693. For more information about an error, try `rustc --explain E0552`. </del>

Discussion:
<!-- [31mICE[0m: Rustc '' 'error: internal compiler error: unrecognized representation hint', 'error: internal compiler error: unrecognized representation hint' File: --snippet: 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: --
Regression in nightly-2023-08-26
Change:
<ins> error: overly complex generic constant --> $DIR/issue-67945-4.rs:9:13 | LL |       A: [(); { |  _____________^ LL | |         let x: Option<Box<S>> = None; LL | | LL | |         0 LL | |     }], | |_____^ blocks are not supported in generic constant | = help: consider moving this anonymous constant into a `const` function = note: this operation may be supported in the future error: aborting due to previous error </ins>

Discussion:
The following ICE's on nightly and beta: <details<summaryBacktrace:</summary</details
Reduced: ICE most likely occurs in: I cannot seem to reproduce this without an , so cc
Reduced even more: (Please include all 3 variants thus far in a regression test.)
I looked into this briefly and found that on this line: has the value: Digging a bit deeper, the generics appear to be empty because of the following lines: I can confirm that adding makes this code compile, so I suspect that this is blocked on .
What would be the consequences of always returning the DefId?
It causes query cycle errors at the moment.
Discussed at T-compiler meeting. Due to all the known examples being compile-time errors, the ICE here does not seem so strong a hazard as to warrant weekly visits during triage. (Certainly failing more gracefully would be great. But its not something we're going to e.g. block a release on.) Downgrading priority to P-medium.
Some relevant examples. This gives an (incorrect) error on stable that does not hold: This ICEs on stable:
Is there a reason why we can't just disallow type parameters from appearing within constants during resolve, like we do for type parameters from outer functions? Obviously const generics/lazy normization willl loosen this rule.
good point, I imagine that might work.
Another variant on this bug:
Triage: The two examples that Centril posted ( and ) are no longer ICEs in the latest nightly. Possibly related to ?
Maybe we should just add tests then?
Sounds good! I'll do later.
Another variant (though likely the same): This gives a different to the original, despite being essentially the same code.
Triage: All the snippets including the original are no longer ICE with the latest nightly:
Change:
} } <ins> #[stable(feature = "os_str_str_ref_eq", since = "1.28.0")] impl<'a> PartialEq<&'a str> for OsString { fn eq(&self, other: &&'a str) -> bool { **self == **other } } #[stable(feature = "os_str_str_ref_eq", since = "1.28.0")] impl<'a> PartialEq<OsString> for &'a str { fn eq(&self, other: &OsString) -> bool { **other == **self } } </ins> #[stable(feature = "rust1", since = "1.0.0")] impl Eq for OsString {}

Discussion:
I've just got very surprised to find out that doesn't compile, but does. After some investigation, I found that is missing. Similar impl is present for though. I believe it'd be nice to implement it.
is to as is to , so check out , this implementation might meet your needs.
I've soled my problem immediately. I filed issue because I think we could help others by implementing the trait.
Change:
#[cfg_attr(not(test), rustc_diagnostic_item = "print_macro")] #[allow_internal_unstable(print_internals)] macro_rules! print { <del> ($($arg:tt)*) => { $crate::io::_print($crate::format_args!($($arg)*)) }; </del> <ins> ($($arg:tt)*) => {{ $crate::io::_print($crate::format_args!($($arg)*)); }}; </ins> } /// Prints to the standard output, with a newline.

Discussion:
https://crater- https://crater- https://crater- https://crater- https://crater- https://crater- is likely cause (cc
I'll fix this.
Fixed on beta with and on master. will be a more complete change and will likely land in 1.63 (or later).
Change:
/// tokens. UnknownPrefix, <ins> /// Similar to the above, but *always* an error on every edition. This is used /// for emoji identifier recovery, as those are not meant to be ever accepted. InvalidPrefix, </ins> /// Examples: `12u8`, `1.0e-40`, `b"123"`. Note that `_` is an invalid /// suffix, but may be present here on string and float literals. Users of /// this type will need to check for and reject that case.

Discussion:
In the 2015 and 2018 editions, the following compiles (with warnings): ` [playground] The is taken as an identifier, although emoji aren't generally permitted in identifiers in any edition. I tested with 1.77.1. I think the underlying problem is that and in distinguish "identifiers" containing emoji (as rather than ), but don't have a way to make that distinction for . [playground]:
Regression from 1.57 to 1.58 (stable to stable). Very likely in , cc Regression from error to pass. Previous error: .
WG-prioritization assigning priority (). label -I-prioritize +P-low
thank you for the detailed report. will fix this.
Change:
ty::FnDiverging => unreachable!() } } <ins> pub fn unwrap_or(self, def: Ty<'tcx>) -> Ty<'tcx> { match self { ty::FnConverging(t) => t, ty::FnDiverging => def } } </ins> } pub type PolyFnOutput<'tcx> = Binder<FnOutput<'tcx>>;

Discussion:
Compiler panics, when closure marked as diverging. I tried this code: I expected to see this happen: Instead, this happened: : Backtrace:
Change:
background: rgba(0, 0, 0, 0); } <del> code { </del> <ins> .docblock code { </ins> color: #ffb454; } h3 > code, h4 > code, h5 > code {

Discussion:
Ayu-only. The summary in the search results is now blue, when it used to be white. ! ! Ayu-only. The color of impls in Ayu has changed from white to yellow. This may be intentional, but it looked off when I saw it. Note that this happens for all impls, not just foreign impls. ! ! All themes. Certain auto-trait, foreign, unconditional impls have underlines. ! ! All themes. The phrase next to in the search results is now red in addition to itself being red, whereas used to be gray. ! ! All of the regressions seem to have occurred in beta (1.54.0).
Regression 3 is fixed in
Sending a fix for the three others.
Regressions 1 and 4 are fixed in .
Change:
components.push(ptr) } <del> let name = fmt!("%s_vtable_%u", ty_to_str(ccx.tcx, tydesc.ty), token::gensym("vtable")); </del> let tbl = C_struct(components); <del> let vt_gvar = do name.as_c_str |buf| { </del> <ins> let vtable = ccx.sess.str_of(gensym_name("vtable")); let vt_gvar = do vtable.as_c_str |buf| { </ins> llvm::LLVMAddGlobal(ccx.llmod, val_ty(tbl).to_ref(), buf) }; llvm::LLVMSetInitializer(vt_gvar, tbl);

Discussion:
Configured with
I found that does not properly emit some information for android assembler. keep digging do you have any idea to fix this ?
some symbol starts with which arm as cannot recognize it [error] [orig]
Ok, I know what the issue is now. I changed the naming of the vtables, since they are internal, in order to make it easier to debug. So they now have the type attached. Apparently the 's don't get changed the same way the '<' and ''s do. I'll get on it.
works with below patch
Change:
Ok(TokenTree::Delimited(delim_span, open_delim, tts)) } <ins> fn unclosed_delim_err(&mut self, tts: TokenStream, mut errs: Vec<PErr<'a>>) -> Vec<PErr<'a>> { // If there are unclosed delims, see if there are diff markers and if so, point them // out instead of complaining about the unclosed delims. let mut parser = crate::stream_to_parser(self.string_reader.sess, tts, None); let mut diff_errs = vec![]; // Suggest removing a `{` we think appears in an `if`/`while` condition // We want to suggest removing a `{` only if we think we're in an `if`/`while` condition, but // we have no way of tracking this in the lexer itself, so we piggyback on the parser let mut in_cond = false; while parser.token != token::Eof { if let Err(diff_err) = parser.err_diff_marker() { diff_errs.push(diff_err); } else if parser.is_keyword_ahead(0, &[kw::If, kw::While]) { in_cond = true; } else if matches!( parser.token.kind, token::CloseDelim(Delimiter::Brace) | token::FatArrow ) { // end of the `if`/`while` body, or the end of a `match` guard in_cond = false; } else if in_cond && parser.token == token::OpenDelim(Delimiter::Brace) { // Store the `&&` and `let` to use their spans later when creating the diagnostic let maybe_andand = parser.look_ahead(1, |t| t.clone()); let maybe_let = parser.look_ahead(2, |t| t.clone()); if maybe_andand == token::OpenDelim(Delimiter::Brace) { // This might be the beginning of the `if`/`while` body (i.e., the end of the condition) in_cond = false; } else if maybe_andand == token::AndAnd && maybe_let.is_keyword(kw::Let) { let mut err = parser.struct_span_err( parser.token.span, "found a `{` in the middle of a let-chain", ); err.span_suggestion( parser.token.span, "consider removing this brace to parse the `let` as part of the same chain", "", Applicability::MachineApplicable, ); err.span_label( maybe_andand.span.to(maybe_let.span), "you might have meant to continue the let-chain here", ); errs.push(err); } } parser.bump(); } if !diff_errs.is_empty() { errs.iter_mut().for_each(|err| { err.delay_as_bug(); }); return diff_errs; } return errs; } </ins> fn close_delim_err(&mut self, delim: Delimiter) -> PErr<'a> { // An unexpected closing delimiter (i.e., there is no // matching opening delimiter).

Discussion:
Unmatched delimiters are hard to deal with by taking consideration of surrounding code because they actually occur during lexing. Still, it'd be nice if we detected some common sources of issues like this one. No response No response <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Change:
<ins> error: unused doc comment --> $DIR/useless-comment.rs:9:1 | LL | /// foo | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ rustdoc does not generate documentation for macro invocations | note: the lint level is defined here --> $DIR/useless-comment.rs:3:9 | LL | #![deny(unused_doc_comments)] |         ^^^^^^^^^^^^^^^^^^^ = help: to document an item produced by a macro, the macro must produce the documentation as part of its expansion error: unused doc comment --> $DIR/useless-comment.rs:32:5 | LL |     /// bar |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ rustdoc does not generate documentation for macro invocations | = help: to document an item produced by a macro, the macro must produce the documentation as part of its expansion error: unused doc comment --> $DIR/useless-comment.rs:13:5 | LL |     /// a |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ LL |     let x = 12; |     ----------- rustdoc does not generate documentation for statements error: unused doc comment --> $DIR/useless-comment.rs:16:5 | LL | /     /// multi-line LL | |     /// doc comment LL | |     /// that is unused | |______________________^ LL | /     match x { LL | |         /// c LL | |         1 => {}, LL | |         _ => {} LL | |     } | |_____- rustdoc does not generate documentation for expressions error: unused doc comment --> $DIR/useless-comment.rs:20:9 | LL |         /// c |         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ LL |         1 => {}, |         ------- rustdoc does not generate documentation for match arms error: unused doc comment --> $DIR/useless-comment.rs:25:5 | LL |     /// foo |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ LL |     unsafe {} |     --------- rustdoc does not generate documentation for expressions error: unused doc comment --> $DIR/useless-comment.rs:28:5 | LL |     #[doc = "foo"] |     ^^^^^^^^^^^^^^ LL |     #[doc = "bar"] LL |     3; |     - rustdoc does not generate documentation for expressions error: unused doc comment --> $DIR/useless-comment.rs:29:5 | LL |     #[doc = "bar"] |     ^^^^^^^^^^^^^^ LL |     3; |     - rustdoc does not generate documentation for expressions error: unused doc comment --> $DIR/useless-comment.rs:35:13 | LL |     let x = /** comment */ 47; |             ^^^^^^^^^^^^^^ -- rustdoc does not generate documentation for expressions error: unused doc comment --> $DIR/useless-comment.rs:37:5 | LL |       /// dox |       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ LL | /     { LL | | LL | |     } | |_____- rustdoc does not generate documentation for expressions error: aborting due to 10 previous errors </ins>

Discussion:
Other expressions work as expected: it reports just one error, for the whole sequence of doc comment lines. () Errors:
( is a rustc lint.)
True, but I as well since it's a rustdoc-related lint.
Change:
let param_env = tcx.param_env(src.def_id()).with_reveal_all(); let move_data = match MoveData::gather_moves(body, tcx, param_env) { Ok(move_data) => move_data, <del> Err(_) => bug!("No `move_errors` should be allowed in MIR borrowck"), </del> <ins> Err((move_data, _)) => { tcx.sess.delay_span_bug( body.span, "No `move_errors` should be allowed in MIR borrowck", ); move_data } </ins> }; let elaborate_patch = { let body = &*body;

Discussion:
The following ICE's on stable, beta and nightly: <details<summaryBacktrace:</summary</detailsPossibly related to , except with a different ICE message.
The bug here should be delayed:
triage: P-medium, removing I-nominated label.
Change:
sole_variant_val = val[enum_members[0]] disr_field = get_field_at_index(sole_variant_val, disr_field_index) <del> discriminant = int(sole_variant_val[disr_field]) </del> <ins> discriminant = sole_variant_val[disr_field] # If the discriminant field is a fat pointer we have to consider the # first word as the true discriminant if discriminant.type.code == gdb.TYPE_CODE_STRUCT: discriminant = discriminant[get_field_at_index(discriminant, 0)] </ins> if discriminant == 0: null_variant_name = first_variant_name[last_separator_index + 1:]

Discussion:
Debuginfo for (and probably also ) enums is not correct if the pointer that doubles as discriminant is a fat pointer. Steps to reproduce: (1) Compile the following program with (2) Print the value of in LLDB with pretty printers enabled: This should print instead of . Maybe it's just the LLDB pretty printer that needs to be adapted.
Change:
fn should_run(run: ShouldRun<'_>) -> ShouldRun<'_> { let builder = run.builder; let run = run.suite_path("src/test/rustdoc-gui"); <del> run.default_condition( </del> <ins> run.lazy_default_condition(Box::new(move || { </ins> builder.config.nodejs.is_some() && builder .config .npm .as_ref() .map(|p| check_if_browser_ui_test_is_installed(p)) <del> .unwrap_or(false), ) </del> <ins> .unwrap_or(false) })) </ins> } fn make_run(run: RunConfig<'_>) {

Discussion:
introduced some checks which execute 4 times. They run unconditionally when executing , even if it is just to run tidy. On my system the wall time exceeds that of running tidy itself. I'll look into whether the checks themselves can be made be less wasteful. But if there are suggestions how to completely eliminate them or defer them while preserving their original purpose that would be great too. ! CC can you explain the purpose of running this in rather than erroring in ?
To know beforehand if the test should unconditionally be run or not. If the test is run and the npm package isn't installed, we panic. To be noted that we could make it go down to 2 by switching the order of : currently we check both "local" and "global". Switching the two of them will divide the number of calls by two. cc
I don't have installed, so it'll fail and no short-circuiting will happen regardless of order.
In case you don't have it it'll check 4 times indeed.
Hm, this does seem annoying. It's possible we could add some lazily-evaluated default condition so that this never runs if we're not considering default-on steps (if defaults are on, then these npm lists are likely quite fast in comparison to the rest of the logic).
Change:
_marker: PhantomData<&'a mut T>, } <ins> unsafe impl<'a, T> Sync for DormantMutRef<'a, T> where &'a mut T: Sync {} unsafe impl<'a, T> Send for DormantMutRef<'a, T> where &'a mut T: Send {} </ins> impl<'a, T> DormantMutRef<'a, T> { /// Capture a unique borrow, and immediately reborrow it. For the compiler, /// the lifetime of the new reference is the same as the lifetime of the

Discussion:
The code below does not compile on new versions of (bisect below) searched nightlies: from nightly-2020-09-11 to nightly-2020-09-12 regressed nightly: nightly-2020-09-12 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.5.2</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
cc
We probably just need to and likewise for Sync. Conceptually it's no different to a &mut T, so that should be reasonable.
can we assign the issue to you given that you've already provided a PR?
I'm going to self-assign, I don't expect to hit any roadblocks with the PR though, it's already bors-ready.
Change:
| --------------------------------- first implementation here LL | impl Foo for i16 {} | ^^^^^^^^^^^^^^^^ conflicting implementation for `i16` <ins> | = note: upstream crates may add new impl of trait `coherence_lib::Remote` for type `i16` in future versions </ins> error: aborting due to previous error

Discussion:
PR had removed the notes from the tests for the upstream/downstream printing logic, so now that logic is not tested: Plus, the new error messages are worse: an upstream impl can indeed be , even if the crate is private. I think that even in the OP case, some sort of note should be , unless we change coherence. Again, the test case: There, the error message is a coherence conflict for , where this impl conflicts with the libcore impl, because the compiler can't prove that . Now, the error message says that the reason that the compiler can't prove is because of a possible downstream impl. Of course, no downstream impl can exist as the trait is private, however, I don't think we want to change coherence to account for that, especially not without an RFC. Maybe a wording change is in order? I don't think the "upstream" message needs to change any (see the test diff), it's still good in the private case. Maybe it should try to mention a non-private trait, but that would be some work. Say, for non-exported trait, change the note to say: I'm not even sure the note is a problem, I personally like the state before the PR the best. cc
Actually, I think the version of the note I came up with is even more confusing than the "downstream crate" note, and the current version is worse than both.
That PR was also submitted with no "positive" test to see that it fixes the error message it is purported to fix. That feels clearly wrong to me.
Change:
).map(|mut i| { let attr = cx.meta_word(span, sym::rustc_proc_macro_decls); i.attrs.push(cx.attribute(attr)); <ins> let deprecated_attr = attr::mk_nested_word_item( Ident::new(sym::deprecated, span) ); let allow_deprecated_attr = attr::mk_list_item( Ident::new(sym::allow, span), vec![deprecated_attr] ); i.attrs.push(cx.attribute(allow_deprecated_attr)); </ins> i });

Discussion:
Use attribute on a procedural macro function doesn't work like expected: it triggers a warning message also when library is building and not just in call place. I know that the attribute support is not landed in stable but this warning is present in all channels (stable, beta and nightly). Compiling lib simple by raise follow warning: Sadly this issue make attribute not usable at all for procedural macro. Follow the code to reproduce this issue: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
The most likely reason is that and friends are used from the proc macro harness automatically generated for proc macro crates. So either the harness should generate (there are precedents for this, e.g. test harness generates ), or should not be reported from "externally generated code", which usually includes macros from other crates, but also code generated by the compiler.
Adding should be a very simple fix - the item referring to the proc macro definition functions is generated in in .
claim
Change:
use schema::{METADATA_HEADER, rustc_version}; use rustc::hir::svh::Svh; <del> use rustc::session::Session; </del> <ins> use rustc::session::{config, Session}; </ins> use rustc::session::filesearch::{FileSearch, FileMatches, FileDoesntMatch}; use rustc::session::search_paths::PathKind; use rustc::util::common;

Discussion:
Today when you compile for a target that does not exist rustc gives the standard message for failing to find a crate, for . We can and should be more explicit about what this means. Actually what is almost certainly happening is that you don't have that target installed: It could instead say: A reasonable heuristic for printing this might be if the crate is named or and the sysroot is not overridden.
When I run on I get the error:
I would like to try my hand at this if no one else has picked it up already. I am fairly new to rust, so I might need some assistance getting the pull request into a something resembling a reasonable state.