jiebi/CodeConvo huggingface dataset:
Change:
<ins> // Copyright 2018 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. // When the type of a method call's receiver is unknown, the span should point // to the receiver (and not the entire call, as was previously the case before // the fix of which this tests). fn shines_a_beacon_through_the_darkness() { let x: Option<_> = None; x.unwrap().method_that_could_exist_on_some_type(); //~^ ERROR 17:5: 17:15: the type of this value must be known in this context } fn courier_to_des_moines_and_points_west(data: &[u32]) -> String { data.iter() //~ ERROR 22:5: 23:20: the type of this value must be known in this context .sum::<_>() .to_string() } fn main() {} </ins>

Discussion:
E.g., the expression with unknown type is the variable use , but the error highlight covers the entire sub-expression of . I assume this is due to us doing something sub-optimal with the spans here in the HIR lowering.
is worried that similar issues are arising with other desugarings, i.e. that this might be an across-the-board regression. Worth investigating.
: gives
triage: P-medium Doesn't seem like a "stop everything" sort of problem, but would be good to figure it out. However, it does not appear to be a regression: e.g., the above test case behaves the same in 1.16.0 as well.
Change:
self.unclosed_delims.extend(snapshot.unclosed_delims.clone()); } <ins> pub fn unclosed_delims(&self) -> &[UnmatchedBrace] { &self.unclosed_delims } </ins> /// Create a snapshot of the `Parser`. pub(super) fn create_snapshot_for_diagnostic(&self) -> SnapshotParser<'a> { let mut snapshot = self.clone();

Discussion:
With following doctest, where the cfg attribute spans multiple lines, the final program is invalid: the wrapping method doesn't take into account the dangling line that closes the attribute. rust /// # #![cfgattr(not(dox), feature(cfgtargetfeature, targetfeature, /// # stdsimd))] /// /// fn foo() { /// let mut dst = [0]; /// addquickly(&[1], &[2], &mut dst); /// asserteq!(dst[0], 3); /// } ///
cc
cc
I don't see a message associated with the stack trace, is that missing?
The problem lies in how rustdoc parses doctests. It scans lines for crate-level attributes and statements, but it doesn't do anything more intelligent than checking the beginning of each line: We recently changed the parsing for and detection to use the libsyntax parser, but this initial scan is still a string-based search. The way to fix the test in the OP is to actually remove the part of it - rustdoc doesn't pass on any information into doctest compilation, so those features are going to be enabled regardless.
This is the associated message:
Change:
let mut tarball = Tarball::new(builder, "clippy", &target.triple); tarball.set_overlay(OverlayKind::Clippy); <ins> tarball.is_preview(true); </ins> tarball.add_file(clippy, "bin", 0o755); tarball.add_file(cargoclippy, "bin", 0o755); tarball.add_legal_and_readme_to("share/doc/clippy");

Discussion:
It should not be possible that clippy component is missing since we are gating on it in CI..? cc
I think this is a rustup bug somehow, it's looking specifically for : I can back this out to give rustup time to fix it in a new release, this wasn't an urgent fix. I want to spend another few minutes investigating first though.
I don't think rustup's rename system is designed to allow changing the name of a component. contains more information about how and why this was done.
says I need at a minimum to keep the key for clippy-preview. I will try to test that out today but I don't have permissions for a dist-static build and it might take me a bit so I'll put up a revert in the meantime.
I'm happy to run dev-static builds as needed, but I agree that a revert is appropriate for the time being. Please feel free to poke on Zulip if you need a quick review, etc. I'm a little surprised our testing in didn't catch this -- let's make sure we understand how to test it in the future.
what went wrong in is that worked before and after, but running before and after did not. I'll make sure to test that in any future PR.
Change:
`i686-uwp-windows-msvc` | ? |  | [^x86_32-floats-return-ABI] [`i686-win7-windows-msvc`](platform-support/win7-windows-msvc.md) | ✓ |   | 32-bit Windows 7 support [^x86_32-floats-return-ABI] `i686-wrs-vxworks` | ? |  | [^x86_32-floats-return-ABI] <ins> [`loongarch64-unknown-linux-musl`](platform-support/loongarch-linux.md) | ? |  | LoongArch64 Linux (LP64D ABI) with musl 1.2.3 </ins> [`m68k-unknown-linux-gnu`](platform-support/m68k-unknown-linux-gnu.md) | ? |  | Motorola 680x0 Linux `mips-unknown-linux-gnu` | ✓ | ✓ | MIPS Linux (kernel 4.4, glibc 2.23) `mips-unknown-linux-musl` | ✓ |  | MIPS Linux with musl 1.2.3

Discussion:
The output is miles of errors like this: I think this target has somehow slipped past our CI? Maybe I'm searching our codebase wrong, but I don't think I can find any tests for it? Note that this affects the target specifically, as identified by the Miri cron job that tries to build all tier 2 targets: which just failed: cc target maintainers:
I'm sorry. The is incorrectly written in the Tier 2 table in .
Change:
<ins> // Copyright 2014 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. enum Foo { A = 1i64, //~^ ERROR mismatched types: expected `int` but found `i64` B = 2u8 //~^ ERROR mismatched types: expected `int` but found `u8` } fn main() {} </ins>

Discussion:
Code sample: Backtrace and debug log:
Similar code without the feature does not cause a compiler error:
A smaller test case:
Neither of the test cases are ICEing for me today, I'm seeing the following:
Flagging as needstest

The error message doesn't say that the problem is mismatching mutability.
Looks like this can be closed, this is now: Edit: though now the complaint might be that it doesn't single out 'other'
Flagging as needstest (just in case a test doesn't already exist)
Change:
// This prevents programs (including rustc) from attempting to read a partial archive. // It also enables writing an archive with the same filename as a dependency on Windows as // required by a test. <del> let mut archive_tmpfile = TempFileBuilder::new() </del> <ins> // The tempfile crate currently uses 0o600 as mode for the temporary files and directories // it creates. We need it to be the default mode for back compat reasons however. (See // #107495) To handle this we are telling tempfile to create a temporary directory instead // and then inside this directory create a file using File::create. let archive_tmpdir = TempFileBuilder::new() </ins> .suffix(".temp-archive") <del> .tempfile_in(output.parent().unwrap_or_else(|| Path::new(""))) .map_err(|err| io_error_context("couldn't create a temp file", err))?; </del> <ins> .tempdir_in(output.parent().unwrap_or_else(|| Path::new(""))) .map_err(|err| { io_error_context("couldn't create a directory for the temp file", err) })?; let archive_tmpfile_path = archive_tmpdir.path().join("tmp.a"); let mut archive_tmpfile = File::create_new(&archive_tmpfile_path) .map_err(|err| io_error_context("couldn't create the temp file", err))?; </ins> <del> write_archive_to_stream(archive_tmpfile.as_file_mut(), &entries, archive_kind, false)?; </del> <ins> write_archive_to_stream(&mut archive_tmpfile, &entries, archive_kind, false)?; </ins> let any_entries = !entries.is_empty(); drop(entries);

Discussion:
Given this code: I get this output from rustc: The most recent archive no longer has the "read" permission bit set for group/world owners. This ended up breaking because our files are built in a container with a different user and aren't then readable outside of the container. There's no particular reason we do this and we can work around this, but I also suspected that the change in permissions here probably wasn't intentional. I think this is due to (cc specifically . I haven't dug too deeply but my guess is that temp files specifically turn off other permission bits
reverted back to the LLVM archive writer to fix another regression. Still I think this issuw should be kept open as a reminder to fix the new archive writer before it becomes the default again.
cc , which also needs to be fixed before relanding the archive writer change. BTW is there a tracking issue for that somewhere? I see the original PR linked to , but it hasn't been reopened.
I have kept all issues that need to be fixed before it can land again in my github notifications. There is currently no tracking issue, but feel free to open one. It did probably be a good idea to ensure no issue is forgotten about.
Change:
} } <del> pub fn expand_expr(&mut self, mut e: Gc<ast::Expr>) -> Gc<ast::Expr> { loop { match e.node { ast::ExprMac(..) => { let mut expander = expand::MacroExpander { cx: self, }; e = expand::expand_expr(e, &mut expander); } _ => return e } } </del> <ins> #[deprecated = "Replaced with `expander().fold_expr()`"] pub fn expand_expr(&mut self, e: Gc<ast::Expr>) -> Gc<ast::Expr> { self.expander().fold_expr(e) } /// Returns a `Folder` for deeply expanding all macros in a AST node. pub fn expander<'b>(&'b mut self) -> expand::MacroExpander<'b, 'a> { expand::MacroExpander { cx: self } </ins> } pub fn new_parser_from_tts(&self, tts: &[ast::TokenTree])

Discussion:
I believe this should output the string : But I get this error: Rust version:
Note that standard recursive macros work fine, e.g., And outputs . Maybe the bug here is that expanding macros within other macros is using an older environment that doesn't include the name ?
It's even worse than that. only uses the compiler built-in macros:
I think this might be a dupe of
Does fixing mean that also gets fixed? I wouldn't assume so, but it might be possible depending on the implementation. (Sorry I missed that issue. I searched for 'recursive macro' instead of 'nested macro'!)
both and use , which doesn't work with non-builtin macros.
Right. I'm referring to the recursive aspect. Wasn't sure if that would make a difference. (I just don't know enough about how macros are expanded to know. Pure guesswork on my part.)
Change:
``` It is advisable to find out what the unhandled cases are and check for them, <del> returning an appropriate value or panicking if necessary. </del> <ins> returning an appropriate value or panicking if necessary. Check if you need to remove a semicolon from the last expression, like in this case: ```ignore fn foo(x: u8) -> u8 { inner(2*x + 1); } ``` The semicolon discards the return value of `inner`, instead of returning it from `foo`. </ins> "##, E0270: r##"

Discussion:
If I take the following line from the Rust book and make a function out of it Meaning something like Then the compiler fails with However if I add the return statement, which should be optional. It works Shouldn't this be considered an expression by the compiler?
The crucial thing here is the semicolon after your statement. A block consists of a bunch of statements, terminated with semicolons, possibly followed by an expression, which is not terminated by a semicolon. Therefore, putting the semicolon after made the compiler view the expression as a statement, with no terminating expression on the block. If you leave off the semicolon, it should work: Note the lack of a semicolon. I hope that helps! This bug might still be useful as a documentation bug - the long explaination for does not mention this pitfall, while it seems like a common case that should be addressed.
There's usually a suggestion printed telling you to remove the trailing semicolon. It only works when the type of the last statement-expression is the same as the function return type, which isn't known in this case since the return type of is inferred. cc , which attempted to fix this
I see, still getting the hang of when semicolons are required. But maybe a clearer error message is required.
I updated the title to make it accurately reflect the issue. The compiler never considers the line to be unreachable either way, it just says that not all control paths return a value. Which is true, none of the 1 control paths return a value.
Change:
_ => panic!("Expected the const item as a pattern to match.") } } <ins> #[test] fn test_from_nonzero() { let nz = NonZeroU32::new(1).unwrap(); let num: u32 = nz.into(); assert_eq!(num, 1u32); } </ins>

Discussion:
I'd really expect this to just work: All types should implement , as this conversion is always possible and free.
Change:
/// `ManuallyDrop` to control drop order (needs to be dropped after all the nodes). pub(super) alloc: ManuallyDrop<A>, // For dropck; the `Box` avoids making the `Unpin` impl more strict than before <del> _marker: PhantomData<crate::boxed::Box<(K, V)>>, </del> <ins> _marker: PhantomData<crate::boxed::Box<(K, V), A>>, </ins> } #[stable(feature = "btree_drop", since = "1.7.0")]

Discussion:
I'm referring to this particular line Even though in environments Global as a structure exists and is defined, and it only shows up in PhantomData, the use of the structure is most likely undefined if attribute is never used. Yes, there will be no calls to Global as it's only a phantom, and execution will not be affected, but just seems ill-defined at least. For completeness: compilation of code that uses with custom allocator under is not affected, and there is no sign of runtime bugs.
Does this matter? It holds it directly:
My issue is the opposite - it should be in the PhantomData too, but not implicit
I understand, but it already includes for dropck, so why should it include it in the too?
To avoid inclusion of Global that has no logical relation to the BTreeMap instance with custom allocator
If it's accepted as a bug I can quickly fix it, at least it passes tests
Change:
.filter(|i| i.inner_impl().trait_.is_some()) .find(|i| i.inner_impl().trait_.def_id_full(cx.cache()) == c.deref_trait_did) { <del> if let Some(type_did) = impl_.inner_impl().for_.def_id_full(cx.cache()) { // `impl Deref<Target = S> for S` if target_did == type_did { // Avoid infinite cycles return; } } </del> sidebar_deref_methods(cx, out, target_deref_impl, target_impls); } }

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. --Original: Minimized: <!-- 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 --
When running with , the last few lines before the panic are: seems relevant since it has a impl:
Minimized: rust pub struct Generic<T(T); impl<'astd::ops::Deref for Generic<&'a mut (){ type Target = Generic<&'a (); fn deref(&self) -&Self::Target { unimplemented!() } } impl<'aGeneric<&'a (){ pub fn some_method(&self) {} }
searched nightlies: from nightly-2020-11-12 to nightly-2021-01-17 regressed nightly: nightly-2021-01-09 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: </detailsRegressed in . label regression-from-stable-to-nightly
cc - do you have time to figure out what's going wrong here?
Yes, I believe so, I'll see what I can do here. claim
Please ping me once you open the PR ( is taking a break :) )
The core issue is the recursion cycle handling... It focuses only on s and wasn't anticipating targets that differ only in generic type args. I believe I see the tweak we'll need here, so I should have a PR in the next day or so.
Change:
// all span information. // // As a result, some AST nodes are annotated with the token <del> // stream they came from. Attempt to extract these lossless // token streams before we fall back to the stringification. </del> <ins> // stream they came from. Here we attempt to extract these // lossless token streams before we fall back to the // stringification. // // During early phases of the compiler, though, the AST could // get modified directly (e.g. attributes added or removed) and // the internal cache of tokens my not be invalidated or // updated. Consequently if the "lossless" token stream // disagrees with our actuall stringification (which has // historically been much more battle-tested) then we go with // the lossy stream anyway (losing span information). </ins> let mut tokens = None; match nt.0 {

Discussion:
I ran across a very curious case today... Given this procedural macro: and this expansion: when compiled I get: which is quite curious! -- er, just wrong thinking here cc cc cc
Seems similar to how also causes an inconsistency.
Ok I think I see what's going on here. This has to do with introduced in Basically I think this boils down to , we fundamentally cannot losslessly tokenize an AST item into a list of tokens to hand to a procedural macro. What's happening here is that all the tokens of the are saved off in the parser. This is the original source token stream which produced the struct. Later on when we tokenize the struct to hand off to a procedural macro we will use this cached token stream, if available, and tokenize it out and return it. When stringifying, however, we use the actual AST node itself (the source of truth). The bug is that cfg processing does indeed happen before the procedural macro runs. The cfg processing is modifying the AST item's internal fields but it's not invalidating the cached token stream or modifying it. Hence when the procedural macro runs the cached token stream is invalid wrt the internal state of the AST node, causing two different results to come out depending on how you look at it. Possible solutions here are: the cached list of tokens if the AST node is modified. This seems tricky to get right, are there other locations where a modification can happen? implemented , but holy cow that's a lot of work. the two results of tokenization (stringify + parse and the tokens themselves) and return the string one if they differ. None of them seem like great solutions :(
Change:
use rustc_middle::ty::layout::{LayoutCx, LayoutOf, TyAndLayout}; use rustc_middle::ty::{self, ScalarInt, Ty, TyCtxt}; use rustc_span::DUMMY_SP; <del> use rustc_target::abi::VariantIdx; </del> <ins> use rustc_target::abi::{Abi, VariantIdx}; </ins> #[instrument(skip(ecx), level = "debug")] fn branches<'tcx>(

Discussion:
<!-- [31mICE[0m: Rustc '' 'error: internal compiler error: Got a scalar pair where a scalar was expected', 'error: internal compiler error: Got a scalar pair where a scalar was expected' File: --code: 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
Regression in nightly-2023-11-09 ping
Good catch, thanks! should fix this.
Change:
<ins> // run-fail // check-run-results // exec-env:RUST_BACKTRACE=0 // Test that we format the panic message only once. // Regression test for https://github.com/rust-lang/rust/issues/110717 use std::fmt; struct PrintOnFmt; impl fmt::Display for PrintOnFmt { fn fmt(&self, f: &mut fmt::Formatter<'_>) -> fmt::Result { eprintln!("fmt"); f.write_str("PrintOnFmt") } } fn main() { panic!("{}", PrintOnFmt) } </ins>

Discussion:
I tried this code: I expected to see this happen: No panic during runtime Instead, this happened: Panicked during runtime <details<summaryFormat: was already formatted once</summary</details<!-- Provide the most recent version this worked on, for example: It most recently worked on: Rust 1.47 --It most recently worked on: Rust 1.70 (beta) and Rust 1.69 (stable) <!-- Provide the version you are using that has the regression. --: None I also reported this here , but I think this one is on . assigning you, because I suspect this has something to do with recent changes.
I'll look into this tomorrow. Can you check if it also happens with -Zflatten-format-args=no?
This is unrelated to and was caused by a recent change to the panic runtime. I've posted a fix at
Change:
retained: &mut retained, access_levels: &cx.cache.access_levels, update_retained: true, <del> is_json_output: cx.output_format.is_json() && !cx.show_coverage, </del> <ins> is_json_output, </ins> }; krate = ImportStripper.fold_crate(stripper.fold_crate(krate)); } // strip all impls referencing private items <del> let mut stripper = ImplStripper { retained: &retained, cache: &cx.cache }; </del> <ins> let mut stripper = ImplStripper { retained: &retained, cache: &cx.cache, is_json_output, document_private: cx.render_options.document_private, }; </ins> stripper.fold_crate(krate) }

Discussion:
cc label +A-docs +A-rustdoc-ui +C-enhancement +T-rustdoc This is technically a regression, but it doesn't feel appropriate to label it as such.
Here is an example of a block that should be hidden when is not passed:
Change:
-> Result<Duration, Duration> { if self >= other { Ok(if self.t.tv_usec >= other.t.tv_usec { <del> Duration::new(self.t.tv_sec as u64 - other.t.tv_sec as u64, (self.t.tv_usec as u32 - other.t.tv_usec as u32) * 1000) </del> <ins> Duration::new((self.t.tv_sec - other.t.tv_sec) as u64, ((self.t.tv_usec - other.t.tv_usec) as u32) * 1000) </ins> } else { <del> Duration::new(self.t.tv_sec as u64 - 1 - other.t.tv_sec as u64, </del> <ins> Duration::new((self.t.tv_sec - 1 - other.t.tv_sec) as u64, </ins> (self.t.tv_usec as u32 + (USEC_PER_SEC as u32) - other.t.tv_usec as u32) * 1000) })

Discussion:
On Mac OS, I get the following when building with : We should track down what's going on with this test, and get the builders enabling debug assertions in general to catch this kind of problem.
cc