jiebi/CodeConvo huggingface dataset:
Change:
// check that a comma comes after every field if !ate_comma { <del> let err = ExpectedCommaAfterPatternField { span: self.token.span } </del> <ins> let mut err = ExpectedCommaAfterPatternField { span: self.token.span } </ins> .into_diagnostic(&self.sess.span_diagnostic); if let Some(mut delayed) = delayed_err { delayed.emit(); } <ins> self.recover_misplaced_pattern_modifiers(&fields, &mut err); </ins> return Err(err); } ate_comma = false;

Discussion:
When changing a pattern binding from something like to something like it's easy to end up with which yields an unhelpful syntax error message (). I don't believe it's obvious why and are valid, but is not. The same holds for bindings, of course. It would be nice if rustc's parser accepted the invalid syntax and provided one of its helpful "did you mean to write ?" error messages.
Current output:
Change:
trait_name: Symbol, } <ins> #[derive(LintDiagnostic)] #[diag(trait_selection_disallowed_positional_argument)] #[help] pub struct DisallowedPositionalArgument; #[derive(LintDiagnostic)] #[diag(trait_selection_invalid_format_specifier)] #[help] pub struct InvalidFormatSpecifier; #[derive(LintDiagnostic)] #[diag(trait_selection_wrapped_parser_error)] pub struct WrappedParserError { description: String, label: String, } </ins> impl<'tcx> OnUnimplementedDirective { fn parse( tcx: TyCtxt<'tcx>,

Discussion:
The following are some unexpected behaviors I see with the formatting strings in the attribute. I'm not sure that the attribute should actually be using std's format parsing, but if it is, the following seem like issues with the current implementation. Anything after the is ignored, and not included in the message output. Expectation: There should be a warning that the string is malformed. or These generate an error. However, my understanding of the attribute is that it tries to only generate warnings for things it doesn't understand. I would expect this to also generate a warning. This does not generate a warning or error. I would expect it to generate a warning that anything after the is ignored. This includes width, precision, debug formatting, etc. The error message generated with this is the type followed by a . I would expect this to generate a warning that the format arguments are not valid (similar to how works). : cc
I filled to hopefully address this.
Good catch! This should probably support a strict subset of formatting (only named arguments and no format options), and warn whenever the string is either not valid for or not in the supported subset. When it shows a warning, not sure what the behavior of the string should be -- maybe just take it as a literal without any interpolation?
Change:
} } <del> fn raw_pat<'a>(p: &'a Pat) -> &'a Pat { </del> <ins> /// Checks for common cases of "catchall" patterns that may not be intended as such. fn pat_is_catchall(dm: &DefMap, p: &Pat) -> bool { match p.node { PatKind::Ident(_, _, None) => pat_is_binding(dm, p), PatKind::Ident(_, _, Some(ref s)) => pat_is_catchall(dm, &s), PatKind::Ref(ref s, _) => pat_is_catchall(dm, &s), PatKind::Tup(ref v) => v.iter().all(|p| pat_is_catchall(dm, &p)), _ => false } } fn raw_pat(p: &Pat) -> &Pat { </ins> match p.node { PatKind::Ident(_, _, Some(ref s)) => raw_pat(&s), _ => p

Discussion:
This simple code fails to compile because is not defined. But the error message is . But is not the cause it just happens to occur after .
I agree that this is confusing, though from the compiler's perspective, the error message makes sense. Since isn't a variant of , becomes the name of a binding that matches all possible values of other than . (See ) Once that happens, the case is indeed unreachable.
Perhaps the error message could point to the match arm that the unreachable arm overlaps with.
Also if you comment out the Bar arm, you get a snake-case warning on Other, but unfortunately the error happens first.
Thanks for your coments. Now at least I understand why the compiler printed this error message.
Related:
Change:
static HANDLER_LOCK: StaticRwLock = StaticRwLock::new(); static mut HANDLER: Handler = Handler::Default; <ins> static FIRST_PANIC: AtomicBool = AtomicBool::new(true); </ins> /// Registers a custom panic handler, replacing any that was previously /// registered.

Discussion:
Given this code, the failure message looks like this This is problematic as the useful information (the message passed to )is buried inside the sentence. It'd be better if the failure message was on its own line, something akin to: This format also allows for space to mention other useful information (e.g. issue ).
Is this still something we want to do? I have a small patch that implements something like this and would also but I'm not sure how many people really want another format for panic messages. Changing the format might also break existing tools (for example, there are several run-tests in this repo that expect a panic).
I'd be all for it, I still find those messages hard to read even after all these years.
you should submit it
The pull request didn't really fix this bug... should I make another bug like this, or is this a wontfix now?
Oh sorry, that's because I didn't change the original pull request message. Perhaps can comment on this?
This is somewhat of a wontfix for now, the discussion of concluded that we likely don't want to radically change the format for now due to the concurrency/verbosity reasons mentioned. If this becomes extra onerous in the future, however, we can consider reformatting these messages.

Rust developers are developers. Many will be used to using a debugger. Lets tell them straight up from the message how they can hook up their debugger without having to know anything about rust's name mangling algorithm.
Used as workaround in , but still discovered from other people instead of documentation. . Mentioning in the panic message and possibly in the documentation for might be a good idea. If nobody is already doing this, I will :)
Change:
in_root: bool, handler: &'a errors::Handler, is_proc_macro_crate: bool, <ins> is_test_crate: bool, </ins> } pub fn modify(sess: &ParseSess, resolver: &mut ::syntax::ext::base::Resolver, mut krate: ast::Crate, is_proc_macro_crate: bool, <ins> is_test_crate: bool, </ins> num_crate_types: usize, handler: &errors::Handler, features: &Features) -> ast::Crate {

Discussion:
I setup a crate using the example from There are no tests setup: no tests folder, no #[test] attributes. succeeds fails with: #[procmacroderive]proc-macro Naturally I expected this error not to occur. Run on the latest nightly via rustup: rustc 1.14.0-nightly ( 2016-10-27) binary: rustc commit-hash: commit-date: 2016-10-27 host: x86_64-unknown-linux-gnu release: 1.14.0-nightly LLVM version: 3.9
You can probably work around this by using (although I haven't tested that).
Thanks for the report! I'm not sure what the best way to solve this would be. We could either tell the compiler that doesn't work for these crate types, or we could tell Cargo to not test proc-macro libraries. Both should have the end goal though of having work by default.
Would a simple fix for this be to add to ? Or should - where it currently panics - quietly bail out if this is a test crate?
I'd personally prefer for to keep doing the same feature gating it's doing today, so in that sense I don't think it should take the same bail-out route that rustdoc takes. Adding some logic to though sounds good to me.
I think it was wrong that this ticket was closed with since it states
Actually fixing this appears simpler than I expected. I'm guessing a should be enough. This will ensure all the feature gating is still done, but no expansion is performed. Did you have any further thoughts?
of it works it works for me!
this is failing again. It works correctly on nightly-2017-01-17 rustc 1.16.0-nightly ( 2017-01-17) but fails on nightly-2017-01-18 rustc 1.16.0-nightly ( 2017-01-17).
This could be related to recently enabling doc-testing of proc-macro crates in cargo This rustc change should fix that If you look at the cargo output, does the error happen when running the normal tests, or after trying to run doc-tests? Edit: I've tested this in the latest nightly from rustup, and this is definitely what is happening. Hopefully it will be fixed soon.

thanks for staying on top of this! I've approved and p=1'd it to hopefully get it in soon. sorry for the breakage!
Change:
<ins> // Copyright 2016 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. // compile-flags: --test #![crate_type = "proc-macro"] #![feature(proc_macro)] extern crate proc_macro; #[proc_macro_derive(A)] //~^ ERROR: `--test` cannot be used with proc-macro crates pub fn foo1(input: proc_macro::TokenStream) -> proc_macro::TokenStream { "".parse().unwrap() } </ins>

Discussion:
I setup a crate using the example from There are no tests setup: no tests folder, no #[test] attributes. succeeds fails with: #[procmacroderive]proc-macro Naturally I expected this error not to occur. Run on the latest nightly via rustup: rustc 1.14.0-nightly ( 2016-10-27) binary: rustc commit-hash: commit-date: 2016-10-27 host: x86_64-unknown-linux-gnu release: 1.14.0-nightly LLVM version: 3.9
You can probably work around this by using (although I haven't tested that).
Thanks for the report! I'm not sure what the best way to solve this would be. We could either tell the compiler that doesn't work for these crate types, or we could tell Cargo to not test proc-macro libraries. Both should have the end goal though of having work by default.
Would a simple fix for this be to add to ? Or should - where it currently panics - quietly bail out if this is a test crate?
I'd personally prefer for to keep doing the same feature gating it's doing today, so in that sense I don't think it should take the same bail-out route that rustdoc takes. Adding some logic to though sounds good to me.
I think it was wrong that this ticket was closed with since it states
Actually fixing this appears simpler than I expected. I'm guessing a should be enough. This will ensure all the feature gating is still done, but no expansion is performed. Did you have any further thoughts?
of it works it works for me!
this is failing again. It works correctly on nightly-2017-01-17 rustc 1.16.0-nightly ( 2017-01-17) but fails on nightly-2017-01-18 rustc 1.16.0-nightly ( 2017-01-17).
This could be related to recently enabling doc-testing of proc-macro crates in cargo This rustc change should fix that If you look at the cargo output, does the error happen when running the normal tests, or after trying to run doc-tests? Edit: I've tested this in the latest nightly from rustup, and this is definitely what is happening. Hopefully it will be fixed soon.

thanks for staying on top of this! I've approved and p=1'd it to hopefully get it in soon. sorry for the breakage!
Change:
} } <ins> let tcx = self.hir.tcx(); </ins> let tcx_hir = tcx.hir(); let hir_typeck_results = self.hir.typeck_results();

Discussion:
When compiling () The generated assembly includes a prologue with unexpected 's (as well as a trailing , already reported in ) Expected behaviour would be to have no prologue (and prevent compilation of a function that is not as this would require implementing an undefined ABI, contrarily to what seems to happen ). This is treacherous, as it dereferences some memory locations that may not be accessible, as happened to me and led to hours of debugging to finally figure out the compiled function was not the one defined. cc
IIRC this is invalid and rustc should reject such a function, naked functions can't take arguments and the compiler should probably enforce that.
Hmm, my understanding of the RFC (“The following variant is not an error because the C calling convention is well-defined and it is thus possible for the programmer to write a conforming function”, even if the example is not with an argument) would mean that if the function is declared , then the function can actually respect the said ABI, thus should be well-formed?
Is there an update on this? I was hit by this issue as well. I hit the problem when compiling a tock app (baremetal-ish and jumped to by the tock OS) A naked function with arguments would produce this prolog (RV32): Which would result in an invalid access as s0 would be 0. Removing the arguments would remove the prologue and fix the problem. Removing the naked cfg would also work as teh stack pointer was already setup by the OS and result in this. If arguments with naked functions aren't supported rustc should generate an error as this is a difficult problem to debug.
This is an LLVM bug. Has it been reported upstream?
Change:
Change this file to make users of the `download-ci-llvm` configuration download a new version of LLVM from CI, even if the LLVM submodule hasn’t changed. <del> Last change is for: https://github.com/rust-lang/rust/pull/113996 </del> <ins> Last change is for: https://github.com/rust-lang/rust/pull/116881 </ins>

Discussion:
The profile is intended not just for people working on LLVM itself, but also anyone who touches codegen but not LLVM. For example, anyone who modifies or is only changing the IR we send to LLVM, not LLVM itself. We should keep on for them but not for , but ideally we wouldn't build LLVM from source if it's unmodified. points out some things that we should fix before enabling that option by default for the profile: Originally posted by in <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim Should all 3 tasks be in one PR or is it 3 separate PR's?
I'd say it depends how challenging they are - if it's simple to fix all three in one PR that seems fine, but if it takes a more than a day to do one of the tasks, it probably makes sense to open a PR for it early.
I think I can tackle points 1 and 3 by tonight so I'll make that into one PR. I'll open a separate PR for the second point, since I think it has more work involved, if that's alright :)
release-assignment
Change:
let dl = self.data_layout(); let pack = repr.pack; if pack.is_some() && repr.align.is_some() { <del> bug!("struct cannot be packed and aligned"); </del> <ins> self.tcx.sess.delay_span_bug(DUMMY_SP, "struct cannot be packed and aligned"); return Err(LayoutError::Unknown(ty)); </ins> } let mut align = if pack.is_some() { dl.i8_align } else { dl.aggregate_align };

Discussion:
: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Can't reproduce, can you provide the full code that's needed to reproduce this?
Sure
MCVE:
Assigning as discussed as part of the and removing . label -I-prioritize +P-medium
bisection: searched nightlies: from nightly-2020-06-01 to nightly-2021-03-17 regressed nightly: nightly-2020-10-27 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.0</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
Change:
<ins> // compile-flags: -C no-prepopulate-passes #![crate_type = "cdylib"] // CHECK: define void @a() #[no_mangle] #[inline] pub extern "C" fn a() {} // CHECK: define void @b() #[export_name = "b"] #[inline] pub extern "C" fn b() {} // CHECK: define void @c() #[no_mangle] #[inline] extern "C" fn c() {} // CHECK: define void @d() #[export_name = "d"] #[inline] extern "C" fn d() {} // CHECK: define void @e() #[no_mangle] #[inline(always)] pub extern "C" fn e() {} // CHECK: define void @f() #[export_name = "f"] #[inline(always)] pub extern "C" fn f() {} // CHECK: define void @g() #[no_mangle] #[inline(always)] extern "C" fn g() {} // CHECK: define void @h() #[export_name = "h"] #[inline(always)] extern "C" fn h() {} </ins>

Discussion:
Code: If the function is marked as , it doesn't get compiled into the dll file: The reason a function may be marked as both and is so that it gets inlined when compiling the crate as a rust library, but not inlined when compiling the crate as a cdylib. There should be a warning to use something like instead. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
Related to - I think is that we should include 'd functions in s and s, but as a short term solution, a warning is a nice idea
claim

I currently use Rust to generate a static library for FFI consumption. In some public interfaces, I call other FFI public interfaces as primarily a wrapper with a few tweaks. I'd like to mark these "inner" functions as inline, however, this seems to cause them to not show up in the final staticlib. Given this drastically simplified example: The function makes it to the static library, but the function does not: If I remove the attribute, we see both functions in the static lib: The don't seem to hint that can prevent / items from surviving all the way to the final library, or that they shouldn't be used together. I would expect any function marked and/or should be present in the final artifact, regardless of attributes. I see this behavior on stable, as well as a recent nightly. I don't know if this is a regression, as this is the first time I've run into this. Thanks! Edit: Simplified profile settings, they are not needed to reproduce. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Tried with = same result
I’ve noticed this for a while but I always assumed it was intended... It would be really nice if this was fixed
This appears to have been done deliberately: Maybe it shouldn't apply to s.
Expanding on note, I would also expect this not to apply to s as well (I used the staticlib for my example, but my use case generates code for both static and dynamic library usage).
I think I'm going to take this on claim
Change:
<ins> error[E0277]: `Helper<'a, T>` is not an iterator --> $DIR/inherent-bound-in-probe.rs:40:21 | LL |     type IntoIter = Helper<'a, T>; |                     ^^^^^^^^^^^^^ `Helper<'a, T>` is not an iterator | = help: the trait `Iterator` is not implemented for `Helper<'a, T>` note: required by a bound in `std::iter::IntoIterator::IntoIter` --> $SRC_DIR/core/src/iter/traits/collect.rs:LL:COL error[E0275]: overflow evaluating the requirement `&_: IntoIterator` --> $DIR/inherent-bound-in-probe.rs:44:17 | LL |         Helper::new(&self.0) |                 ^^^ | = help: consider increasing the recursion limit by adding a `#![recursion_limit = "256"]` attribute to your crate (`inherent_bound_in_probe`) note: required for `&BitReaderWrapper<_>` to implement `IntoIterator` --> $DIR/inherent-bound-in-probe.rs:34:13 | LL | impl<'a, T> IntoIterator for &'a BitReaderWrapper<T> |             ^^^^^^^^^^^^     ^^^^^^^^^^^^^^^^^^^^^^^ LL | where LL |     &'a T: IntoIterator<Item = &'a u8>, |                         ------------- unsatisfied trait bound introduced here = note: 126 redundant requirements hidden = note: required for `&BitReaderWrapper<BitReaderWrapper<BitReaderWrapper<BitReaderWrapper<BitReaderWrapper<...>>>>>` to implement `IntoIterator` = note: the full type name has been written to '$TEST_BUILD_DIR/methods/inherent-bound-in-probe/inherent-bound-in-probe.long-type-hash.txt' note: required by a bound in `Helper<'a, T>` --> $DIR/inherent-bound-in-probe.rs:25:25 | LL |     &'a T: IntoIterator<Item = &'a u8>, |                         ^^^^^^^^^^^^^ required by this bound in `Helper<'a, T>` error: aborting due to 2 previous errors Some errors have detailed explanations: E0275, E0277. For more information about an error, try `rustc --explain E0275`. </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 via  and some manual item deletion: I can take a quick look into this one I guess. claim
Change:
FusedIterator, InPlaceIterable, SourceIter, TrustedLen, TrustedRandomAccessNoCoerce, }; use core::marker::PhantomData; <del> use core::mem::{self}; </del> <ins> use core::mem::{self, ManuallyDrop}; use core::ops::Deref; </ins> use core::ptr::{self, NonNull}; use core::slice::{self};

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. --I'm trying out the allocator api with the goal of being able to track memory usage for parts of a program: I expected this to work (and print 0 at the end), but instead it fails by freeing an invalid pointer: Running with miri gives a bit more context:
This seems to be a problem with the implementation of because if I do: There is no crash and no Miri error, this to me indicate that there is a problem in the implementation of . Another interesting things is the message I have locally , I don't know what it means but it's certainly interesting. label +T-libs +I-unsound
The drop guard used in the implementation of IntoIter makes a raw copy of an allocator when reconstructing RawVec. The allocator is then dropped twice, once by RawVec drop and second time by IntoIter drop. cc .
Minimal reproduction of problem: Prints:
Change:
version = "0.6.0" dependencies = [ "clippy_lints", <del> "env_logger 0.7.0", </del> <ins> "env_logger 0.7.1", </ins> "failure", "futures", "log",

Discussion:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool miri no longer builds. A follow-up PR to the repository is needed to fix the fallout. cc do you think you would have time to do the follow-up work? If so, that would be great! cc the PR reviewer, and nominating for compiler team prioritization.
triage: has PR (in ). Marking P-medium and removing nomination.
Change:
<ins> error[E0425]: cannot find external crate `foo` in the crate root --> $DIR/crate-called-as-function.rs:2:7 | LL |     ::foo() |       ^^^ not found in the crate root error: aborting due to previous error For more information about this error, try `rustc --explain E0425`. </ins>

Discussion:
Test program: This produces the following error messages: Both the error and the help seem entirely unhelpful. The error suggests that it looked for a function in the crate root, but in fact it looked for a crate . The whole "possible candidate" help seems incorrect, and adding that line would lead to a compilation failure.
cc
This is still an issue, but at least the incorrect help message is no longer displayed: