jiebi/CodeConvo huggingface dataset:
Change:
// `$ORIGIN/../lib` can find it. It may also be used as a dependency // of `rustc-dev` to support the inherited `-lLLVM` when using the // compiler libraries. <del> maybe_install_llvm(builder, target, &tarball.image_dir().join("lib")); </del> <ins> let dst_libdir = tarball.image_dir().join("lib"); maybe_install_llvm(builder, target, &dst_libdir); let link_type = if builder.config.llvm_link_shared { "dynamic" } else { "static" }; t!(std::fs::write(tarball.image_dir().join("link-type.txt"), link_type), dst_libdir); </ins> Some(tarball.generate()) }

Discussion:
From Switching to static linking would preclude any of the improvements from , so it would be better to use dynamic linking instead which would allow any contributor to get started without building LLVM from source or using system LLVM. That said, it sounds like dynamic linking will be very hard to do on other platforms. cc
Cc - do we know what the right way to bring the issues (bugs?) I found to LLVM developers? Are there active maintainers of LLVMs build system?
LLVM’s bugzilla is pretty much the only place for bug reports. If its something less defined than a precise bug report, talking it out on the mailing lists is the way to go.
In which way is static linking making downloaded LLVM impossible?
I don't think it's impossible to download/ship the statically linked LLVM, it's something I want to explore. That said, we want to move to dynamically linking LLVM because we ideally want to be applying ThinLTO to LLVM everywhere, not just on x86_64-unknown-linux-gnu, and since LTO happens at link-time, we want that to happen once, not on the multiple LLVM links occurring during CI.
Change:
/// in the given `Wtf8Buf`. The `Wtf8Buf` may reserve more space to avoid /// frequent reallocations. After calling `try_reserve`, capacity will be /// greater than or equal to `self.len() + additional`. Does nothing if <del> /// capacity is already sufficient. </del> <ins> /// capacity is already sufficient. This method preserves the contents even /// if an error occurs. </ins> /// /// # Errors ///

Discussion:
Any methods of container types (12 in Rust 1,62.1, including duplicated ones in ), and maybe corresponding methods. - - - - ... and corresponding methods in . Documentations for describes "If the capacity overflows, or the allocator reports a failure, then an error is returned.". However, it does not give any guarantees about whether the content is preserved or not on that error. This guarantee (or absence of the guarantee) should be explicitly described.
At least for (and -based things like ) it's obvious to guarantee that, so we might as well. (Thank you, Rust, for insisting on move-is- so we don't have the "what if the move constructor panics" problems like C++.) I think it'll need to be to hashbrown before we can consider promising it for /, through -- there's no guarantee in <https://rust-
Modulo needing to add it in hashbrown, shall we see if we have consensus to say that failures preserve the current contents? merge
Team member has proposed to merge this. The next step is review by the rest of the tagged team members: [x] [x] [x] [x] [ ] [x] No concerns currently listed. Once a majority of reviewers approve (and at most 2 approvals are outstanding), 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.
: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. As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed. This will be merged soon.
Please feel free to post a PR for this.
Created a PR for this.
Change:
<ins> warning: the feature `const_generics` is incomplete and may cause the compiler to crash --> $DIR/issue-70125-1.rs:2:12 | LL | #![feature(const_generics)] |            ^^^^^^^^^^^^^^ | = note: `#[warn(incomplete_features)]` on by default </ins>

Discussion:
: <details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Got same error with: It seems unrelated to the type of the const
claim
Reduced: Looks like a normalization failure to me, but that shouldn't happen for .
So I found the bug, is just outright missing : <hr/But also, it's worrying that an equivalent to this is missing for consts (even if it's not relevant here):
For the record, what I described above () isn't fixed, just worked around. EDIT: opened .
Change:
ident: "struct", span: $DIR/auxiliary/nested-macro-rules.rs:10:32: 10:38 (#6), }, <del> Group { delimiter: None, stream: TokenStream [ Ident { ident: "FirstAttrStruct", span: $DIR/auxiliary/nested-macro-rules.rs:16:27: 16:42 (#7), }, ], span: $DIR/auxiliary/nested-macro-rules.rs:10:39: 10:56 (#6), </del> <ins> Ident { ident: "FirstAttrStruct", span: $DIR/auxiliary/nested-macro-rules.rs:16:27: 16:42 (#7), </ins> }, Group { delimiter: Brace,

Discussion:
As of , some of our code utilizing macros in [] started to fail to compile. The code that is failing is some macro magic for making nice pin name aliases for microcontrollers, so it's not surprising that broke it. I see that some other repos were broken as well and that helped fix it, but I'm really not sure how to do the fix in our repo. To reproduce: clone the [] repo I expect this to compile properly like on stable, instead it fails to compile with: It most recently worked on: Regressed to with () : modify labels: +regression-from-stable-to-nightly -regression-untriaged []:
Fixed in
Thanks for the quick fix!
Change:
pub span: Span, } <ins> #[derive(SessionDiagnostic)] #[diag(parser::use_eq_instead)] pub(crate) struct UseEqInstead { #[primary_span] #[suggestion_short(applicability = "machine-applicable", code = "=")] pub span: Span, } </ins> // SnapshotParser is used to create a snapshot of the parser // without causing duplicate errors being emitted when the `Parser` // is dropped.

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. If you cannot produce a minimal reproduction case (something that would work in isolation), please provide the steps or even link to a repository that causes the problematic output to occur. --Given the following code: The current output is: <!-- The following is not always necessary. --Ideally the output should suggest replacing the with where appropriate as the suggestion for incorrect usage of in place of already exist. <!-- If the problem is not self-explanatory, please provide a rationale for the change. --<!-- If dramatically different output is caused by small changes, consider also adding them here. 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. The output might also be different depending on the Edition. --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Change:
// FIXME(oli-obk): report cmp errors? l.try_cmp(r).ok() }, <del> ty::TyInt(_) => Some((a as i128).cmp(&(b as i128))), </del> <ins> ty::TyInt(_) => { let a = interpret::sign_extend(tcx, a, ty).expect("layout error for TyInt"); let b = interpret::sign_extend(tcx, b, ty).expect("layout error for TyInt"); Some((a as i128).cmp(&(b as i128))) }, </ins> _ => Some(a.cmp(&b)), } },

Discussion:
The previous version of the crate fails to compile with the error (see the build log). No error nor warning was present in the 1.25 release. Since is actually , the error is wrong and should be fixed. regressed from stable to beta () cc
cc -- initial git log dive notes that this could be related to miri transition? Not sure.
Jup it's a regression. :
Not yet fixed on beta, this needs a backport.
Backported to beta! Thanks!
Change:
<ins> // ignore-tidy-linelength </ins> // edition:2018 #![feature(min_const_generics)]

Discussion:
When run on an with elided lifetimes, generates documentation containing the anonymous elided lifetimes in the function's signature. Running on the blocking variant of the same function produces a correct signature. You can reproduce this issue by generating docs for the following code: The asynchronous function's docs show the elided lifetimes, the blocking function's docs don't: :
I agree that this makes some function signatures unnecessarily verbose. For example: ... becomes ... However, given the nuances of async functions (specifically: the referenced values must survive every state of the FSM), one could argue that showing these lifetimes in the docs might be useful(?). It's obviously not the worst problem on earth, but could someone at least shed some light on whether this behaviour is intended or not? Is this a feature or a bug? Maybe
I think it's the expected behaviour. However we can discuss about removing the elided lifetimes. In this case it's not really useful...
It's especially visually disruptive with a parameter, making simple methods look significantly more complex than they actually are. It also feels surprising to special-case async functions like this, if it makes sense to show these lifetimes symmetry with traditional functions would be nice.
We have several instances of in the Tokio codebase because the version with explicit lifetimes is simpler than the one with all the elided ones displayed. There are many cases where it would be more useful to just not show lifetimes on the method.
So I don't forget, I got halfway through debugging this and it has something to do with 'in band lifetimes': Naively changing this to use the same mechanism as .
Funnily enough, this does work with 1.34 if you add enough s: ! So in some sense this is a regression, although you needed nightly to use at the time.
Change:
} } <del> /// Creates a `Vec<T>` directly from the raw constituents. </del> <ins> /// Creates a `Vec<T>` directly from the raw components of another vector. </ins> /// <del> /// This is highly unsafe: /// /// - if `ptr` is null, then `length` and `capacity` should be 0 /// - `ptr` must point to an allocation of size `capacity` /// - there must be `length` valid instances of type `T` at the ///   beginning of that allocation /// - `ptr` must be allocated by the default `Vec` allocator </del> <ins> /// This is highly unsafe, due to the number of invariants that aren't checked. </ins> /// /// # Example ///

Discussion:
The documentation is misleading. The pointer is not allowed to be null.
How do you make an empty slice if the pointer is not allowed to be null?
The underlying representation is an implementation detail and shouldn't be documented beyond the ability to convert the raw parts obtained from a vector back into a vector.
The language and library documentation has a love affair with making far too many promises about the implementation. In the vector module, there are numerous errors when it comes to information about the vector's capacity too. It tends to guarantee that the capacity is exactly what was asked for rather than at least that much. It is allowed to set the capacity to a value provided by the allocator.
Does that mean you are required to special case the empty case and then use a different way to make an empty vector?
No, it means you can't use this method outside of the standard library beyond converting from an existing vector.
If what you're asking is how it does this internally, the answer is that empty vectors along with zero-size allocations in general are allowed to be entirely arbitrary pointers. They will never be dereferenced and the compiler / library code will never attempt to deallocate them.
The documentation is not supposed to cover these implementation details. It would make sense to cover it in comments (which it is) or internal design documentation.
In that case I suppose the docs should say: can only be constructed from components of an already existing vector.
Change:
<ins> // check-pass #![feature(marker_trait_attr)] #[marker] pub trait F {} impl<T> F for T where T: Copy {} impl<T> F for T where T: 'static {} fn main() {} </ins>

Discussion:
() same code with an additional line of whitespace/comments where indicated: however, the playground seems to behave different from my local nightly here Tested on label T-compiler requires-nightly F-markertraitattr A-traits A-typesystem and someone please add “I-unsound ”
ACTUALLY… the error after adding the whitespace disappears again with . Which would explain why it isn’t reproducable in the playground. Might be related to label A-incr-comp.
This test doesn't seem to compile with the most recent nightly but I don't think the underlying issue has been fixed. Not sure how to retrigger this issue
Change:
<ins> error[E0597]: `awd` does not live long enough --> $DIR/using-late-bound-from-closure.rs:9:29 | LL |     let a = for<'a> |b: &'a ()| -> &'a () { |                 -- lifetime `'a` defined here LL |         const { LL |             let awd = (); |                 --- binding `awd` declared here LL |             let _: &'a () = &awd; |                    ------   ^^^^ borrowed value does not live long enough |                    | |                    type annotation requires that `awd` is borrowed for `'a` LL | LL |         }; |         - `awd` dropped here while still borrowed error: aborting due to 1 previous error For more information about this error, try `rustc --explain E0597`. </ins>

Discussion:
<!-- [31mICE[0m: Rustc '-Zincremental-verify-ich=yes -Cincremental=<dir-Cdebuginfo=2' 'error: internal compiler error: cannot convert to a region vid', 'error: internal compiler error: cannot convert to a region vid' 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: note: compiler flags: -Z incremental-verify-ich=yes -C incremental=[REDACTED] -C debuginfo=2 [mirborrowck] borrow-checking [mirborrowck] borrow-checking -- label +F-closurelifetimebinder +F-inline_const
another one from
Technically fixed by revert
Do we have a technical regression test?
Technically, I don't think so
Change:
for (i, proj) in place.projections.iter().enumerate() { match proj.kind { <del> ProjectionKind::Index => { // Arrays are completely captured, so we drop Index projections </del> <ins> ProjectionKind::Index | ProjectionKind::Subslice => { // Arrays are completely captured, so we drop Index and Subslice projections </ins> truncate_place_to_len_and_update_capture_kind(&mut place, &mut curr_mode, i); return (place, curr_mode); } ProjectionKind::Deref => {} ProjectionKind::Field(..) => {} // ignore <del> ProjectionKind::Subslice => {}  // We never capture this </del> } }

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<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Probably fixed by (
searched nightlies: from nightly-2022-12-30 to nightly-2023-03-18 regressed nightly: nightly-2023-01-01 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.5</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </detailsRegression in same as ..?
You should update your cargo-bisect-rustc version to make it bisect the contents of rollups as well^^
I already have the git version installed :o
Note that we don't have the artifacts for all rollups. I think it requires a perf bisection to be run on the pr or something?
Regression in nightly-2021-09-01 `
Ah, the rollup predates unrolled builds.
I think this is a different issue, it's not fixed by that PR anyway. I'll try and investigate anyway claim The ICE occurs while trying to report this error Changing to fails earlier:
Actually this can be reduced further -
Change:
<ins> trait MyTrait { #[doc = MyTrait] //~^ ERROR attribute value must be a literal fn myfun(); } fn main() {} </ins>

Discussion:
<!-- [31mICE[0m: Rustc '' 'thread 'rustc' panicked at 'called on a value'', 'thread 'rustc' panicked at 'called on a value'' File: --snippet: 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: [hircrate] getting the crate HIR [hirattrs] getting HIR owner attributes in `` [entry_fn] looking up the entry function of a crate [analysis] running analysis passes on this crate --
Crashes since cc
For the record: helped expose a latent bug in AST validation, which will fix.
Also (probably the same cause):
This code now causes unbound memory growth after when trying to print the query stack. after
Change:
<del> error: invalid character `'.'` in crate name: `need_crate_arg_ignore_tidy.x` | = help: you can either pass `--crate-name` on the command line or add `#![crate_name="…"]` to set the crate name error: aborting due to 1 previous error </del>

Discussion:
Running on my checkout with the current master commit fails with tons of errors. here's the last few screens of messages:
Is the check looking for in the full path? My rustc checkout is in a directory called (it's my 2nd of 3 checkouts), and I suspect tidy gets confused by that.
It does CC
That code should probably use .
Oops, I will try to fix this ASAP
Submitted a fix for this at .
Change:
use crate::sys_common::{AsInner, FromInner, IntoInner}; use crate::thread; <del> use core::ffi::c_void; </del> use super::path::maybe_verbatim; use super::to_u16s;

Discussion:
Reported on discord, using will fail on Windows if the file is hidden. This also affects methods like or that open the file the same way. The reason for this is that we use , which has : So to make it work the caller needs to match the requested attributes to the existing attributes at the time of opening. It was suggested we could instead use and then manually truncate the file using to zero.
Manually truncating would require also clearing the alternate data streams too, right? And it would presumably stop erroring if another process still has the file open and instead corrupt the file fron the view of the other process.
No? The proposed solution would work the same was as in the case where the file already exists. Which we use for .
Right, got confused with .
Change:
<ins> error: expected `{`, found `)` --> $DIR/issue-61858.rs:2:15 | LL |     (if foobar) |      --       ^ expected `{` |      | |      this `if` statement has a condition, but no block error: aborting due to previous error </ins>

Discussion:
I tried this code: first outputs some error messages and then hangs up trying to allocate a large amount of memory. :
modify labels: regression-from-stable-to-nightly
Error: Label regression-from-stable-to-nightly can only be set by Rust team members Please let know if you're having trouble with this bot.
Rust 1.34.0 and before is OK:
triage: P-medium. Removing nomination. Assigning to self and for initial investigation.
I'm seeing the same behavior on the following programs: and These were found with the help of .
Another program that I also observe to make run out of memory:
The original report is caused due to growing unbounded in a bad parser code path, in part due to it being a and not a (which it can't be at the moment). Now that I have a clue at what causes the behavior, I'll dig deeper for the trigger.
Change:
<ins> // Copyright 2017 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. fn main() { "😊""; } </ins>

Discussion:
has saying that the column info is provided in characters, not in bytes. However, the error emitter doesn't care about that at all and uses these like byte offsets all over the place. This leads to bugs like and . As an example, look how span printing varies with varying characters used: Correct case: Now add an emoji character: Note how its off by one char now. This can stack up: If I didn't use any spaces at all, I'd run into . Now this can be fixed by going through the emitter code and looking for all places where the pos is used in a byte position fashion. A much more proper fix instead is to stop trusting that people read comments and encode this via the type system. There is already a mechanism for that inside the compiler, its ! Just convert the types of , members of the and structs to , or maybe to if that's preferred.
cc
Change:
<ins> // Copyright 2017 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. fn send<T: Send>(_: T) {} fn sync<T: Sync>(_: T) {} fn main() { // `Cell` is not `Sync`, so `&Cell` is neither `Sync` nor `Send`, // `std::fmt::Arguments` used to forget this... let c = std::cell::Cell::new(42); send(format_args!("{:?}", c)); sync(format_args!("{:?}", c)); } </ins>

Discussion:
is only parameterized on lifetime. The types of the captured arguments are erased in the contained . Nothing restricts the aggregate from being or , so by OIBIT it's both. Thus this compiles: I'm not sure if there are any realistic ways to accidentally abuse this, but here's a deliberate example. The spawned thread will read the through the arguments, even while the main thread modifies it.
Change:
- [Cargo will now output path to custom commands when `-v` is passed with `--list`][cargo/5041] - [The Cargo binary version is now the same as the Rust version][cargo/5083] <del> - [`Cargo.lock` files are now included in published crates.][cargo/5093] </del> Misc ----

Discussion:
The release notes for 1.26 mention but that is a nightly-only unstable feature. Was that intentional?
cc
Yes this seems unintentional, which is odd since it was marked relnotes and unstable features tend not to get that tag. cc would anyone be able to clarify ?
was initially intended for stable but through testing we ended up realizing it would be a breaking change and is not always desirable. Instead of stabilizing it was landed as a nightly feature, guarded by in the manifest