jiebi/CodeConvo huggingface dataset:
Change:
<ins> error: cannot test inner items --> $DIR/issue-107454.rs:7:5 | LL |     #[test_case] |     ^^^^^^^^^^^^ | note: the lint level is defined here --> $DIR/issue-107454.rs:4:9 | LL | #![deny(unnameable_test_items)] |         ^^^^^^^^^^^^^^^^^^^^^ = note: this error originates in the attribute macro `test_case` (in Nightly builds, run with -Z macro-backtrace for more info) error: aborting due to previous error </ins>

Discussion:
This happens when a test function is declared inside another function, the one where the tests start running to be precise, using a custom testing framework in a nostd environment. link: at lines: 31 [function declared outside] , 40 [comment of function declared inside] I checked with the latest version of the nightly channel, and could not find any related issues <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
Running on your current master branch () doesn't reproduce the issue for me, all tests pass.
That is because the section causing the issue is commented out, if you remove function27 (dont mind the name) from and replace the comment from the function init() in with function27, it should reproduce the issue (just checked again) ! I shouldve pushed and linked a version that reproduces the issue, my bad
I'm able to reproduce this with nightly <details<summary<stronglong file</strong</summary<p</p</details
Got it down to this: using (see ).
claim
Change:
| |                   ------------------------------ temporary value created here LL | |     } | |_____^ returns a value referencing data owned by the current function <ins> | = help: use `.collect()` to allocate the iterator </ins> error: aborting due to 4 previous errors

Discussion:
Given a situation where an iterator is : We should suggest using in these cases. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Or flatten/flat_map?
I want for us to detect cases of trying to operate on iterators of iterators because the only option then is to allocate or completely rework the logic. The former will help newcomers, experts will know enough to try the later.
claim
Couldn't we still recommend both? Recommending bad practices seems suboptimal.
Change:
<ins> // needs-unwind #![feature(unsized_fn_params)] #[inline(always)] fn callee(y: [i32]) {} // EMIT_MIR unsized_argument.caller.Inline.diff fn caller(x: Box<[i32]>) { callee(*x); } fn main() { let b = Box::new([1]); caller(b); } </ins>

Discussion:
Inlining introduces unsized temporaries. This is problematic since unsized temporaries fail to uphold alignment requirements as described in . For example:
The unsized locals alignment issue itself was fixed in .
Change:
x.push(y); //~ ERROR explicit lifetime required } fn main() { <del> let x = baz; </del> }

Discussion:
Look at its expected error output is () but under NLL it yields (): The latter is amazingly different from the former.
Hmm. We actually do try to give the nicer errors, but for whatever reason the heuristics we use to decide what is the "main error" to report are failing here. Seems like an interesting case to dig into a bit.
But I'll mark it as a sub-issue of
OK so -- the problem here I think is the TEST. In particular, the line serves no purpose. It does however cause typeck to fail and hence we never get to MIR borrowck. If you remove that line and enable , we get the same error message.
Change:
// Don't inject `extern crate std` because it's already injected by the // compiler. <del> if !s.contains("extern crate") && !opts.no_crate_inject { </del> <ins> if !s.contains("extern crate") && !opts.no_crate_inject && cratename != Some("std") { </ins> match cratename { Some(cratename) => { if s.contains(cratename) {

Discussion:
Th example here: shows
We need an explicit here, I think
when I click on the codepen link, I do see an explicit . However, the function was not being called.
Right, but I think it does the wrong thing, because that main is generated by Rustdoc. It's only a theory, I could be wrong
Oh! No, this is
Change:
<ins> // Regression test for #121532 // Checks the we don't ICE in ArrayIntoIter // lint when typeck has failed // Typeck fails for the arg type as // `Self` makes no sense here fn func(a: Self::ItemsIterator) { //~ ERROR failed to resolve: `Self` is only available in impls, traits, and type definitions a.into_iter(); } fn main() {} </ins>

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:
<ins> // Regression test for #88684: Improve diagnostics for combining marks // in character literals. // run-rustfix fn main() { let _spade = "♠️"; //~^ ERROR: character literal may only contain one codepoint //~| NOTE: this `♠` is followed by the combining mark `u{fe0f}` //~| HELP: if you meant to write a `str` literal, use double quotes let _s = "ṩ̂̊"; //~^ ERROR: character literal may only contain one codepoint //~| NOTE: this `s` is followed by the combining marks `u{323}u{307}u{302}u{30a}` //~| HELP: if you meant to write a `str` literal, use double quotes let _a = 'Å'; //~^ ERROR: character literal may only contain one codepoint //~| NOTE: this `A` is followed by the combining mark `u{30a}` //~| HELP: consider using the normalized form `u{c5}` of this character } </ins>

Discussion:
I tried to compile the following code (): For the avoidance of doubt, is . I expected the code to compile—but instead, the literal is rejected: Notably, it is accepted if unicode-escaped: :
The spade "character" in your code is not just a single U+2660, it also has a unicode variation selector U+FE0F: On my machine at least, this makes a visible difference in appearance (which github tries to eliminate by adding a U+FE0F unless I "escape" with a code block):
D'oh! Good spot, thanks Perhaps some improved diagnostics could have helped here?
We have similar diagnostics in other cases of misleading Unicode so that seems like a good idea.
Change:
} }; <del> let coerce_to = match opt_coerce_to { Some(c) => c, None => { // If the loop context is not a `loop { }`, then break with // a value is illegal, and `opt_coerce_to` will be `None`. // Return error in that case (#114529). return Ty::new_misc_error(tcx); } }; </del> <ins> // If the loop context is not a `loop { }`, then break with // a value is illegal, and `opt_coerce_to` will be `None`. // Set expectation to error in that case and set tainted // by error (#114529) let coerce_to = opt_coerce_to.unwrap_or_else(|| { let guar = tcx.sess.delay_span_bug( expr.span, "illegal break with value found but no error reported", ); self.set_tainted_by_errors(guar); Ty::new_error(tcx, guar) }); </ins> // Recurse without `enclosing_breakables` borrowed. e_ty = self.check_expr_with_hint(e, coerce_to);

Discussion:
<!-- [31mICE[0m: Rustc '' 'error: internal compiler error: no type for local variable HirId(DefId(0:3 ~ E798F6428C27040F6BCB788CE3C70B28DC596BC8C3AD45A9CC67EC872D6B13EF[a927]::main).70) (local )', 'error: internal compiler error: no type for local variable HirId(DefId(0:3 ~ E798F6428C27040F6BCB788CE3C70B28DC596BC8C3AD45A9CC67EC872D6B13EF[a927]::main).70) (local )' File: --auto-reduced (treereduce-rust): &lt;details&lt;summary&lt;strongoriginal code&lt;/strong&lt;/summary&lt;poriginal: </p</detailsVersion information Command: &lt;!-- Include a backtrace in the code block by setting in your environment. E.g. . --&lt;details&lt;summary&lt;strongProgram output&lt;/strong&lt;/summary&lt;p&lt;/p&lt;/details&lt;!-- TRIAGEBOTSTART --&lt;!-- TRIAGEBOTASSIGNSTART --&lt;!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --&lt;!-- TRIAGEBOTASSIGNEND --&lt;!-- TRIAGEBOTEND --
Regression in nightly-2023-10-31 Regression in = ping
reduced a bit further:
claim
Change:
stable = $stable:expr $(,tool_std = $tool_std:literal)? $(,allow_features = $allow_features:expr)? <ins> $(,add_bins_to_sysroot = $add_bins_to_sysroot:expr)? </ins> ;)+) => { $( #[derive(Debug, Clone, Hash, PartialEq, Eq)]

Discussion:
Running doesn't include miri as part of the built rust toolchain, meaning that doesn't work cc <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
label +A-rustbuild
It seems like the same thing happens to rustfmt: doesn't include rustfmt as part of the built rust toolchain, meaning that doesn't work.
The same thing applies to and .
We need to call in all of these steps. I think that currently adds all libraries as well which isn't correct - someone should look into how this is done for rustdoc and do the same for the other tools. Take a look around I agree it's a bug that we don't copy these today.
claim
this seems related to
claim

This is derived from , in which we concluded that the bug should be filed against rustc, as it's an problem. In rustc: Then in a project using this toolchain via a rustup link: But note that does not make this work either, so there is probably more to it? Thanks <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
[removed comment, wrong issue, sorry]
(I think you posted that comment in the wrong place.)
Oops, yes.
Can anyone comment on what the correct fix for this might be? I notice that if I copy and from into then I'm able to run via the linked toolchain. I initially considered changing rustup to add to the PATH, but that seems incorrect as we would be adding something outside of the toolchain root to PATH. So should x.py copy or move the binaries from into ? I'm willing to (attempt to) do the work if we can agree on what the correct fix is.
I'm not really knowledgeable about . You might want to ask in on Zulip.
Yes, it should copy the binaries from stage1-tools-bin to stage1/bin.
Mentoring instructions: Add a new argument to the macro that says whether the tool should be to the sysroot, then copy it into the sysroot just after
I believe this will be fixed by , once we figure out some problems with clippy/fmt builds.
claim
Change:
_ => Res::Err, }; <del> err.span_label(call_expr.span, "call expression requires function"); </del> <ins> if !self.maybe_suggest_bad_array_definition(&mut err, call_expr, callee_expr) { err.span_label(call_expr.span, "call expression requires function"); } </ins> if let Some(span) = self.tcx.hir().res_span(def) { let callee_ty = callee_ty.to_string();

Discussion:
Given the following code (): The current output is: <!-- The following is not always necessary. --Ideally the output should look like: and the compiler would preview the fix, by adding the commas in green. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
This week I'm busier than I thought ;) release-assignment
label +A-parser
claim
Change:
<ins> include ../../run-make-fulldeps/tools.mk # ignore-cross-compile all: # Smoke-test that `#[bench]` isn't entirely broken. $(RUSTC) --test smokebench.rs -O $(call RUN,smokebench --bench) $(call RUN,smokebench --bench noiter) $(call RUN,smokebench --bench yesiter) $(call RUN,smokebench) </ins>

Discussion:
<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. --I tried running benchmarks with current nightly rust: Running with the previous nightly works: Also, note the difference in the line . This happens for the benchmarks in both the and crates. looks to be related ( <!-- 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<summaryBacktrace</summary<p</p</details
Ouch. I guess libtest needs better tests. I might be able to get to this in 12 hours or so, if anyone else sees this please do take care of it.
Oof, missed that started as the full list of tests+benches before getting shadowed as only the tests. Not a fan of the way TestEvent is used to manage state (haven't ever been a fan of it, TBH), but I'll have to think a bit about how to fix it without undoing the perf wins we just got here.
Confirm the bug as well: started to fail after changing the toolset to the current nighly.
Yeah, should be fixed by . Hopefully will be in the next nightly, if we're lucky.
Change:
pub unsafe fn new() -> Handler { make_handler() } <ins> fn null() -> Handler { Handler { _data: crate::ptr::null_mut() } } </ins> } impl Drop for Handler {

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 tried this code: and compiled it with: I expected to see asan report a bad pointer use and give a backtrace. Instead I just got a raw sigsegv: Running with verbose output shows that AddressSanitizer is intercepting the signal. It looks like is also installing a signal handler, which is overriding the AddressSanitizer one. <!-- 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. --: </p</details
(set handler and prevent override) is a workaround, but I think the Rust runtime shouldn't stomp SIGSEGV in the sanitizer case.
cc
Change:
{"message":"mismatched types","code":{"code":"E0308","explanation":"Expected type did not match the received type. <del> Erroneous code example: </del> <ins> Erroneous code examples: </ins> ```compile_fail,E0308 <del> let x: i32 = "I am not a number!"; //     ~~~   ~~~~~~~~~~~~~~~~~~~~ //      |             | //      |    initializing expression; //      |    compiler infers type `&str` //      | //    type `i32` assigned to variable `x` </del> <ins> fn plus_one(x: i32) -> i32 { x + 1 } plus_one("Not a number"); //       ^^^^^^^^^^^^^^ expected `i32`, found `&str` if "Not a bool" { // ^^^^^^^^^^^^ expected `bool`, found `&str` } let x: f32 = "Not a float"; //     ---   ^^^^^^^^^^^^^ expected `f32`, found `&str` //     | //     expected due to this </ins> ``` <del> This error occurs when the compiler is unable to infer the concrete type of a variable. It can occur in several cases, the most common being a mismatch between two types: the type the author explicitly assigned, and the type the compiler inferred. </del> <ins> This error occurs when an expression was used in a place where the compiler expected an expression of a different type. It can occur in several cases, the most common being when calling a function and passing an argument which has a different type than the matching type in the function declaration. </ins> "},"level":"error","spans":[{"file_name":"$DIR/flag-json.rs","byte_start":244,"byte_end":246,"line_start":7,"line_end":7,"column_start":17,"column_end":19,"is_primary":true,"text":[{"text":"    let _: () = 42;","highlight_start":17,"highlight_end":19}],"label":"expected `()`, found integer","suggested_replacement":null,"suggestion_applicability":null,"expansion":null},{"file_name":"$DIR/flag-json.rs","byte_start":239,"byte_end":241,"line_start":7,"line_end":7,"column_start":12,"column_end":14,"is_primary":false,"text":[{"text":"    let _: () = 42;","highlight_start":12,"highlight_end":14}],"label":"expected due to this","suggested_replacement":null,"suggestion_applicability":null,"expansion":null}],"children":[],"rendered":"error[E0308]: mismatched types --> $DIR/flag-json.rs:7:17 |

Discussion:
I believe the error message for E0308 is incorrect. Here it is, with my emphasis on the part that seems incorrect: Isn't this error because the compiler was able to infer the type, but it was not what was expected? For example, in the example provided in the error explanation, the value assigned to is most definitely , and is expected, so the types don't match. modify labels: A-diagnostics D-incorrect D-confusing C-bug
Also the explanation says: between two types: the type the author explicitly assigned, and the type the compiler inferred. Isn't the most common case passing the wrong type to a function? Usually people do not provide a type annotation to a unless it is necessary to help the compiler figure out what concrete type a generic is. Perhaps the explanation could be clarified and expanded upon for that.
You beat me to it :)
Mentoring instructions: Change to have an up-to-date diagnostic and appropriate long description.
On it.
Proposed text:
Overall text looks good. Can you open a PR and -mention me on it?
Change:
} #[test] <ins> fn test_exp() { assert_eq!(1.0, 0.0f64.exp()); assert_approx_eq!(2.718282, 1.0f64.exp()); assert_approx_eq!(148.413159, 5.0f64.exp()); let inf: f64 = Float::infinity(); let neg_inf: f64 = Float::neg_infinity(); let nan: f64 = Float::nan(); assert_eq!(inf, inf.exp()); assert_eq!(0.0, neg_inf.exp()); assert!(nan.exp().is_nan()); } #[test] fn test_exp2() { assert_eq!(32.0, 5.0f64.exp2()); assert_eq!(1.0, 0.0f64.exp2()); let inf: f64 = Float::infinity(); let neg_inf: f64 = Float::neg_infinity(); let nan: f64 = Float::nan(); assert_eq!(inf, inf.exp2()); assert_eq!(0.0, neg_inf.exp2()); assert!(nan.exp2().is_nan()); } #[test] </ins> fn test_asinh() { assert_eq!(0.0f64.asinh(), 0.0f64); assert_eq!((-0.0f64).asinh(), -0.0f64);

Discussion:
This succeeds and shouldn't. In , is also calling . Might just have to add a 2...
And tests probably...
Change:
} ty::Error(_) => {} _ => { <del> struct_span_err!( </del> <ins> let mut err = struct_span_err!( </ins> self.tcx.sess, ty.span, E0118, <del> "no base type found for inherent implementation" ) .span_label(ty.span, "impl requires a base type") .note( "either implement a trait on it or create a newtype  to wrap it instead", ) .emit(); </del> <ins> "no nominal type found for inherent implementation" ); err.span_label(ty.span, "impl requires a nominal type") .note("either implement a trait on it or create a newtype to wrap it instead"); if let ty::Ref(_, subty, _) = self_ty.kind() { err.note(&format!( "you could also try moving the reference to  uses of `{}` (such as `self`) within the implementation", subty )); } err.emit(); </ins> } } }

Discussion:
] To : This should probably use the covered/local terminology from instead of "base type" to avoid the problematic overlap with subtyping/inheritance terminology.
] ] ] (Not really [C-bug], but it was the closest of the template options.)
Just fyi, you can do modify labels to -C-bug +A-diagnostics +C-enhancement +D-newcomer-roadblock which will let you apply most labels yourself. .
Error: Label D-newcomer-roadblock can only be set by Rust team members Please let know if you're having trouble with this bot.
... Oh, unless that happens.
A second attempt :stuckouttongue: modify labels to -C-bug +A-diagnostics +C-enhancement
In the reference, we use the term "nominal type". The error code explanation should also mention unions and trait objects ( is valid). If the person use or , it should also hint at removing the reference and putting them on in the associated items. Not sure if I should open a new issue for that one or not though.
Change:
// Linux. This was added in 2.6.28, however, and because we support // 2.6.18 we must detect this support dynamically. if cfg!(target_os = "linux") { <del> weak! { fn accept4(c_int, *mut sockaddr, *mut socklen_t, c_int) -> c_int </del> <ins> syscall! { fn accept4( fd: c_int, addr: *mut sockaddr, addr_len: *mut socklen_t, flags: c_int ) -> c_int </ins> } <del> if let Some(accept) = accept4.get() { let res = cvt_r(|| unsafe { accept(self.0.raw(), storage, len, SOCK_CLOEXEC) }); match res { Ok(fd) => return Ok(Socket(FileDesc::new(fd))), Err(ref e) if e.raw_os_error() == Some(libc::ENOSYS) => {} Err(e) => return Err(e), } </del> <ins> let res = cvt_r(|| unsafe { accept4(self.0.raw(), storage, len, SOCK_CLOEXEC) }); match res { Ok(fd) => return Ok(Socket(FileDesc::new(fd))), Err(ref e) if e.raw_os_error() == Some(libc::ENOSYS) => {} Err(e) => return Err(e), </ins> } }

Discussion:
Sorry for the cryptic title, didn't knew exactly what to put there. On musl targets (well and (hf)) for some reason pipe2 is not used (even on kernels that support it). Pipe2 is important to protect against race condition when multiple threads run external commands. The following is an example that due to this bug will deadlock on the musl targets listed above (and probably all linux musl ones). Running with strace proves that pipe2 is not used, and that instead the fallback is: vs the target: Versions affected: 1.30.1 1.31.0 - Current stable rustc 1.32.0-nightly ( 2018-12-07) Later Edit: Just to be clear, if I compile a C file with the same musl toolchain that rust uses pipe2 works, so it's not a bug in Musl (or doesn't look like one to me).
cc
Did some investigation regarding this bug: The culprit seems to be: More specifically the following comment: “It assumes that //! we've been dynamically linked to the library the symbol comes from, but that //! is currently always the case for things like libpthread/libc.” Well this is not the case for musl target binaries. pipe2 is one of the symbols rust uses this mechanism to check for existence.(for fair reasons, the symbol is not there on old kernels). But on any musl target this symbol does exist because musl is emulating it in it’s standard library in case the systemcall is missing. A solution would thus be to assume this symbol always exists on musl targets (and it’s probably the same for the other ones) and make the weak! macro return the symbol directly for such targets. I could do it myself if this sounds resonable.
Thanks for the report Your investigation sounds right to me and I agree that we can probably just assume these symbols always exist on the musl target (as we're mostly pulling in the libc anyway). Should be fine to update the standard library to assume so!
Is this kind of what you had in mind? I wanna know if I should go like this, or I understood you wrong.