jiebi/CodeConvo huggingface dataset:
Change:
// option. This file may not be copied, modified, or distributed // except according to those terms. <del> // ignore-windows everything is the system allocator on windows // ignore-musl no dylibs on musl right now // ignore-bitrig no jemalloc on bitrig // ignore-openbsd no jemalloc on openbsd </del> <ins> // ignore-musl no dylibs </ins> // aux-build:allocator-dylib2.rs <ins> // aux-build:allocator1.rs </ins> // error-pattern: cannot link together two allocators // Ensure that rust dynamic libraries use jemalloc as their allocator, verifying

Discussion:
As of the time of this writing, we are running jemalloc at the revision which I believe is the 4.0.4 release of jemalloc. Previously we were running which I believe is somewhere in the 3.6 series. We attempted to upgrade jemalloc many times between these two commits eventually that the previous behavior of on Windows is fundamentally racy in jemalloc right now unfortunately. This led to a to where we are today. Unfortunately, however, there is a so we are attempting to downgrade back to 3.6. There were no known problems other than some Windows issues with jemalloc 3.6, so we believe it'll be fine for awhile. In this downgrade, however, it appears that the implementation of is somewhat broken as well, causing the to fail to land. As a result, the downgrade attempt will disable jemalloc on Windows entirely. This issue will track re-enabling it on Windows as well as re-upgrading once the deadlock bug is fixed. As far as I know the only reason to not enable Windows is that lots of locking support was improved in 4.0.*, and the only reason to not upgrade immediately is the deadlock bugs we've encountered.
FWIW one of my Rust projects with CI-every-night has started deadlocking recently, and after some investigation it turned up the exact same stack trace as rustdoc itself, so that's at least another data point for the deadlock in jemalloc.
Change:
// trait selection is because we don't have enough // information about the types in the trait. pending_obligation.stalled_on = <del> trait_ref_type_vars(self.selcx, data.to_poly_trait_ref()); </del> <ins> trait_ref_infer_vars(self.selcx, data.to_poly_trait_ref()); </ins> debug!( "process_predicate: pending obligation {:?} now stalled on {:?}",

Discussion:
I've come up with this example (): My understanding is that the error is caused by the obligation being on just (which means it's not retried when is unified with ), whereas it should be stalled on both and so that it's retried when either changes. Right now is limited to type inference variables, so its representation will need to change, and will need to expose constants too. I believe ran into this as well, but for WF obligations, not trait ones. I'm self-assigning this because I'm working on the fix (as part of a larger effort). cc
Note to self: the PR fixing this should also test this example (): The reason for this is that this second example has the type and const inference variables in different generic args of , meaning fixing it also requires changing this to :
I've definitely noticed problems with inference involving consts before, but wasn't able to pin down where the issue was stemming from. It would be great if this could be addressed once and for all.
Change:
unicode-width = "0.1.4" atty = "0.2" termcolor = "1.0" <del> annotate-snippets = "0.5.0" </del> <ins> annotate-snippets = "0.6.1" </ins>

Discussion:
Part of To support lines in the first column of UI test output, we have to make use of the flag and update the library. Relevant : The relevant PR in the annotate-snippet library and a new version needs to be released. Once that's done, we have to pass as a second argument to . <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
modify labels: A-diagnostics E-help-wanted
claim
Change:
<ins> error[E0308]: mismatched types --> $DIR/hint-closure-signature-119266.rs:5:22 | LL |     let x = |a: u8, b: (usize, u32), c: fn() -> char| -> String { "I love beans.".to_string() }; |             --------------------------------------------------- the found closure ... LL |     let x: fn(i32) = x; |            -------   ^ incorrect number of function parameters |            | |            expected due to this | = note: expected fn pointer `fn(i32)` found closure `{closure@$DIR/hint-closure-signature-119266.rs:2:13: 2:64}` = note: closure has signature: `fn(u8, (usize, u32), fn() -> char) -> String` error: aborting due to 1 previous error For more information about this error, try `rustc --explain E0308`. </ins>

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:
visit::walk_trait_item(self, item); self.resolver.current_module = parent; } <ins> fn visit_token(&mut self, t: Token) { if let Token::Interpolated(nt) = t { match nt.0 { token::NtExpr(ref expr) => { if let ast::ExprKind::Mac(..) = expr.node { self.visit_invoc(expr.id); } } _ => {} } } } </ins> }

Discussion:
This issue probably needs a better title, perhaps someone more familiar with the compiler's handling of macros can suggest a better one. Some kind of error message, at least. panic with exit code :
Simplified: Same ICE will happen if is changed to ///. Update: Panic happens at this line: has keys and , but the is .
Change:
} } <del> /// Returns the set of type inference variables contained in a trait ref. fn trait_ref_type_vars<'a, 'tcx>( </del> <ins> /// Returns the set of inference variables contained in a trait ref. fn trait_ref_infer_vars<'a, 'tcx>( </ins> selcx: &mut SelectionContext<'a, 'tcx>, trait_ref: ty::PolyTraitRef<'tcx>, ) -> Vec<TyOrConstInferVar<'tcx>> {

Discussion:
I've come up with this example (): My understanding is that the error is caused by the obligation being on just (which means it's not retried when is unified with ), whereas it should be stalled on both and so that it's retried when either changes. Right now is limited to type inference variables, so its representation will need to change, and will need to expose constants too. I believe ran into this as well, but for WF obligations, not trait ones. I'm self-assigning this because I'm working on the fix (as part of a larger effort). cc
Note to self: the PR fixing this should also test this example (): The reason for this is that this second example has the type and const inference variables in different generic args of , meaning fixing it also requires changing this to :
I've definitely noticed problems with inference involving consts before, but wasn't able to pin down where the issue was stemming from. It would be great if this could be addressed once and for all.
Change:
let mut inner = false; while let Some((mplace, path)) = ref_tracking.todo.pop() { let mode = match ecx.tcx.static_mutability(cid.instance.def_id()) { <del> Some(_) if cid.promoted.is_some() => { // Promoteds in statics are consts that re allowed to point to statics. CtfeValidationMode::Const { allow_immutable_unsafe_cell: false, allow_extern_static_ptrs: true, } } </del> <ins> _ if cid.promoted.is_some() => CtfeValidationMode::Promoted, </ins> Some(mutbl) => CtfeValidationMode::Static { mutbl }, // a `static` None => { // In normal `const` (not promoted), the outermost allocation is always only copied, // so having `UnsafeCell` in there is okay despite them being in immutable memory. let allow_immutable_unsafe_cell = cid.promoted.is_none() && !inner; <del> CtfeValidationMode::Const { allow_immutable_unsafe_cell, allow_extern_static_ptrs: false, } </del> <ins> CtfeValidationMode::Const { allow_immutable_unsafe_cell } </ins> } }; ecx.const_validate_operand(&mplace.into(), path, &mut ref_tracking, mode)?;

Discussion:
<!-- Thank you for filing a regression report! A regression is something that changed between versions of Rust but was not supposed to. Please provide a short summary of the regression, along with any information you feel is relevant to replicate it. --I tried this code: I expected to see this happen: compile fine, with the static containing a slice that references . Instead, this happened: <!-- Provide the most recent version this worked on, for example: It most recently worked on: Rust 1.47 --It most recently worked on: <!-- Provide the version you are using that has the regression. --:
searched nightlies: from nightly-2024-02-10 to nightly-2024-02-11 regressed nightly: nightly-2024-02-11 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.8</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: cc
Context for how I found this: I use this technique in in code generation for benchmarks of generic functions. The simple example I gave is just a minimal reproduction of the issue.
Hm, that is very strange. Not sure if there is a good way to get the backtrace of where in the code the cyclic queries are made? My first guess is that it is the new call to here: But... surely we can ask for the type of a static while evaluating that very static, that can't be cyclic?
Ah no, probably it is related to the fact that we now recursively validate when a constant points to a static. Previously we stopped there. I guess we should not do that for promoteds.
WG-prioritization assigning priority (). label -I-prioritize +P-high -E-needs-bisection +T-compiler
Change:
d: u64, } <del> // Going from an aggregate struct to another type currently requires Copy to // enable the TrustedRandomAccess specialization. Without it optimizations do not yet // reliably recognize the loops as noop for repr(C) or non-Copy structs. </del> <ins> // implementing Copy exercises the TrustedRandomAccess specialization inside the in-place // specialization </ins> #[derive(Copy, Clone)] pub struct Bar { a: u64,

Discussion:
Adding the follow method as part of a benchmark to which exercises results in the following assembly (extracted with objdump): The ghidra decompile for the same function (comments are mine): Note the useless loop. The number of loop iterations (or rather the pointer increments) is needed to calculate the new length of the output . LLVM already manages to hoist but then it fails to eliminate the now-useless loop. The issue does not occur if one uses instead, which always results in length == 0. I tried several variations of the loop (e.g. replacing with a simple ) but it generally results in the same or worse assembly. Note: The assembly looks somewhat different if I but the decrementing loop without side-effect is still there. I assume the differences are due to LTO or some other compiler settings. Tested on commit 2020-11-21 22:46 modify labels: +I-slow
It looks like this can be solved with more ~dakka~ passes. On godbolt it can be made loop-free by adding And branchless with Using as starting point requires the same passes to be to achieve these results, i.e. it does not provide a better baseline. I failed to reproduce this improvement locally but that might be due to argument escaping issues when attempting to put the space-separated list into
Surprisingly targeting a current CPU results in only one extra pass needed to achieve the loop-free result:
Inserting one loop deletion pass directly into also results in the branchless version without having to change target-cpu or adding additional other passes. So I assume that the other passes are only needed due to the way that works.
It looks like that this removed on nightly now. On nightly: On stable:
That's only true for types because I implemented a specialization for that purpose. The suboptimal assembly still exists for types not implementing Copy, e.g. newtypes. I'll update my initial post.
Something that was is that this case also fails for - i.e. with the specialization - is when the wrapper type is
Seems to work in the other direction weirdly is optimised away, whilst is not
Is there a case here that still doesn't optimize? It looks like all the existing godbolt links do.
Looks good, I'll update the existing codegen test.
Change:
<ins> error[E0267]: `break` inside `async` function --> $DIR/break-inside-coroutine-issue-124495.rs:8:5 | LL |   async fn async_fn() { |  _____________________- LL | |     break; | |     ^^^^^ cannot `break` inside `async` function LL | | } | |_- enclosing `async` function error[E0267]: `break` inside `gen` function --> $DIR/break-inside-coroutine-issue-124495.rs:12:5 | LL |   gen fn gen_fn() { |  _________________- LL | |     break; | |     ^^^^^ cannot `break` inside `gen` function LL | | } | |_- enclosing `gen` function error[E0267]: `break` inside `async gen` function --> $DIR/break-inside-coroutine-issue-124495.rs:16:5 | LL |   async gen fn async_gen_fn() { |  _____________________________- LL | |     break; | |     ^^^^^ cannot `break` inside `async gen` function LL | | } | |_- enclosing `async gen` function error[E0267]: `break` inside `async` block --> $DIR/break-inside-coroutine-issue-124495.rs:20:21 | LL |     let _ = async { break; }; |             --------^^^^^--- |             |       | |             |       cannot `break` inside `async` block |             enclosing `async` block error[E0267]: `break` inside `async` closure --> $DIR/break-inside-coroutine-issue-124495.rs:21:24 | LL |     let _ = async || { break; }; |                      --^^^^^--- |                      | | |                      | cannot `break` inside `async` closure |                      enclosing `async` closure error[E0267]: `break` inside `gen` block --> $DIR/break-inside-coroutine-issue-124495.rs:23:19 | LL |     let _ = gen { break; }; |             ------^^^^^--- |             |     | |             |     cannot `break` inside `gen` block |             enclosing `gen` block error[E0267]: `break` inside `async gen` block --> $DIR/break-inside-coroutine-issue-124495.rs:25:25 | LL |     let _ = async gen { break; }; |             ------------^^^^^--- |             |           | |             |           cannot `break` inside `async gen` block |             enclosing `async gen` block error: aborting due to 7 previous errors For more information about this error, try `rustc --explain E0267`. </ins>

Discussion:
Same issue as which was for blocks. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Change:
<ins> // Crash reduction of // https://github.com/rust-lang/rust/issues/118242 const EXPECTED = [ { 'query': 't', 'correction': null, }, ]; </ins>

Discussion:
sqlx was updated yesterday. and its search is now broken. compare: with:
Firefox prints those errors: with label -needs-triage +T-rustdoc +A-rustdoc-search +regression-untriaged cc
Change:
self.s.word("<"); self.commasep(Inconsistent, &generic_params, |s, param| { <ins> s.print_outer_attributes_inline(&param.attrs); </ins> match param.kind { ast::GenericParamKind::Lifetime => { <del> s.print_outer_attributes_inline(&param.attrs); </del> let lt = ast::Lifetime { id: param.id, ident: param.ident }; s.print_lifetime_bounds(lt, &param.bounds) } ast::GenericParamKind::Type { ref default } => { <del> s.print_outer_attributes_inline(&param.attrs); </del> s.print_ident(param.ident); s.print_type_bounds(":", &param.bounds); <del> match default { Some(ref default) => { s.s.space(); s.word_space("="); s.print_type(default) } _ => {} </del> <ins> if let Some(ref default) = default { s.s.space(); s.word_space("="); s.print_type(default) </ins> } } ast::GenericParamKind::Const { ref ty } => { <del> s.print_outer_attributes_inline(&param.attrs); </del> s.word_space("const"); s.print_ident(param.ident); s.s.space();

Discussion:
As this This is the example proc-macro: This is the test: Run both of result and result are: Formal parameter attributes disappear in proc-macro. Toolchain:
cc
I have a fix in
Change:
<ins> {"module":{"inner":{"lo":0,"hi":0},"items":[{"attrs":[],"id":0,"span":{"lo":0,"hi":0},"vis":{"node":"Inherited","span":{"lo":0,"hi":0}},"ident":{"name":"core","span":{"lo":0,"hi":0}},"kind":{"variant":"ExternCrate","fields":[null]},"tokens":{"_field0":[[{"variant":"Token","fields":[{"kind":{"variant":"Ident","fields":["extern",false]},"span":{"lo":0,"hi":0}}]},"NonJoint"],[{"variant":"Token","fields":[{"kind":{"variant":"Ident","fields":["crate",false]},"span":{"lo":0,"hi":0}}]},"NonJoint"],[{"variant":"Token","fields":[{"kind":{"variant":"Ident","fields":["core",false]},"span":{"lo":0,"hi":0}}]},"NonJoint"],[{"variant":"Token","fields":[{"kind":"Semi","span":{"lo":0,"hi":0}}]},"NonJoint"]]}}],"inline":true},"attrs":[{"kind":{"variant":"Normal","fields":[{"path":{"span":{"lo":0,"hi":0},"segments":[{"ident":{"name":"crate_type","span":{"lo":0,"hi":0}},"id":0,"args":null}]},"args":{"variant":"Eq","fields":[{"lo":0,"hi":0},{"_field0":[[{"variant":"Token","fields":[{"kind":{"variant":"Literal","fields":[{"kind":"Str","symbol":"lib","suffix":null}]},"span":{"lo":0,"hi":0}}]},"NonJoint"]]}]}}]},"id":null,"style":"Inner","span":{"lo":0,"hi":0}}],"span":{"lo":0,"hi":0},"proc_macros":[]} </ins>

Discussion:
The JSON for is broken because the for attributes serializes to nothing. An empty library produces the following: The important bit which is clearly not valid JSON. It looks like the  serialization was removed in . I'm not sure what a solution is here. I'm guessing AST serialization is used elsewhere, where this field isn't needed. I'm not too familiar with , so I'm not sure if it has something equivalent to . cc <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Looks like the encoding/decoding change from needs to be reverted. Reverting should be ok because and don't do anything anyway (at least when inlined) during metadata encoding and decoding. The change is trivial, so marking this as E-easy, but if it's not done until the weekend I'll submit the PR myself.
claim
Change:
member3: &'a Type13<'a>, } <ins> // Helper type to allow `Type14<Bar>` to be a unique ID pub struct Bar; // repr(transparent) parameterized type #[repr(transparent)] pub struct Type14<T>(T); </ins> pub fn foo0(_: ()) { } // CHECK: define{{.*}}foo0{{.*}}!type ![[TYPE0:[0-9]+]] pub fn foo1(_: c_void, _: ()) { }

Discussion:
I've got a fix for this that I'll be uploading in a minute or two, I'm filing the issue to claim an issue number for the test. : </p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
This seems to be a duplicate of .
Change:
declare_tool_lint! { pub rustc::DEFAULT_HASH_TYPES, Allow, <del> "forbid HashMap and HashSet and suggest the FxHash* variants" </del> <ins> "forbid HashMap and HashSet and suggest the FxHash* variants", report_in_external_macro: true </ins> } pub struct DefaultHashTypes {

Discussion:
Filing this since had the idea and so that we don't forget. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
cc
It should be as easy (unless I'm overlooking something) as adding to all declaretool_lint invocations and then fixing the fallout (changing imports as described by the lint)
I'd like to handle this claim
Change:
ty, }; <del> let expr = &tcx.hir().body(ast_const.body).value; </del> <ins> let mut expr = &tcx.hir().body(ast_const.body).value; // Unwrap a block, so that e.g. `{ P }` is recognised as a parameter. Const arguments // currently have to be wrapped in curly brackets, so it's necessary to special-case. if let ExprKind::Block(block, _) = &expr.node { if block.stmts.is_empty() { if let Some(trailing) = &block.expr { expr = &trailing; } } } </ins> if let ExprKind::Path(ref qpath) = expr.node { if let hir::QPath::Resolved(_, ref path) = qpath { if let Res::Def(DefKind::ConstParam, def_id) = path.res {

Discussion:
produces: which is clearly incorrect.
What I believe is happening here is that is no longer treated as a parameter, because it's in brackets. It's a when it gets to rather than a parameter.
Change:
use syntax::util::lev_distance::find_best_match_for_name; use rustc::hir; use rustc::hir::{ExprKind, QPath}; <ins> use rustc::hir::def_id::DefId; </ins> use rustc::hir::def::{CtorKind, Res, DefKind}; use rustc::hir::ptr::P; use rustc::infer;

Discussion:
Trivial example: Output on current nightly: Ideally the error message would suggest using the 2018 edition.
Part of
Change:
} #[test] <del> #[should_fail] </del> #[ignore(cfg(windows))] fn test_from_bytes_fail() { <ins> use str::not_utf8::cond; </ins> let bb = ~[0xff_u8, 0xb8_u8, 0xa8_u8, 0xe0_u8, 0xb9_u8, 0x84_u8, 0xe0_u8, 0xb8_u8, 0x97_u8,

Discussion:
It seems to me that returning a Result would be more appropriate than failing.
See discussion on -- the right thing to do here would be to use conditions, I think.
This should be pretty simple -- working on it.
Fixed pending
fixes.
Change:
I: TrustedLen<Item = T>, { fn from_iter(iterator: I) -> Self { <del> let mut vector = Vec::new(); </del> <ins> let mut vector = match iterator.size_hint() { (_, Some(upper)) => Vec::with_capacity(upper), _ => Vec::new(), }; </ins> // must delegate to spec_extend() since extend() itself delegates // to spec_from for empty Vecs vector.spec_extend(iterator);

Discussion:
The change in made non-PGO builds of Firefox's 's .text section grow by close to 1MB. has a ~89MB section, which makes it a 1% size increase in a library where about only 16% of the code is rust, which makes it a 7% (!) increase in size. This comes from the fact that essentially all uses of Vec::push inline this all for some reason, and it's used all across the place.
modify labels: I-heavy T-libs
Error: Label libs-impl can only be set by Rust team members Please let know if you're having trouble with this bot.
inling seems to have a noticable performance benefit, so not doing so is probably not desirable, see Not sure how else we would be able to directly remedy this issue.
Assigning as and removing .
Change:
// Ensure all ZSTs have been freed. assert!(alloc.state.borrow().0.is_empty()); } <ins> #[test] fn test_vec_from_array_ref() { assert_eq!(Vec::from(&[1, 2, 3]), vec![1, 2, 3]); } #[test] fn test_vec_from_array_mut_ref() { assert_eq!(Vec::from(&mut [1, 2, 3]), vec![1, 2, 3]); } </ins>

Discussion:
Currently we have , should and also be implemented for where ? <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Can you help me with runnable code to understand why the will be useful and what can be a use case for it? label +T-libs-api
Ah ok, maybe I understand what do you mean, currently we can do And your proposal is to support
I don’t have a use case for , adding it is just for matching existing . But for , I want to be able to write: instead of