jiebi/CodeConvo huggingface dataset:
Change:
if env::var_os("RUSTC_DENY_WARNINGS").is_some() && env::var_os("RUSTC_EXTERNAL_TOOL").is_none() { <del> // When extending this list, search for `NO-RUSTC-WRAPPER` and add the new lints // there as well, some code doesn't go through this `rustc` wrapper. </del> <ins> // When extending this list, add the new lints to the RUSTFLAGS of the // build_bootstrap function of src/bootstrap/bootstrap.py as well as // some code doesn't go through this `rustc` wrapper. </ins> cmd.arg("-Dwarnings"); cmd.arg("-Drust_2018_idioms"); cmd.arg("-Dunused_lifetimes");

Discussion:
When using 1.38 beta to bootstrap itself, I get:
This is expected and not a supported bootstrapping configuration; if you want to not see these errors you'll want to either bootstrap with N-1 compiler (so, in this case, 1.37) or I believe remove from bootstrap and some other libraries, as well as set deny-warnings in to false. Note that only the 1.37 bootstrap method is officially supported as "guaranteed to work", the deny warnings fix is more of a hack. Closing as won't fix.
Huh? In the past this was always fixed as it's a very common practice for distribution packaging (I don't know of a single packager not doing that). See e.g. or (in which you sort of acknowledged that yourself) deny-warnings is already set to false in , so I guess it somehow doesn't apply to building bootstrap itself.
I hope is an acceptable compromise wrt this. Thanks for pointing out the deny-warnings option which I forgot (since it has been set to false forever for us and never had any effect on the build of bootstrap itself)
Yeah is great; in this case the unsafe block is needed for 1.37 but not on 1.38; if there was an easy way to support both use cases then I'd be happy to accept a PR targeting beta but I'm not personally aware of one -- it looks like we don't seem to have an or similar? We try to support distros and such where possible in this configuration, it's just that this specific case I'm not sure how much we can do. deny-warnings=false is always my recommendation when using a different bootstrap compiler, or manual patches to the code.
Change:
if let Some(ref s) = build.config.ccache { cmd_finder.must_have(s); } <del> warn_old_master_branch(&build.config.git_config(), &build.config.src); </del> }

Discussion:
I am getting this on each invocation now, since very recently: This is in my main checkout, not in a worktree, so I am not quite sure what could even be so unusual about my setup that causes an error here. Cc
A bisect points at That's I am surprised about the date of this PR, I think I would have noticed this earlier if this happened for a month... so probably some other factor is also involved. Cc
It seems to try to read which indeed is not a file that exists here. I also noticed this line in So maybe checking these files is just futile since git doesn't always use a file to track these refs?
I think what happened is that has been run, and that indeed cleans up most of the files from . So the current approach in bootstrap of looking at these files is not reliable. IMO we should instead look at the commit date of the most recent commit in that branch. That also avoids having to directly mess with git's internal files.
yeah, i'm gonna accept defeat on this one. is kinda slow on my device, but only if the relevant files aren't in the i/o cache, and building rust takes a good while anyways.
is not the case anymore since . I am planning to revert and as they are not really required.
Seems like it will still be the case if upstream was configured and too old. But that could be fixed in a much better way (e.g., we could ignore upstream commit and use merge commit in current branch) compare to and
Change:
if let Some(ref s) = build.config.ccache { cmd_finder.must_have(s); } <del> warn_old_master_branch(&build.config.git_config(), &build.config.src); </del> }

Discussion:
I am in this state (only 1 modified file): But I just tried to format and got this: Something is quite wrong here. Formatting of only changed files must be correct, otherwise some files in the tree will get spurious formatting changes in PRs. Perhaps is related? I have a vague memory of seeing this misbehavior occasionally in the past though I'm only now remembering to file an issue.
Don't we check formatting of all files in CI anyway?
Most likely. On CI, yes.
Interesting. I swear I've seen spurious formatting changes in PRs. Might be some other effect.
Should be closed by (GH didn't pick up the comment)
Change:
<ins> // revisions:cfail1 cfail2 // compile-flags: -Z query-dep-graph --crate-type rlib -C linker-plugin-lto -O // no-prefer-dynamic // build-pass #![feature(rustc_attrs)] #![rustc_partition_reused(module = "lto_in_linker", cfg = "cfail2")] pub fn foo() {} </ins>

Discussion:
First compile is ok, after I modify some contents. It failed. I've to . Then works.
I don't know how to setup a minimal env to reproduce this. But I'd love to provide any info you needed.
cc Is this maybe related to ? (Although this sounds like the opposite of that, where it is missing the bit code.)
Some digging shows that this is a preexisting bug in rustc: I believe that this is only showing up now because Cargo is only just now passing
I've posted a fix for this at
Change:
<ins> fn foo1(s: &str) -> impl Iterator<Item = String> + '_ { None.into_iter() .flat_map(move |()| s.chars().map(|c| format!("{}{}", c, s))) //~^ ERROR captured variable cannot escape `FnMut` closure body //~| HELP consider adding 'move' keyword before the nested closure } fn foo2(s: &str) -> impl Sized + '_ { move |()| s.chars().map(|c| format!("{}{}", c, s)) //~^ ERROR lifetime may not live long enough //~| HELP consider adding 'move' keyword before the nested closure } fn main() {} </ins>

Discussion:
Given the following code: The current output is: The actually needed fix here is the following, which should ideally be recommended <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
slightly more minimal:
claim
I came up with a solution of printing an extra line of to give user a recommendation of fixing the error by adding 'move' keyword before the closure parameter of map(). The following is the output for the first testing code. Is this good enough? This is the output from the second testing code ():
Refined the fix with a verbose suggestion of where to add keyword. The output of the first test case is: The output of the second test case is: In addition, the fix will also add the suggestion for nested closure block like this test case: The output of the above test case is:
Change:
<ins> // force-host // no-prefer-dynamic #![crate_type = "proc-macro"] extern crate proc_macro; use proc_macro::TokenStream; #[proc_macro_attribute] pub fn assert_input(args: TokenStream, input: TokenStream) -> TokenStream { assert_eq!(input.to_string(), "trait Alias = Sized ;"); assert!(args.is_empty()); TokenStream::new() } </ins>

Discussion:
I tried this code: I expected the code to compile sucessfully, but got an ICE instead: (This is procedural-macro-related. I can't reproduce without a procedural macro.) This used to work and regressed in . <details<summaryBacktrace</summary<p</p</detailscc
If this code only works on nightly, then I don't think it's a . However, we don't have a label, so ...
This will be fixed by , which handles attributes on expressions in a more systematic way. As a side note, is currently parsed as
Do you want to add to that PR then?
We'll still need to add a regression test.
Assigning P-high as .20on.20nightly.20with.20.60stmt_ex.E2.80.A6) and removing I-prioritize.

I tried this code: and I expected to see this happen: the compiler complained was missing, or on nightly, after adding , compiled successfully, just like . Instead, this happened: the assertion failed. The compiler gave an empty as to the procedural macro: Edit: I found this in the compiler's log: I tried this with: nightly-2020-12-08 () nightly-2020-12-07 () beta () stable () cc
The pretty-print/reparse check has been removed, so this should hopefully be fixed on the latest nightly.
Confirmed that this is fixed in latest nightly, thanks! :heart: Do I need to leave this issue open (possibly for a regression test)?
That sounds like a good idea.
Change:
<ins> struct Foo {} impl Foo { pub fn bar() //~^ ERROR: expected `;`, found `}` //~| ERROR: associated function in `impl` without body } fn main() {} </ins>

Discussion:
Playground with repro . Not present in latest stable or beta. <!-- 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
Regressed since , I think is the cause.
right, this issue can be probably be closed as duplicate of
I would suggest not closing this issue as long as literally starts with the statement referencing back to this issue. Furthermore, this issue is older, so if they’d be duplicates, would be closed.
Change:
fn mut_iter(self) -> MutItems<'a, T>; /// Returns a mutable pointer to the last item in the vector. <del> fn mut_last(self) -> &'a mut T; </del> <ins> fn mut_last(self) -> Option<&'a mut T>; </ins> /// Returns a reversed iterator that allows modifying each value fn mut_rev_iter(self) -> RevMutItems<'a, T>;

Discussion:
changed the , and methods of vectors to return an Option instead of failing on empty vectors. These methods should probably get the same change, to be consistent - - -
I'll try to fix this!
Change:
|           help: missing comma here error: no rules expected the token `e` <del> --> $DIR/missing-comma.rs:19:21 </del> <ins> --> $DIR/missing-comma.rs:23:21 </ins> | LL | macro_rules! foo { | ---------------- when calling this macro

Discussion:
I don't know what to make of this error. () Errors: On stable (1.34) the output is
I'm pretty sure this is fallout from the "missing comma here" suggestion for macros, that evaluates the macro again with the current arguments but adding a comma token in between the argument tokens in different combinations to see if it would be correct. My guess is that that is causing a parse error that doesn't happen for normal things than only have one token in them. We can disable the suggestion when fully qualified paths are involved.
Change:
<ins> error[E0229]: associated type bindings are not allowed here --> $DIR/issue-102467.rs:7:17 | LL |     type A: S<C<X = 0i32> = 34>; |                 ^^^^^^^^ associated type not allowed here error: aborting due to previous error For more information about this error, try `rustc --explain E0229`. </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. --./src/test/ui/associated-consts/issue-- <!-- 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. --: rustdoc ./src/test/ui/associated-consts/issue-- <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
For an unknown reason, it doesn't fail before we're way into the part of rustdoc when calling .
I tried this: <details</detailsBut unfortunately the result still looks bad: Not sure what's going on and why this error appears this late.
Hm, is it worth committing that? :slightlysmilingface: In other examples like we don't get any information at all on what the underlying error is and rustdoc just says I know that there are perhaps 5-10 ices that all have this message and its hard for me to tell if they all have the same cause or are actually due to different underlying issues. :/
I can provide a PR with this change if you want, but I'm not sure it's much of an improvement... Oh well. Pushing a PR and then you'll decide if you want it or not.
This errors correctly on rustdoc now, needs test
I'll add it tomorrow then. Thanks for the heads up!
Change:
``` If your closure requires it, however, Rust will take ownership and move <del> the environment instead: </del> <ins> the environment instead. This doesn’t work: </ins> ```rust,ignore let nums = vec![1, 2, 3];

Discussion:
Right before the "move closures" section, the book doesn't really make it clear that this code would not compile: It shows part of the compile error, but it just looks like a non-error message from the compiler. Consider appending "the error message" to "This gives us".
Change:
<ins> // run-pass // compile-flags: --edition 2018 #![feature(try_blocks)] fn issue_76271() -> Option<i32> { return try { 4 } } fn main() { assert_eq!(issue_76271(), Some(4)); } </ins>

Discussion:
that won't compile but should be a type error: But it gives a parse error instead: (It works if you put parens, like )
Change:
} } <ins> impl<const N: usize> MultiCharEq for [char; N] { #[inline] fn matches(&mut self, c: char) -> bool { self.iter().any(|&m| m == c) } } impl<const N: usize> MultiCharEq for &[char; N] { #[inline] fn matches(&mut self, c: char) -> bool { self.iter().any(|&m| m == c) } } </ins> impl MultiCharEq for &[char] { #[inline] fn matches(&mut self, c: char) -> bool {

Discussion:
Many methods accept patterns of any type that implements the trait. One such type is , which matches any single character mentioned in the pattern slice. However, patterns are not as nice to use as one might hope. This does not compile: Rust complains: The method constrains its argument type with , and Rust won't apply the usual type coercions like to in order to satisfy trait bounds. One must instead write: It's not a tragedy, but it's not pretty either. CC
Shorter version:
cc
Lovely! This hadn't occurred to me.
Yeah, this was a known issue from the start. This concrete impl is basically a originally-nice API that is old enough that it got gradually worse over time in multiple iterations. If I remember right, there was originally a hardcoded method that just took a , and the language still allowed array literals to coerce to static slices, so originally you could do . At some point we got a cleaning up of the expression syntax, which lead to . And then when I proposed the trait the methods got generic, and no longer liked to do deref coercions, leading to the ugly as shortest possible literal form. I think the only real "fix" for this is deprecating this pattern, and/or holding out till we have char array generics and can have a impl for all directly.
Triage: Seems like the same status today; we are making progress on const generics, but it's not ready yet.
Change:
.env("RUSTDOC", builder.rustdoc(self.compiler)) .env("RUSTC", builder.rustc(self.compiler)) .current_dir(path); <ins> // FIXME: implement a `// compile-flags` command or similar //        instead of hard-coding this test if entry.file_name() == "link_to_definition" { cargo.env("RUSTDOCFLAGS", "-Zunstable-options --generate-link-to-definition"); } </ins> builder.run(&mut cargo); } }

Discussion:
Interestingly, the dark theme works fine. Screenshot of Ayu: ! cc
Sending a fix in the next few hours.
Change:
<ins> #![feature(postfix_match)] fn main() { let val = Some(42); val.match { Some(_) => 2, _ => 1 }; Some(2).match { Some(_) => true, None => false }.match { false => "ferris is cute", true => "I turn cats in to petted cats", }.match { _ => (), } } </ins>

Discussion:
As of current nightly, produces this: which is not valid Rust syntax. The correct output would contain . tracking issue:
Change:
<ins> #[no_mangle] pub extern "C" fn my_bar_add(left: i32, right: i32) -> i32 { // Obviously makes no sense but... unsafe { g_free(std::ptr::null_mut()); } left + right } #[link(name = "glib-2.0")] extern "C" { fn g_free(p: *mut ()); } </ins>

Discussion:
This is with Rust 1.69 but was probably always the case. Example: Compiling with prints Similarly when providing nothing changes. I didn't really follow how collects the libraries but I think it's via the query in which claims so this should be included AFAIU. Also the rationale of was to provide all libraries needed to link to the resulting , which is not the case in the above example. CC who originally implemented this feature.
It works as expected if the attribute is used in a dependencies. It seems to me that the function, is forgetting to add the current native libs. Doing something like this correctly adds to the output (even when passed via the command line) but I don't know if it's the right thing to do (cc
Yeah, I think adding is the correct fix. That adds the same information as does for dependencies.
Beware that is rather quirky. Originally Rust printed lines during build with information which link flags need to be to use the static library it builds, and is a blunt way of redirecting these "warnings". I don't know whether omission of is a bug or the old warnings just weren't meant to print them.
I can't imagine it to be a deliberate omission as is the only way to know how to correctly link any arbitrary staticlib afaik.
Change:
}); debug!(?trait_predicate); <del> let elaborated_predicates = elaborate_trait_ref(tcx, trait_ref).filter_map(|obligation| { debug!(?obligation); let pred = obligation.predicate.to_opt_poly_projection_pred()?; Some(pred.map_bound(|p| { ty::ExistentialPredicate::Projection(ty::ExistentialProjection { item_def_id: p.projection_ty.item_def_id, substs: p.projection_ty.substs, term: p.term, }) })) }); </del> <ins> let mut elaborated_predicates: Vec<_> = elaborate_trait_ref(tcx, trait_ref) .filter_map(|obligation| { debug!(?obligation); let pred = obligation.predicate.to_opt_poly_projection_pred()?; Some(pred.map_bound(|p| { ty::ExistentialPredicate::Projection(ty::ExistentialProjection { item_def_id: p.projection_ty.item_def_id, substs: p.projection_ty.substs, term: p.term, }) })) }) .collect(); // NOTE: Since #37965, the existential predicates list has depended on the // list of predicates to be sorted. This is mostly to enforce that the primary // predicate comes first. elaborated_predicates.sort_by(|a, b| a.skip_binder().stable_cmp(tcx, &b.skip_binder())); elaborated_predicates.dedup(); </ins> let existential_predicates = tcx .mk_poly_existential_predicates(iter::once(trait_predicate).chain(elaborated_predicates));

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
searched toolchains through Regression in hmm
what's your system? do you have debug builds on? I can't seem to repro this on master. edit: oops, first question i guess is
no this is not with debug build on, its just the normal master toolchain installed via on x86
Literally can't repro this locally. I'm pretty sure that I know the reason why (the function, which is called from isn't actually returning a sorted list of elaborated predicates). This must be because we're calculating def path hash or something differently between the CI master build and a local build of master.
so you can't even repro with the official master artifacts? :| or just not with a local build?
Sorry, I can repro with the master artifacts. But not with a local build of master, which makes testing the change that I want to make to fix this issue difficult.
Actually, repro on ~stable~ whoops I mean nightly: This should be a UI test that is resilient to def path hashing changes.
Change:
<del> error: expected `;`, found `#` --> $DIR/properly-recover-from-trailing-outer-attribute-in-body.rs:4:47 | LL |     #[cfg(feature = )] |     ------------------ only `;` terminated statements or tail expressions are allowed after this attribute LL |     [1, 2, 3].iter().map().collect::<String>() |                                               ^ expected `;` here LL |     #[attr] |     - unexpected token | help: add `;` here | LL |     [1, 2, 3].iter().map().collect::<String>(); |                                               + help: alternatively, consider surrounding the expression with a block | LL |     { [1, 2, 3].iter().map().collect::<String>() } |     +                                            + error: expected statement after outer attribute --> $DIR/properly-recover-from-trailing-outer-attribute-in-body.rs:5:5 | LL |     #[attr] |     ^^^^^^^ error: aborting due to 2 previous errors </del>

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:
elif path.startswith('.//'): return path else: <del> raise RuntimeError('Non-absolute XPath is not supported due to  the implementation issue.') </del> <ins> raise InvalidCheck('Non-absolute XPath is not supported due to implementation issues') </ins> class CachedFiles(object):

Discussion:
When a doc test fails, the console output looks like this: A traceback should only be shown if there was an error in the python script itself - in this case it should only show the matches error, something like this:
cc me. I'm surely willing to fix that as soon as I get enough spare time.
did you ever get a chance to look at this? (Do you know if the situation has changed?)
No, also I'm not aware of any update. Looks like that I've forgotten this at that time (as flt2dec was being matured); I have virtually no energy to contribute nowadays, so I probably cannot work on this right now.