jiebi/CodeConvo huggingface dataset:
Change:
... LL | impl MyTrait for lib::MyFundamentalStruct<(MyType,)> { } | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ conflicting implementation for `lib::MyFundamentalStruct<(MyType,)>` <ins> | = note: upstream crates may add new impl of trait `lib::MyCopy` for type `lib::MyFundamentalStruct<(MyType,)>` 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:
let trim_chars: &[_] = &[' ', '=']; let value = line[(idx + 1)..] <del> .trim_left_matches(trim_chars) </del> <ins> .trim_start_matches(trim_chars) </ins> .split(';') .map(PathBuf::from);

Discussion:
After +
src/bootstrap changes from should probably be backported to beta
I think this can be closed now
Change:
LL |     if let ....3 = 0 {} |            ^^^ help: use `..=` for an inclusive range <ins> error: `...` range patterns are deprecated --> $DIR/recover-range-pats.rs:129:20 | LL |             let $e1...$e2; |                    ^^^ help: use `..=` for an inclusive range ... LL |     mac2!(0, 1); |     ------------ in this macro invocation error: `...` range patterns are deprecated --> $DIR/recover-range-pats.rs:140:17 | LL |             let ...$e; |                 ^^^ help: use `..=` for an inclusive range ... LL |     mac!(0); |     -------- in this macro invocation error: `...` range patterns are deprecated --> $DIR/recover-range-pats.rs:144:19 | LL |             let $e...; |                   ^^^ help: use `..=` for an inclusive range ... LL |     mac!(0); |     -------- in this macro invocation </ins> error[E0029]: only char and numeric types are allowed in range patterns --> $DIR/recover-range-pats.rs:19:12 |

Discussion:
The CI for started to fail today with this error: It appears as though the compiler doesn't see and only sees as the range expression and then generates this error. The expression is inside a expansion. You can reproduce this by cloning the repo and building it: The build succeeds on the stable channel and much older releases, so this appears to be a regression in the nightly. Here's the version on my windows system, but note that this also fails on linux and macos too:
Regression introduced in
More specifically the bug is in: which is called to see whether what follows is a valid start of a range pattern end expression. This is strange tho... in the case of e.g.: the call to in is used successfully to parse but somehow that doesn't work for . cc
Similarly, with: this does not trigger "error: range patterns are not supported" but it should.
Change:
}; // Invoke the default handler, which prints the actual panic message and optionally a backtrace <del> // Don't do this for `ExplicitBug`, which has an unhelpful message and backtrace. if !info.payload().is::<rustc_errors::ExplicitBug>() { </del> <ins> // Don't do this for `GoodPathBug`, which already emits its own more useful backtrace. if !info.payload().is::<rustc_errors::GoodPathBug>() { </ins> (*DEFAULT_HOOK)(info); // Separate the output with an empty line

Discussion:
With beta but nightly does not show backtraces: edits this is with prioritize
can you share your example code, as it doesn't seem that all ICEs are missing backtraces: on the same nightly and beta, and which has a backtrace on both. (if you have the time to do so and a master checkout, it'd be interesting to know whether ThinLTO could be involved like in ; bisection would also be worthwhile)
Hmm interesting, maybe its' something that only happens with :thinking: does not show a backtrace for me ! I also can't force it with or anything :(
This backtrace was removed on purpose in because it's useless. It just points at the place in the error machinery where delayed bugs get flushed, which is either just noise or misleading at worse.
This also affects explicit calls too -- these should be restored in . Regarding s backtraces being useless, see .
Change:
/// Allows unsafe on extern declarations and safety qualifiers over internal items. (unstable, unsafe_extern_blocks, "1.80.0", Some(123743)), /// Allows unsized fn parameters. <del> (unstable, unsized_fn_params, "1.49.0", Some(48055)), </del> <ins> (internal, unsized_fn_params, "1.49.0", Some(48055)), </ins> /// Allows unsized rvalues at arguments and parameters. (incomplete, unsized_locals, "1.30.0", Some(48055)), /// Allows unsized tuple coercion.

Discussion:
<!-- [31mICE[0m: Rustc '-Zcrate-attr=feature(unsizedfnparams) --crate-type=lib -ooutputfile -Zdump-mir-dir=dir' 'thread 'rustc' panicked at 'unsized arguments must not be types'', 'thread 'rustc' panicked at 'unsized arguments must not be types'' 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: [fnabiofinstance] computing call ABI of --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Regression in nightly-2020-10-29 fetching (via remote github) commits from max(, 2020-10-26) to ending github query because we found starting sha: getcommitsbetween returning commits, len: 7 commit[0] 2020-10-27: Auto merge of - ayrtonm:function-reference-lint, r=oli-obk commit[1] 2020-10-27: Auto merge of - nathanwhit:cstring-temp-lint, r=oli-obk commit[2] 2020-10-28: Auto merge of - Dylan-DPC:rollup-tan044s, r=Dylan-DPC commit[3] 2020-10-28: Auto merge of - est31:smallerlistoverlap, r=varkor commit[4] 2020-10-28: Auto merge of - pietroalbini:build-manifest-checksum-cache, r=Mark-Simulacrum commit[5] 2020-10-28: Auto merge of - nox:function-sections, r=nagisa,bjorn3 commit[6] 2020-10-28: Auto merge of - tgnottingham:expnidtag_hash, r=Aaron1011 I guess
claim
Looks like this is WONTFIX while the features remain experimental (see ).

release-assignment
Yeah, this is a deliberate ICE since a better error requires too much refactoring, and the fundamental issue is that this entire feature was never properly designed and poorly interacts with many other parts of the language. The fix is to mark unsizedfnparams as an internal feature, to warn people about the ICEs lurking here.
Or maybe it is extern types that should be marked as incomplete, they are causing trouble in many ways as nobody ever prepared Rust for types whose size cannot be determined dynamically...
Change:
&self, free_regions: &FreeRegionMap, var_data: &[VarData], <ins> graph: &RegionGraph, </ins> errors: &mut Vec<RegionResolutionError<'tcx>>) -> Vec<VarValue> {

Discussion:
Notably, this does not occur with a trait like: This smells like a bug to me, unless a language change introduced special treatment of with regard to lifetimes.
An interesting quirk is that if you replace with just , it compiles fine with the impl.
cc
are you saying this used to work? Just curious what the original was.
(Also it seems difficult if not impossible to satisfy the combination of and ..... well I guess of static would, but I don't know if we can deduce that.
Yes, this used to work. This bug is affecting
It looks like this may have been introduced in . Prior to this, checking for bounds in was done via , which creates a throw-away inference context before calling into trait selection. It now goes through the ; the impl of for uses its own inference context. This causes region constraints introduced during trait selection for to stick around, resulting in a seemingly inappropriate transitive constraint between the free region within the closure body and at the call site of .
hmm good catch, sorry I let this slip through last week :( I'll try to pay it some attention now. The current code does not seem entirely wrong to me, though. I have to think this through a bit.
Change:
// create all the steps directly in MIR with operations all backends need to support anyway. let (source, ty) = if let ty::Adt(adt_def, ..) = source.ty.kind() && adt_def.is_enum() { let discr_ty = adt_def.repr().discr_type().to_ty(this.tcx); <del> let place = unpack!(block = this.as_place(block, source)); </del> <ins> let temp = unpack!(block = this.as_temp(block, scope, source, Mutability::Not)); </ins> let discr = this.temp(discr_ty, source.span); this.cfg.push_assign( block, source_info, discr, <del> Rvalue::Discriminant(place), </del> <ins> Rvalue::Discriminant(temp.into()), </ins> ); (Operand::Move(discr), discr_ty)

Discussion:
noticed this 1.63→1.64 change in I tried this code: I expected to see this happen: because is non-, an error about moving out from behind a reference, like happened in 1.63 , this happened: it compiles fine in 1.64 in nightly is probably cased by Change enum-int casts to not go through MIR casts which is mentioned in It's unclear to me whether this is intentional under the banner of " behaviour", since there's no trait involved.
Prioritized as P-critical in meeting just now. This needs to be fixed by 1.65 at a minimum.
labels +T-compiler This needs work from T-compiler! :)
labels -I-lang-nominated Meeting consensus is that the current behavior is wrong and needs to be fixed.
Change:
KeyMustBeAString => "key must be a string", ExpectedColon => "expected `:`", TrailingCharacters => "trailing characters", <ins> TrailingComma => "trailing comma", </ins> InvalidEscape => "invalid escape", UnrecognizedHex => "invalid u escape (unrecognized hex)", NotFourDigit => "invalid u escape (not four digits)",

Discussion:
Gives me:
That's because JSON doesn't allow for a trailing comma, I'd imagine.
The specification is clearly wrong here and the decoder should accept trailing commas.
Well, that's not how standards work.
Not sure what you mean by that. I'm not saying that the encoder should produce trailing commas.
There is some precedence for not allowing trailing commas: Go, Chromium, and Firefox reject such json. The specification is still wrong for not allowing them and I see no reason not to parse them.
sad but true. Please feel free to close the issue then.
We could, however, have a better error message.
It shouldn't fail, since it returns a containing possible parse errors.
Change:
let span = token.span.substitute_dummy(sp); <del> let mut err = cx.dcx().struct_span_err(span, parse_failure_msg(&token)); </del> <ins> let mut err = cx.dcx().struct_span_err(span, parse_failure_msg(&token, None)); </ins> err.span_label(span, label); if !def_span.is_dummy() && !cx.source_map().is_imported(def_span) { err.span_label(cx.source_map().guess_head_span(def_span), "when calling this macro");

Discussion:
one of the desired output should be much help, rather than: No response No response <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Change:
/// assert!(!(..1.0).contains(&f32::NAN)); /// assert!(!(..f32::NAN).contains(&0.5)); /// ``` <ins> #[inline] </ins> #[stable(feature = "range_contains", since = "1.35.0")] pub fn contains<U>(&self, item: &U) -> bool where

Discussion:
I tried this code: Also godbolt link I expected to see this happen: I was trying this code to see what kind of assemble the compilers makes. I tried different optimize levels. I see with optimize levels and , that the bits are still there but not used in the function. function is self takes about 5 instructions and the code about 40 instruction, which is dead code. Instead, this happened: bits removed in all the optimize levels. I was using a similar code on a embedded device. FYI: It also happens with . Remove the before 247. I see this happen on stable and nightly both for x86_64 and thumbv6/v7.
This is, unfortunately, well known. and aren't necessarily smaller 'll be optimized out in (which is opt-level=2).
Please open issues if you see any more problems like this. I think this general situation is more of a problem than our issue tracker suggests. If you report them we'll be more aware of the trend, and we can paper over individual situations like this one. I think that's what my linked PR does.
maybe to clarify. With opt_level the assembly of the generated function is fine and optimized. But the bits are not removed and not used. so I am not sure if will help in this case.
does more than just apply an optimization hint. I disassembled the rlib files that come out of compiling that example code and confirmed that my PR does reduce the output to just one function.
Change:
<ins> warning: unresolved link to `long_cat` --> $DIR/macro-docs.rs:5:9 | LL |         /// A |         ^^^^^ ... LL | m!(); | ---- in this macro invocation | = note: `#[warn(rustdoc::broken_intra_doc_links)]` on by default = note: the link appears in this line: [`long_cat`] is really long ^^^^^^^^^^ = note: no item named `long_cat` in scope = help: to escape `[` and `]` characters, add '' before them like `[` or `]` = note: this warning originates in the macro `m` (in Nightly builds, run with -Z macro-backtrace for more info) warning: 1 warning emitted </ins>

Discussion:
: : I expected to see this happen: completes successfully with a "unresolved link to " warning Instead, this happened: <!-- 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
I bet the source span is wrong somehow.
The issue is that the documentation on the re-export is being combined with the original documentation. splits it up by the module it's scoped to, which is different for the two doc-comments; if you remove it works fine. needs to only pass the documentation for the current scope to , not the combined docs. Not sure why it needs a separate file.
The markdown range it comes up with is 3..13. Hmm, this is weird - I think this is actually the correct span because they both come from , which doesn't care about scoping and just works on strings. Maybe it is a bug in after all?
Aha, here we go: is trying to look at the rustc snippet instead of the text it was provided. Maybe it could just work with instead?
Hmm, there are some other bugs here too: normally rustdoc will resolve docs in the scope inside the module and to the scope of the parent. But since there are inner docs, it will resolve all of the links inside the module. I think the fix for both the issues is to separate outer docs from inner ones; not yet sure how to do that.
To add another test-case for what I believe is another instance of the same problem: This doesn't panic, but produces: For an even more confused case, split the module into its own file: Which yields this nonsensical warning: Essentially, the span of the unresolved link is misattributed to the wrong file. The line and column values are correct, it's just the wrong file that's used.
That's is assuming there is only inner or outer docs, not both.
Change:
#[allow(unused_mut)] fn run(mut $sel, $builder: &Builder<'_>) -> Option<PathBuf> { <del> $builder.ensure(ToolBuild { </del> <ins> let tool = $builder.ensure(ToolBuild { </ins> compiler: $sel.compiler, target: $sel.target, tool: $tool_name,

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:
} if tcx.sess.instrument_coverage() { <del> save_unreachable_coverage(basic_blocks, used_blocks); </del> <ins> save_unreachable_coverage(basic_blocks, source_scopes, used_blocks); </ins> } basic_blocks.raw.truncate(used_blocks);

Discussion:
This can be seen here: To reproduce:
Last passing run was so this regressed between 2022-06-30 and 2022-07-02.
Minimized a reproducer. : : Execution:
label regression-untriaged
Bisection says searched nightlies: from nightly-2022-06-29 to nightly-2022-07-03 regressed nightly: nightly-2022-07-03 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.1</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </detailsSo,
WG-prioritization assigning priority (). label -I-prioritize +P-critical
Unfortunately while this fixes the minimal reproducer, it doesn't fix the full case. Would you prefer I file a new bug, or should this one be re-opened? To reproduce:
It's not very minimized, but slightly better. : : Empty
searched nightlies: from nightly-2022-07-07 to nightly-2022-07-22 regressed nightly: nightly-2022-07-09 searched commits: from to regressed commit:
Interesting, I had assumed based on the matching panic message that it'd have the same regressing commit.
Happy to report that with the latest nightly we're back to green on nightly. Thanks much
Thanks the first fix was enough for Suricata :-)
Thanks so much, pydantic-core has been pinned to but is not back on nightly.
Change:
} } <ins> #[stable(feature = "mpsc_debug", since = "1.7.0")] impl<T> fmt::Debug for SyncSender<T> { fn fmt(&self, f: &mut fmt::Formatter) -> fmt::Result { write!(f, "SyncSender {{ .. }}") } } </ins> //////////////////////////////////////////////////////////////////////////////// // Receiver ////////////////////////////////////////////////////////////////////////////////

Discussion:
All public types should implement Debug. Per conversation on #rust-internals, there might be some useful information that could be printed for these types -- but even just "Sender { .. }" etc. would be a start.
Was this
probably. It has been suggested that way more useful info could actually be printed instead of the opaque placeholders -- but that would be more of a wishlist item than a bug... The patch is sufficient to fix the actual problem I was running into: not being able to #[derive(Debug)] on any structure containing mpsc Senders/Receivers.
Ok, closing.
Change:
<ins> // check-pass // Make sure unused parens lint doesn't emit a false positive. // See https://github.com/rust-lang/rust/issues/71290 for details. #![deny(unused_parens)] fn x() -> u8 { ({ 0 }) + 1 } fn y() -> u8 { ({ 0 } + 1) } pub fn foo(a: bool, b: bool) -> u8 { (if a { 1 } else { 0 } + if b { 1 } else { 0 }) } pub fn bar() -> u8 { // Make sure nested expressions are handled correctly as well ({ 0 } + 1 + 2 + 3 + 4 + 5 + 6 + 7 + 8 + 9) } fn main() {} </ins>

Discussion:
In this example: rustc throws a warning: Removing the parentheses as the message directs causes errors: It seems the warning is wrong, unless this is expected to compile <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: This also happens on nightly. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I think this may apply to any binary op where the left-hand side is an expression that can be a statement without a semicolon, per: For example, adding with block expressions also reports unused parens: but removing those gets an error: As a workaround, it doesn't trigger if the operands are wrapped separately: or
claim