jiebi/CodeConvo huggingface dataset:
Change:
/// ``` pub fn bar() {} } <ins> attrs_on_struct! { /// ``` /// assert!(true); /// ``` } </ins>

Discussion:
Doctest test names have changed due to . Doc comments that pass through a macro defined in another crate now seem to report a different span. /// assert!(true); /// running with previously looked like this: Now the test names look like this: Frankly, neither are particularly great. It would be nice if the test name used the span from where the macro was invoked, not where it was defined.
I think this also affects normal backtraces :( Just got this rather unuseful backtrace while bootstrapping: full:
cc
What you're describing is entirely in the opposite direction, is the old (and arguably bad) kind of that's impossible to get anymore. I've hidden your comment to focus on the reported issue.
That makes sense, we have a way to get the outermost invocation, that is used by / and : We'd just need to use this in .
cc
cc
Removed label, left nomination for to decide about this issue.
Well, using what suggested seems like the best thing to do.
Change:
<del> // Test that we don't duplicate storage for futures moved around in .await, and // for futures moved into other futures. // // The exact sizes can change by a few bytes (we'd like to know when they do). // What we don't want to see is the wrong multiple of 1024 (the size of BigFut) // being reflected in the size. // // See issue #59123 for a full explanation. // edition:2018 #![feature(async_await)] use std::future::Future; use std::pin::Pin; use std::task::{Context, Poll}; const BIG_FUT_SIZE: usize = 1024; struct BigFut([u8; BIG_FUT_SIZE]); impl BigFut { fn new() -> Self { BigFut([0; BIG_FUT_SIZE]) } } impl Drop for BigFut { fn drop(&mut self) {} } impl Future for BigFut { type Output = (); fn poll(self: Pin<&mut Self>, _ctx: &mut Context<'_>) -> Poll<Self::Output> { Poll::Ready(()) } } #[allow(dead_code)] struct Joiner { a: Option<BigFut>, b: Option<BigFut>, c: Option<BigFut>, } impl Future for Joiner { type Output = (); fn poll(self: Pin<&mut Self>, _ctx: &mut Context<'_>) -> Poll<Self::Output> { Poll::Ready(()) } } fn noop() {} async fn single() { let x = BigFut::new(); x.await; } async fn single_with_noop() { let x = BigFut::new(); noop(); x.await; } async fn joined() { let a = BigFut::new(); let b = BigFut::new(); let c = BigFut::new(); let joiner = Joiner { a: Some(a), b: Some(b), c: Some(c), }; joiner.await } async fn joined_with_noop() { let a = BigFut::new(); let b = BigFut::new(); let c = BigFut::new(); let joiner = Joiner { a: Some(a), b: Some(b), c: Some(c), }; noop(); joiner.await } fn main() { assert_eq!(1028, std::mem::size_of_val(&single())); assert_eq!(1032, std::mem::size_of_val(&single_with_noop())); assert_eq!(3084, std::mem::size_of_val(&joined())); assert_eq!(3084, std::mem::size_of_val(&joined_with_noop())); } </del>

Discussion:
E.g. in and cc
I'd like to work on this :smile:
You've got it :)
Change:
fn main() { let irr = Irrefutable(0); while let Irrefutable(x) = irr { //~ ERROR E0165 <ins> //~| irrefutable pattern </ins> // ... } }

Discussion:
From: src/test/compile- Error E0184 needs a span_label, updating it from: To: Bonus: I'm not sure that note is helping, you can probably just remove it.
On it
- I am releasing this one so someone else can take it, but feel free to come grab another one

From: src/test/compile- Error E0165 needs a span_label, updating it from: To:

From: src/test/compile- Error E0164 needs a span_label, updating it from: To:
Change:
(Res::Def(DefKind::Ctor(_, CtorKind::Fictive), _), _) if ns == ValueNS => { bad_struct_syntax_suggestion(); } <ins> (Res::Def(DefKind::Ctor(_, CtorKind::Fn), _), _) if ns == ValueNS => { err.span_label( span, format!("did you mean `{} ( /* fields */ )`?", path_str), ); } </ins> (Res::SelfTy(..), _) if ns == ValueNS => { err.span_label(span, fallback_label); err.note("can't use `Self` as a constructor, you must use the implemented struct");

Discussion:
Code Example (): <img width="805" alt="image" src="https://user-"Currently we provide a "do you mean..." for the but not for the . We probably should provide one for both.
Consider fixing Btw (which is a similar enhancement)
I'd like to work on this if it is still available.
go ahead! Ideally, you could turn the output into but just changing the tuple case would be enough.
I created a PR, could you please help review. I took a look at your suggestion of updating all the errors to , that seemed too many changes, not sure if it was necessary, so I just the tuple case.
Change:
} } #[rustc_lint_diagnostics] <del> fn highlighted_note(&mut self, msg: Vec<StringPart>) -> &mut Self { </del> <ins> pub fn highlighted_note(&mut self, msg: Vec<StringPart>) -> &mut Self { </ins> self.sub_with_highlights(Level::Note, msg, MultiSpan::new()); self }

Discussion:
Here it's obvious, but when the error says that it is mismatched with and that "types differ in mutability" then I have zero chance of figuring what's going on. No response No response <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
claim Sounds like a feature I would like to use as well.
Change:
<del> // The ayu theme has a different color for the "<code>" tags in the doc blocks. We need to // check that the rule isn't applied on other "<code>" elements. goto: file://|DOC_PATH|/test_docs/enum.AnEnum.html // We need to show the text, otherwise the colors aren't "computed" by the web browser. show-text: true // We set the theme to ayu. local-storage: {"rustdoc-theme": "ayu", "rustdoc-preferred-dark-theme": "ayu", "rustdoc-use-system-theme": "false"} // We reload to get the text appearing and the theme applied. reload: assert-css: (".docblock code", {"color": "rgb(255, 180, 84)"}, ALL) // It includes variants and the "titles" as well (for example: "impl RefUnwindSafe for AnEnum"). assert-css: ("div:not(.docblock) > code", {"color": "rgb(197, 197, 197)"}, ALL) </del>

Discussion:
My guess is that the yellow inline code style is incorrectly being applied to code blocks too. ! !
cc since you're knowledgeable about rustdoc's CSS
I'll send a fix shortly.
looks to be the likely cause. searched nightlies: from nightly-2021-07-01 to nightly-2021-08-25 regressed nightly: nightly-2021-08-20 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.0</summaryHost triple: x86_64-apple-darwin Reproduce with: </details
Change:
.reqopt("", "rustc-path", "path to rustc to use for compiling", "PATH") .optopt("", "rustdoc-path", "path to rustdoc to use for compiling", "PATH") .optopt("", "rust-demangler-path", "path to rust-demangler to use in tests", "PATH") <del> .reqopt("", "lldb-python", "path to python to use for doc tests", "PATH") .reqopt("", "docck-python", "path to python to use for doc tests", "PATH") </del> <ins> .reqopt("", "python", "path to python to use for doc tests", "PATH") </ins> .optopt("", "jsondocck-path", "path to jsondocck to use for doc tests", "PATH") .optopt("", "valgrind-path", "path to Valgrind executable for Valgrind tests", "PROGRAM") .optflag("", "force-valgrind", "fail if Valgrind tests cannot be run under Valgrind")

Discussion:
Compiletest currently has two different arguments telling it which python to use. Since , both are always the same. We should change it to just one argument to simplify things. Mentoring instructions: Change to be a single argument, then change to use the updated arguments. are you interested in tackling this one too? :) label +A-rustbuild +A-testsuite +E-easy +E-mentor Originally posted by in <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
claim
Change:
fn m2(&self, x: &T5<X>); } <del> // The last field in a struct or variant may be unsized </del> <ins> // The last field in a struct may be unsized </ins> struct S2<X: ?Sized> { f: X, }

Discussion:
Backtrace: This seems to occur when using a non-struct type that contains an unsized type. This is probably because  only handles and the base unsized types. This should be extended to handle enums and tuples as well.
This is still happening. Does this mean we should avoid using DSTs for complex custom types for now?
Visiting for triage This is still an issue:
ICE also happens with a tupled trait object:
I've seen this too with: Reproducer: Version: Backtrace:
No longer reproduces but the other tests do.
cc
Is this the same as or related to ?
leads to . As mentioned inline, using the correct type works (). I'm using the Ubuntu PPA "rust-nightly", version ~~vivid.
Does not compile for other reasons that the ICE anymore. I've adjusted to the following and could not reproduce it anymore.
Another example hitting this same ICE:
Bugs similar to this one have been reported numerous times (most of the references to this issue are duplicates). Although it would be nice for reporters to search for similar issues before filing a new one, it's hard to blame them, since the ICE message from rustc tells people to file an issue. This issue itself was opened over two years ago. Separate from fixing the underlying problem, we should at least investigate displaying a real error instead of an ICE.
Change:
/// assert_eq!(&[1, 2, 3], &shared[..]); /// ``` #[inline] <del> fn from(v: Vec<T>) -> Arc<[T]> { match Arc::try_from_vec_in_place(v) { Ok(rc) => rc, Err(mut v) => { unsafe { let rc = Arc::copy_from_slice(&v); // Allow the Vec to free its memory, but not destroy its contents v.set_len(0); rc } } </del> <ins> fn from(mut v: Vec<T>) -> Arc<[T]> { unsafe { let rc = Arc::copy_from_slice(&v); // Allow the Vec to free its memory, but not destroy its contents v.set_len(0); rc </ins> } } }

Discussion:
Miri reports UB in the new test: On first sight, the error seems legitimate. That test got in Cc
Probably what happens is that in Miri, will always move the data to a new location, and then the way the test checks whether that happened causes UB. You should not call unless you are already 100% sure that both pointer point to the same allocation -- and in this case, you cannot be sure of that, since allocators do not promise that keeps the same allocation. In fact, it might be the case that even if keeps the data in-place, the allocation has a new provenance -- it is considered a new allocation at the same location, but all old pointers are invalid now and must be 'refreshed'. So this code probably has UB even if keeps the allocation in-place. I recall this was discussed somewhere at some point, and I think the C standard contains wording along these lines, but I forgot the details... Cc The fix is easy -- just do and later compare that with . The test will still fail in Miri though, and in other allocators that do not shrink in-place.
Yeah, the C standard is quite explicit about this, so for now we should follow suit. Opened
Might it be a good idea to the pointer comparison itself, so that Miri can check the actual implementation, even if it can't check the final assertion. I did suspect that other platforms might not have this behaviour - seems to show this. It might be best to feature gate the test and opt to only platforms with allocators that work like this.
Yes, but to be clear there are two bugs here: the test can fail in some platforms, such as Miri, when realloc doesn't shrink in-place the test has UB on all platforms because the two pointers are into different allocations (realloc conceptually creates a new allocation, even if it remains in-place), but is explicitly documented to only work on pointers within the same allocation
Is the comparison still UB? I'm currently working on a patch that Uses the cast for comparison Turns off this feature for non-GNU targets (since that's the only one I know for sure has the shrink-in-place behaviour) Disables the test on non GNU, and the comparison itself on Miri With that in mnd though, I'm wondering if this opt should just be removed entirely.

The perf wins I got in testing were pretty small for the amount of maintenance headache this seems likely to cause
returns regular integers, you can compare them in whatever way you want.
Change:
<ins> error: expected `;`, found `#` --> $DIR/properly-recover-from-trailing-outer-attribute-in-body-2.rs:6:13 | LL |         #[cfg()] |         -------- only `;` terminated statements or tail expressions are allowed after this attribute LL |         $foo |             ^ expected `;` here LL | LL |         #[cfg(bar)] |         - unexpected token ... LL |     the_macro!( (); (); ); |     --------------------- in this macro invocation | = note: this error originates in the macro `the_macro` (in Nightly builds, run with -Z macro-backtrace for more info) help: add `;` here | LL |         $foo; |             + help: alternatively, consider surrounding the expression with a block | LL |     the_macro!( { () }; (); ); |                 +    + error: aborting due to 1 previous error </ins>

Discussion:
<!-- [31mICE[0m: Rustc '--crate-type=lib -ooutputfile -Zdump-mir-dir=dir' 'error: internal compiler error: not a tail expression', 'error: internal compiler error: not a tail expression' 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: --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
It seems the pops up since cc The code starts ICEing in general since cc
claim
Change:
<ins> error: expected type, found `0` --> $DIR/issue-66270-pat-struct-parser-recovery.rs:4:22 | LL |     incorrect_field: 0, |                      ^ expected type error: aborting due to previous error </ins>

Discussion:
This code (): results in an ICE:
Isn't that a close cousin of
Not really, this is an associated function rather than an inner function.
I'm investigating this. Still repros on . With : <details<summaryBacktrace </summary</details
After investigating, the current ICE is caused by the () inside of not being able to locate the generic parameter it is trying to substitute for. The code at fault is: Which should try and find based on the (), but the current code only handles the situation like .
No longer ICEs, I believe down to Looking at the backtrace on nightly-2019-12-05 this seems related to and also
This no longer ICEs OR errors, at least for me. What backtrace do you mean? AFAICT this can be closed.
Whoops, wrote the wrong date down. I meant the nightly when it did ICE, it was 2019-12-01 or thereabouts. Yeah it can be closed once there's a regression test
Change:
<ins> error: expected type, found `0` --> $DIR/issue-66270-pat-struct-parser-recovery.rs:4:22 | LL |     incorrect_field: 0, |                      ^ expected type error: aborting due to previous error </ins>

Discussion:
paniked when I tried to use GAT, I didn't know does not support it then. Anyway I think it is not supposed to panic. I have confirmed with version 1.39 on Windows, my PC version 1.36 on Linux. It said,
Seems a duplicate of , I did not noticed it when I was opening this issue, sorry. There is also a small difference that I did not turn on
cc &
This should be fixed in the next nightly

This is a toy example I made in order to later make tests which run for with . This is the error I get: Error notes: - compiler flags: I don't know if this kind of pattern is intended as part of the feature or in its future, but if not, I think it can be satisfied by using a procedural macro so that's probably alright. The point of the pattern, as I mentioned at the beginning of the post, is to be able to test a particular generic type's implementation up to an arbitrary range of numeric constants. While implementing another project to help test the feature, I stumbled upon the problem of wanting to test hundreds of different constants, but having no way of doing so with say, a loop over a range of constants. This is one way I thought of making it work. Am I making the right decisions here? How should I go about testing hundreds of constants? Thanks :)
Note: another example that also panics. I know, yes, expressions aren't yet supported as const parameters. But it has the same panic, which is WEIRD! When I wrote this one, I thought "okay maybe inside a statement, the compiler won't try things like because the case when is is already covered... and with exhaustiveness check it should know that N = 0 won't enter the second branch". But I must be wrong there, or otherwise how did it panic? Error:
Minified: I'm pretty sure that I saw this ICE before, but I can't find it ;/
This is just a result of having an expression () as a const generic argument. I don't actually think there's a canonical issue, though many of the issues are essentially the same. is the best tracking issue.
No longer ICEs on the latest nightly
Oh, the new output is interesting. It probably needs to be monomorphized so that the compiler detects the infinite recursion. And then we could also write one that doesn't have infinite recursion :3 In order to force an error, a test function should suffice right?
What do you mean?
I mean that I imagined it might detect that the function recurses infinitely onto itself. But I guess it reads it lazily, and lets monomorphization do the job of recursing the function? which would make a lot of sense to me.
Change:
cargo.arg("--features").arg(features.join(", ")); } <ins> // Warning: be very careful with RUSTFLAGS or command-line options, as conditionally applied // RUSTFLAGS or cli flags can lead to hard-to-diagnose rebuilds due to flag differences, causing // previous tool build artifacts to get invalidated. </ins> // Enable internal lints for clippy and rustdoc // NOTE: this doesn't enable lints for any other tools unless they explicitly add `#![warn(rustc::internal)]` // See https://github.com/rust-lang/rust/pull/80573#issuecomment-754010776

Discussion:
After I noticed that whenever I modify tests (on Windows), stage 1 cargo gets unnecessary rebuilt which also triggers rebuilds for other tools like stage 0 rustdoc. I'm pretty sure something in my implementation is wrong w.r.t. to properly caching, but I didn't invest time in figuring out why yet, hence opening this bug to track it. The build sequence is something like stage 0 std -stage 1 rustc -stage 1 std -stage 1 tool cargo -stage 0 compiletest / run-make-support / rustdoc. Example repro steps: Run -make sure stage 1 cargo is already built. Modify a test. Observe that stage 1 cargo gets rebuilt even though I didn't modify it.
EDIT: oh, is it because in run-make-support or rustdoc we use or something that is a different staged cargo compared to the one we built with stage 1 rustc...
Actually unassigning because I don't know how to cleanly fix this just yet. EDIT: opened thread https://rust-
Running twice is enough to reproduce cargo rebuild issue. Probably some rustflags invalidating the build cache.
Reopening because we need to revert in favor of a different approach.
Change:
pub fn target() -> Target { let mut base = super::apple_base::opts(); <ins> base.cpu = "x86-64".to_string(); </ins> base.eliminate_frame_pointer = false; base.pre_link_args.push("-m64".to_string());

Discussion:
By default, we use the "generic" target CPU, unfortunately on x8664, this disables various features because "generic" is more like "generic x86". This disable things like some SSE usage and multibyte nops. On x8664 we should use as the minimum target cpu, not sure about other archs. To present some arbitrary numbers: cc
To add some slightly more interesting numbers, these are for : generic: x86-64
Did your PR not resolve this?
It probably did for x84_64, but I'm not sure about x86 (I guess "generic" is like i386, which seems a bit too old a target), ARM, etc. Am 21.01.2015 23:33 schrieb "Alexis Beingessner"
Change:
LL | #[derive(Copy="bad")] |              ^ expected one of `)`, `,`, or `::` here <del> warning: empty trait list in `derive` --> $DIR/malformed-derive-entry.rs:7:1 | LL | #[derive()] | ^^^^^^^^^^^ </del> error: malformed `derive` attribute input <del> --> $DIR/malformed-derive-entry.rs:10:1 </del> <ins> --> $DIR/malformed-derive-entry.rs:7:1 </ins> | LL | #[derive] | ^^^^^^^^^ help: missing traits to be derived: `#[derive(Trait1, Trait2, ...)]`

Discussion:
The following code emits an unsquelchable warning. This warning should be a part of .
empty trait list in should have a lint name ... and that name is .
Does not appear to squelch the warning for me...
It seems eminently reasonable to me to include in since it is an attribute applied with no effect; so let's kick off fcp for that. merge
Team member has proposed to merge this. The next step is review by the rest of the tagged teams: [x] [x] [x] [x] [x] [ ] [x] [x] [x] [ ] No concerns currently listed. Once a majority of reviewers approve (and none object), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See for info about what commands tagged team members can give me.
Implementing this as part of the existing would be complicated by , but it might also be possible to implement where the existing "empty trait list" warning is issued (possibly as a ).
I need to make a buffered early lint for the same thing with .
Seems reasonable. And a macro that might end up with an empty derive list should have no problem turning off locally.
reviewed I certainly agree with moving warnings to lints.
:bell: This is now entering its final comment period, as per the . :bell:
The final comment period, with a disposition to merge, as per the , is now complete.
Change:
| LL | fn thing(x: impl FnOnce(&u32)) {} |                  ^^^^^^^^^^^^ <ins> help: consider specifying the type of the closure parameters | LL |     let f = |_: &_| (); |             ~~~~~~~ </ins> error: implementation of `FnOnce` is not general enough --> $DIR/issue-79187.rs:5:5

Discussion:
a new project with (in my case, it used pathfinding version 4.0.0 or 4.0.1) with: produces the following output: For the two closures ( and ), if I add a type for the parameter by changing to , it builds without any errors. If it had told me that it needed type annotations, I would have understood the problem and been able to fix it right away. (I assumed that there was enough type information for it to infer the correct types.) The first confusing bit is that both errors highlight the entire call to , including all parameters. This makes it harder to figure out which one it is complaining about (though the second note contains the line number). Does the first argument have something to do with the lifetimes it is complaining about? I found this part of the message hard to understand: The type parameters look almost identical, and the didn't make sense to me. Could it somehow indicate the bounds of that lifetime (2), or better explain why that lifetime doesn't last long enough? FYI: found as part of solving Advent of Code 2022, Day 12. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
A smaller MCVE:
I'm thinking whether we should fix this as a compiler bug (i.e., make it compile) or suggesting people write explicit type here
maybe related:
Also if we move the closure to the parameter: This will also compile. Combined with , I guess something is wrong with propagating lifetime of closures when we store it in a variable...
claim