Question: }; for (local, val) in cpv.can_const_prop.iter_enumerated_mut() { let ty = body.local_decls[local].ty; <del> match tcx.layout_of(param_env.and(ty)) { Ok(layout) if layout.size < Size::from_bytes(MAX_ALLOC_LIMIT) => {} // Either the layout fails to compute, then we can't use this local anyway // or the local is too large, then we don't want to. _ => { *val = ConstPropMode::NoPropagation; continue; </del> <ins> if ty.is_union() { // Do not const prop unions as they can // ICE during layout calc *val = ConstPropMode::NoPropagation; } else { match tcx.layout_of(param_env.and(ty)) { Ok(layout) if layout.size < Size::from_bytes(MAX_ALLOC_LIMIT) => {} // Either the layout fails to compute, then we can't use this local anyway // or the local is too large, then we don't want to. _ => { *val = ConstPropMode::NoPropagation; continue; } </ins> } } }

<!-- 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. --(reduced) <details<summary<strongOriginal Code</strong</summary<p</p</details- Above original code is mutated from I guess at the top causes ICE <!-- 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- ICE occurred at
label regression-from-stable-to-beta
searched nightlies: from nightly-2024-02-01 to nightly-2024-04-10 regressed nightly: nightly-2024-02-09 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.7</summaryHost triple: aarch64-unknown-linux-gnu Reproduce with: </detailscc
WG-prioritization assigning priority (). label -I-prioritize +P-medium


Question: <ins> warning: the feature `non_lifetime_binders` is incomplete and may not be safe to use and/or cause compiler crashes --> $DIR/unifying-placeholders-in-query-response.rs:5:12 | LL | #![feature(non_lifetime_binders)] |            ^^^^^^^^^^^^^^^^^^^^ | = note: see issue #108185 <https://github.com/rust-lang/rust/issues/108185> for more information = note: `#[warn(incomplete_features)]` on by default warning: 1 warning emitted </ins>

<!-- 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. --minimal project with full compiler output can be found here cargo 1.77.0-nightly ( 2024-01-09) : <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details


Question: // Free the allocation without dropping its contents let (bptr, alloc) = Box::into_raw_with_allocator(src); <del> let src = Box::from_raw(bptr as *mut mem::ManuallyDrop<T>); </del> <ins> let src = Box::from_raw_in(bptr as *mut mem::ManuallyDrop<T>, alloc.by_ref()); </ins> drop(src); Self::from_ptr_in(ptr, alloc)

run Output: Miri: The underlying issue was found when reviewing the implementation of . The code is a reproduction to trigger the unsoundness. The implementation in question features: Where is turned into and dropped. Yes, that’s , not . The code for seems to be doing the same thing. For comparison: The code for (and the same thing for ) seems to properly use a … no actually, that’s a with zero lengths… notably the allocator is correct though. So the buggy code for should just switch to create a presumably. label I-unsound requires-nightly T-libs


Question: - [Extend `ptr::null` and `null_mut` to all thin (including extern) types.][94954] - [`impl Read and Write for VecDeque<u8>`.][95632] - [STD support for the Nintendo 3DS.][95897] <ins> - [Use rounding in float to Duration conversion methods.][96051] </ins> - [Make write/print macros eagerly drop temporaries.][96455] - [Implement internal traits that enable `[OsStr]::join`.][96881] - [Implement `Hash` for `core::alloc::Layout`.][97034]

<!-- 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. --- ~Related release note: ~Related PR: ~ ~Though the PR describes the change is related to improve its truncation better, the changed behavior is rounding up which was down before.~ EDIT: The upper changes and issue . It is not related to this issue. I want to check if this is expected change or regression. I tried this code: I expected to see this happen: explanation Until 1.62.1, Instead, this happened: explanation In 1.63.0, <!-- Provide the most recent version this worked on, for example: It most recently worked on: Rust 1.47 --It most recently worked on: Until 1.62.1 <!-- Provide the version you are using that has the regression. --:
-- that PR you linked landed in 1.60, not 1.63?
Oh, I am sorry. I probably didn't check how much I scrolled down from release note. Then which change would be related?


Question: <del> // 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. fn foo(_s: i16) { } fn bar(_s: u32) { } fn main() { foo(1*(1 as int)); //~^ ERROR: mismatched types: expected `i16`, found `int` (expected `i16`, found `int`) bar(1*(1 as uint)); //~^ ERROR: mismatched types: expected `u32`, found `uint` (expected `u32`, found `uint`) } </del>

Sorry for not providing smaller case but I hope this is better than nothing: Both versions works (compile and start), but runtime behavior changes. The code that follows the above part: will match no matter what really is, if the value is partially moved (so mouse events are updating my game). If I use the version with , the code works as intended and game is updated only on keyboard presses.
Minimal: This shouldn't compile at all.
Nominating.
Looks like a regression. 0.10 rejects this code.


Question: kind: TypeVariableOriginKind::MiscVariable, span: full_call_span, }); <del> self.point_at_expr_source_of_inferred_type(&mut err, rcvr, expected, callee_ty); </del> <ins> self.point_at_expr_source_of_inferred_type( &mut err, rcvr, expected, callee_ty, provided_arg_span, ); </ins> } // Call out where the function is defined self.label_fn_like(

I tried this code on nightly: I expected to see this happen: compiler does not panic. Instead, this happened: compiler panics and suggests I open a bug report. I initially posted to , but says this is a different issue, despite panicking on the same line in . (Though I'm realizing now that might be the proximal cause but not very related to the root cause.) : <details<summaryPanic message</summary<p</p</detailsThanks all for maintaining Rust, by the way.
Thanks!
searched nightlies: from nightly-2022-12-01 to nightly-2023-01-21 regressed nightly: nightly-2023-01-07 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: </details
It's , i'll fix it unless someone beats me to it since I'm busy this weekend
Hi it's Justin from Commure :wave:. I found a compiler panic you made :grinning:
sorry for causing you trouble


Question: /// Float types, respectively). When comparing two ADTs, these rules apply recursively. pub fn same_type_modulo_infer(&self, a: Ty<'tcx>, b: Ty<'tcx>) -> bool { let (a, b) = self.resolve_vars_if_possible((a, b)); <del> match (a.kind(), b.kind()) { (&ty::Adt(def_a, substs_a), &ty::Adt(def_b, substs_b)) => { if def_a != def_b { return false; } </del> <ins> SameTypeModuloInfer(self).relate(a, b).is_ok() } } </ins> <del> substs_a .types() .zip(substs_b.types()) .all(|(a, b)| self.same_type_modulo_infer(a, b)) } (&ty::FnDef(did_a, substs_a), &ty::FnDef(did_b, substs_b)) => { if did_a != did_b { return false; } </del> <ins> struct SameTypeModuloInfer<'a, 'tcx>(&'a InferCtxt<'a, 'tcx>); </ins> <del> substs_a .types() .zip(substs_b.types()) .all(|(a, b)| self.same_type_modulo_infer(a, b)) } (&ty::Int(_) | &ty::Uint(_), &ty::Infer(ty::InferTy::IntVar(_))) </del> <ins> impl<'tcx> TypeRelation<'tcx> for SameTypeModuloInfer<'_, 'tcx> { fn tcx(&self) -> TyCtxt<'tcx> { self.0.tcx } fn param_env(&self) -> ty::ParamEnv<'tcx> { // Unused, only for consts which we treat as always equal ty::ParamEnv::empty() } fn tag(&self) -> &'static str { "SameTypeModuloInfer" } fn a_is_expected(&self) -> bool { true } fn relate_with_variance<T: relate::Relate<'tcx>>( &mut self, _variance: ty::Variance, _info: ty::VarianceDiagInfo<'tcx>, a: T, b: T, ) -> relate::RelateResult<'tcx, T> { self.relate(a, b) } fn tys(&mut self, a: Ty<'tcx>, b: Ty<'tcx>) -> RelateResult<'tcx, Ty<'tcx>> { match (a.kind(), b.kind()) { (ty::Int(_) | ty::Uint(_), ty::Infer(ty::InferTy::IntVar(_))) </ins> | ( <del> &ty::Infer(ty::InferTy::IntVar(_)), &ty::Int(_) | &ty::Uint(_) | &ty::Infer(ty::InferTy::IntVar(_)), </del> <ins> ty::Infer(ty::InferTy::IntVar(_)), ty::Int(_) | ty::Uint(_) | ty::Infer(ty::InferTy::IntVar(_)), </ins> ) <del> | (&ty::Float(_), &ty::Infer(ty::InferTy::FloatVar(_))) </del> <ins> | (ty::Float(_), ty::Infer(ty::InferTy::FloatVar(_))) </ins> | ( <del> &ty::Infer(ty::InferTy::FloatVar(_)), &ty::Float(_) | &ty::Infer(ty::InferTy::FloatVar(_)), </del> <ins> ty::Infer(ty::InferTy::FloatVar(_)), ty::Float(_) | ty::Infer(ty::InferTy::FloatVar(_)), </ins> ) <del> | (&ty::Infer(ty::InferTy::TyVar(_)), _) | (_, &ty::Infer(ty::InferTy::TyVar(_))) => true, (&ty::Ref(_, ty_a, mut_a), &ty::Ref(_, ty_b, mut_b)) => { mut_a == mut_b && self.same_type_modulo_infer(ty_a, ty_b) } (&ty::RawPtr(a), &ty::RawPtr(b)) => { a.mutbl == b.mutbl && self.same_type_modulo_infer(a.ty, b.ty) } (&ty::Slice(a), &ty::Slice(b)) => self.same_type_modulo_infer(a, b), (&ty::Array(a_ty, a_ct), &ty::Array(b_ty, b_ct)) => { self.same_type_modulo_infer(a_ty, b_ty) && a_ct == b_ct } (&ty::Tuple(a), &ty::Tuple(b)) => { if a.len() != b.len() { return false; } std::iter::zip(a.iter(), b.iter()).all(|(a, b)| self.same_type_modulo_infer(a, b)) } (&ty::FnPtr(a), &ty::FnPtr(b)) => { let a = a.skip_binder().inputs_and_output; let b = b.skip_binder().inputs_and_output; if a.len() != b.len() { return false; } std::iter::zip(a.iter(), b.iter()).all(|(a, b)| self.same_type_modulo_infer(a, b)) } // FIXME(compiler-errors): This needs to be generalized more _ => a == b, </del> <ins> | (ty::Infer(ty::InferTy::TyVar(_)), _) | (_, ty::Infer(ty::InferTy::TyVar(_))) => Ok(a), (ty::Infer(_), _) | (_, ty::Infer(_)) => Err(TypeError::Mismatch), _ => relate::super_relate_tys(self, a, b), </ins> } } <ins> fn regions( &mut self, a: ty::Region<'tcx>, b: ty::Region<'tcx>, ) -> RelateResult<'tcx, ty::Region<'tcx>> { if (a.is_var() && b.is_free_or_static()) || (b.is_var() && a.is_free_or_static()) || a == b { Ok(a) } else { Err(TypeError::Mismatch) } } fn binders<T>( &mut self, a: ty::Binder<'tcx, T>, b: ty::Binder<'tcx, T>, ) -> relate::RelateResult<'tcx, ty::Binder<'tcx, T>> where T: relate::Relate<'tcx>, { Ok(ty::Binder::dummy(self.relate(a.skip_binder(), b.skip_binder())?)) } fn consts( &mut self, a: ty::Const<'tcx>, _b: ty::Const<'tcx>, ) -> relate::RelateResult<'tcx, ty::Const<'tcx>> { // FIXME(compiler-errors): This could at least do some first-order // relation Ok(a) } </ins> } impl<'a, 'tcx> InferCtxt<'a, 'tcx> {

Sorry, this is not necessarily the smallest possible example. Please let me know if this is unhelpful and I'll come up with something more concise. Given the following code: The output in current stable (1.63.0) is: (Please note the "expected closure with ... found closure with ..." hint.) From 1.64 onwards, the expected/found hint is omitted: To me the 1.63 behaviour is preferable to that from 1.64+ as it can often be non-obvious where the differences lie.
searched nightlies: from nightly-2022-06-01 to nightly-2022-08-11 regressed nightly: nightly-2022-07-23 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.4</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
Looks like it was caused by , which is pretty big diagnostics PR in that rollup. cc
Of course I caused it.
label -E-needs-bisection
WG-prioritization assigning priority (). label -I-prioritize +P-medium


Question: FileType(self.0.file_type()) } <del> /// Returns whether this metadata is for a directory. </del> <ins> /// Returns whether this metadata is for a directory. The /// result is mutually exclusive to the result of /// [`is_file`], and will be false for symlink metadata /// obtained from [`symlink_metadata`]. /// /// [`is_file`]: struct.Metadata.html#method.is_file /// [`symlink_metadata`]: fn.symlink_metadata.html </ins> /// /// # Examples ///

should document that , , and are all mutually exclusive. (and that it may also be the case that none of them are true) Why? Because returns true for both files and symlinks to files, and this tends to make me paranoid that a will share similar characteristics and perhaps claim that both and . The only way to convince myself that FileType's behavior is indeed sane is to write a little test program---again. Surely I can't be alone in this.
is calling not (and equivalent on Windows), so if the path is a symlink, then it returns the results based on what the symlink points to, not the symlink itself. So respects the same mutual exclusivity rules as . But yes, this ought to be documented, especially given that the mutually exclusive behavior may be surprising to Windows developers.
Similar goes for , which should document that these are always false for a obtained by calling on a symlink.
Well you can always call on something that is not a symlink, in which case or could be true.


Question: pub mod rusti { #[abi = "rust-intrinsic"] pub extern { <del> pub fn frame_address(f: &once fn(++x: *u8)); </del> <ins> pub fn frame_address(f: &once fn(x: *u8)); </ins> } }

This function still takes its argument by explicit .
also,
I'm doing this, just waiting for tests.
Done, pending
Fixed in


Question: let short = item.type_(); let myname = match item.name { None => continue, <del> Some(ref s) => s.to_string(), </del> <ins> Some(s) => s, </ins> }; <del> let short = short.to_string(); map.entry(short).or_default().push(( myname, Some(item.doc_value().map_or_else(String::new, |s| plain_text_summary(&s))), )); </del> <ins> if inserted.entry(short).or_default().insert(myname) { let short = short.to_string(); let myname = myname.to_string(); map.entry(short).or_default().push(( myname, Some(item.doc_value().map_or_else(String::new, |s| plain_text_summary(&s))), )); } </ins> } if self.shared.sort_modules_alphabetically {

Hey! Ran into what appears to be a bug - crate's exported macros each appear twice in the left sidebar: ! Toolchain versions (per log): rustc 1.60.0-nightly ( 2022-02-09), docsrs 0.6.0 ( 2022-02-01) Please let me know if I can provide additional info.
Thank you for the report! This is definitely not an issue with itself, but with rustdoc. is this known? Should a rustdoc issue be created?
Not known afaik. Please do file an issue (or transfer this one)!
Seems similar to
Thanks for transferring the issue. One difference between this and - both macros are exported using a wildcard in crate root (not rename):
Well, just another reexport issue. It's common around here. :laughing: I'll try to take a look in the next days.
This is what I have on currently nightly: ! So I guess it's fixed?
Trying locally with the latest nightly (, more current than that of issue open) I get the same initial landing page for but if I click on one of the macros listed (e.g. "drill down") duplicates still appear on the sidebar: ! So the tiny bug is still there, just deeper/hidden on the latest nightly?
Ah indeed! I can also reproduce it now. Will take another look tomorrow then.


Question: <ins> // Regression test for #57597. // // Make sure that nested matchers work correctly rather than causing an infinite loop or crash. // edition:2018 macro_rules! foo1 { ($($($i:ident)?)+) => {}; //~^ ERROR repetition matches empty token tree } macro_rules! foo2 { ($($($i:ident)?)*) => {}; //~^ ERROR repetition matches empty token tree } macro_rules! foo3 { ($($($i:ident)?)?) => {}; //~^ ERROR repetition matches empty token tree } macro_rules! foo4 { ($($($($i:ident)?)?)?) => {}; //~^ ERROR repetition matches empty token tree } macro_rules! foo5 { ($($($($i:ident)*)?)?) => {}; //~^ ERROR repetition matches empty token tree } macro_rules! foo6 { ($($($($i:ident)?)*)?) => {}; //~^ ERROR repetition matches empty token tree } macro_rules! foo7 { ($($($($i:ident)?)?)*) => {}; //~^ ERROR repetition matches empty token tree } macro_rules! foo8 { ($($($($i:ident)*)*)?) => {}; //~^ ERROR repetition matches empty token tree } macro_rules! foo9 { ($($($($i:ident)?)*)*) => {}; //~^ ERROR repetition matches empty token tree } macro_rules! foo10 { ($($($($i:ident)?)*)+) => {}; //~^ ERROR repetition matches empty token tree } macro_rules! foo11 { ($($($($i:ident)+)?)*) => {}; //~^ ERROR repetition matches empty token tree } macro_rules! foo12 { ($($($($i:ident)+)*)?) => {}; //~^ ERROR repetition matches empty token tree } fn main() { foo1!(); foo2!(); foo3!(); foo4!(); foo5!(); foo6!(); foo7!(); foo8!(); foo9!(); foo10!(); foo11!(); foo12!(); } </ins>

The following code will cause the compiler to fail: Playground link: It should error that the inner matcher can match an empty string and reject it, just as it does if is used in place of .
The fix should be very easy, since this was already fixed for repetitions in (original bug: ): Looks like just needs to be checked against , too.
cc
Note that with on the outside, this errors properly, although with inconsistent error messages: if the inner repetition uses only, the error is "repetition matches empty token tree", but it seems that if any of the repetitions are , then the error is "multiple successful parses".
The behaviour in my previous comment is because the check for "repetition matches empty token tree" is done at definition time, but does not catch ; this is caught at expansion time however. Ideally all of this will be moved to definition time and the expansion-time check should probably be a) corrected to address the first comment and b) possibly become an ICE, since it should never be encountered since the RFC 550 rules should eliminate all ambiguity at definition time?
Hmm... I don't really remember how most of this code works... Just grepping, but it looks like there are a couple of other places we might want to look at:
I've opened


Question: }; let ExpansionData { depth, id: expn_id, .. } = invoc.expansion_data; <ins> let depth = depth - orig_expansion_data.depth; </ins> self.cx.current_expansion = invoc.expansion_data.clone(); self.cx.force_mode = force;

I tried this code: I expected to see this happen: An error message about exceeding some recursion limit Instead, this happened: Tested on stable 1.51.0 + <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Note that the crash also occurs without . Based on testing with Godbolt, this doesn't seem to be a regression, or at least not a recent one.
Assigning as part of the prioritization working group discussion and removing . modify labels -I-prioritize +P-medium
Issue might be in this line: Calls , which then calls : And sets to , which would result in stack overflow because the recursion limit is never reached.
claim
Bug is confusing to track down, so I am no longer working on this. For people who are interested, here is the log when the loop is encountered: release-assignment
The issue is part of a bigger problem, that seems to ignore the recursion limit. This snippet below compiles successfully instead of reporting an error:
Seems to be a regression between and by testing on Godbolt. I suspect from caused the regression, but I'm not sure. label regression-untriaged


Question: pat: &'tcx Pat<'tcx>, expected: Ty<'tcx>, span: Option<Span>, <del> origin_expr: bool, </del> <ins> origin_expr: Option<&'tcx hir::Expr<'tcx>>, </ins> ) { let info = TopInfo { expected, origin_expr, span }; self.check_pat(pat, expected, INITIAL_BM, info);

<!-- 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 to the user that they need to initialize the enum variant's value in order to use the . <!-- 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 --
Can you give the output of what it should look like?
It should probably look similar to the suggestion given for and So I guess sth. like: Edit: Or instead of saying “to instantiate this tuple variant” we could say “to call this function” like it's done for the erroneous snippet (where is a ).
claim
commit the fix


Question: // Use `||` to give these suggestions a precedence let suggested = self.suggest_missing_parentheses(err, expr) <ins> || self.suggest_missing_unwrap_expect(err, expr, expected, expr_ty) </ins> || self.suggest_remove_last_method_call(err, expr, expected) || self.suggest_associated_const(err, expr, expected) || self.suggest_deref_ref_or_into(err, expr, expected, expr_ty, expected_ty_expr)

in Dec '22 introduced a cool new feature to suggest removing the last method call if it would alleviate a type mismatch error. This is particularly using for people wrestling with issues. in Oct '23 introduced another useful feature to suggest to users that they might consider ing an or type in order to solve a type mismatch. Also very cool, and conveniently by the same author Unfortunately, in cases where a method is called, the previous check takes precedence, and the compiler suggests removing that trailing method to get the code to compile. This isn't generally that useful as the expect suggestion, and I can't think of an example where it's a better one. If you can think of one though, please put it below for me to test! surfaced this with but it's more easily demonstrated with ints. I can see two ways to fix this: the trailing method check first, but ignore and types the checks so the option type is checked first. Note that the method check has to be high in the chain as the motive is to quickly suggest removing a call, before adding a whole load of new ones. This means the check has to be one of the first I am going to work on solving it via method 2, as it feels cleaner that the method check doesn't have to know about the and check. If anyone has strong feelings on this, please let me know! Playground No response No response <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
I think this suggestion for removing the method call is way too eager, as it can easily be wrong and when it's wrong it's quite confusing. Maybe it should instead say that the type was correct before the method call (which is never wrong), nudging the user towards removing the call if they know that it's not important. Instead of strongly saying that it should be removed. Alternatively, it could be special cased to known "unimportant" functions like or .
I think this brings up two issues: should the method call suggestor should do, and say. There was some discussion of this in where it was decided to keep it generic rather than special-casing, but I don't think it's done badly at the moment. Perhaps the wording could be altered?


Question: // Use `||` to give these suggestions a precedence let suggested = self.suggest_missing_parentheses(err, expr) <ins> || self.suggest_missing_unwrap_expect(err, expr, expected, expr_ty) </ins> || self.suggest_remove_last_method_call(err, expr, expected) || self.suggest_associated_const(err, expr, expected) || self.suggest_deref_ref_or_into(err, expr, expected, expr_ty, expected_ty_expr)

it should run I'll focus on the latter here, but if you have examples where removing the method call doesn't make sense we can aggregate them and see if there is a holistic solution?


Question: <ins> type Range = std::ops::Range<usize>; fn demo(r: &Range) { println!("{:?}", r); } fn tell(x: usize) -> usize { x } fn main() { demo(tell(1)..tell(10)); //~^ ERROR mismatched types demo(1..10); //~^ ERROR mismatched types } </ins>

Hi there! With this code (here's a ) The compiler reports this error message with a hint but the hint is incorrect due to missing parantheses in this case. The correct answer would be It works correctly when the second line in main is executed, where the range is provided directly. : <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim


Question: <ins> error[E0425]: cannot find function `used_fn` in this scope --> $DIR/tainted-body.rs:9:9 | LL |         used_fn(); |         ^^^^^^^ not found in this scope error: aborting due to 1 previous error For more information about this error, try `rustc --explain E0425`. </ins>

<!-- ICE: Rustc '-Zvalidate-mir -ooutputfile -Zdump-mir-dir=dir' 'error: internal compiler error: unexpected body ty: {type error} phase Runtime(PostCleanup)', 'error: internal compiler error: unexpected body ty: {type error} phase Runtime(PostCleanup)' 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: [mirdropselaboratedandconstchecked] elaborating drops for [analysis] running analysis passes on this crate --
cc :D (note you'll need which was merged 10 minutes ago ^^ )


Question: <ins> error[E0425]: cannot find function `used_fn` in this scope --> $DIR/tainted-body.rs:9:9 | LL |         used_fn(); |         ^^^^^^^ not found in this scope error: aborting due to 1 previous error For more information about this error, try `rustc --explain E0425`. </ins>

<!-- ICE: Rustc '--edition=2021 -ooutputfile -Zdump-mir-dir=dir' 'error: internal compiler error: impossible case reached', 'error: internal compiler error: impossible case reached' File: --auto-reduced (treereduce-rust): <details<summary<strongoriginal code</strong</summary<poriginal: </p</detailsVersion 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: [mirconst] preparing for borrow checking [mirpromoted] promoting constants in MIR for [mir_borrowck] borrow-checking [analysis] running analysis passes on this crate --
cc


Question: base.has_elf_tls = true; base.features = "+neon,+fp-armv8".to_string(); <del> // FIXME: this shouldn't be panic=abort, it should be panic=unwind base.panic_strategy = PanicStrategy::Abort; </del> Ok(Target { llvm_target: "aarch64-pc-windows-msvc".to_string(), target_endian: "little".to_string(),

The and targets force panic=abort. said : This looks related to , which points at these now-merged LLVM changes: It's possible that we do not need to force panic=abort anymore for arm64 Windows as a result. What's the best way to determine if this is still required?
Theoretically the way to fix this issue is: First Next, run the build Finally, run the tests If that all passes, then the change can land! The tests may be able to be skipped, and some tests may fail, so it may be possible to switch the defaults and we can fixup bugs later. I don't personally have hardware to test these changes on myself, though.
I occasionally have access to a Windows arm64 laptop, so I'll try and get a rustc build going on it at some point.


Question: <ins> // only-x86_64 #![feature(target_feature_11)] #[target_feature(enable = "avx")] fn foo() {} #[target_feature(enable = "avx")] unsafe fn foo_unsafe() {} fn call(f: impl Fn()) { f() } fn call_mut(f: impl FnMut()) { f() } fn call_once(f: impl FnOnce()) { f() } fn main() { call(foo); //~ ERROR expected a `std::ops::Fn<()>` closure, found `fn() {foo}` call_mut(foo); //~ ERROR expected a `std::ops::FnMut<()>` closure, found `fn() {foo}` call_once(foo); //~ ERROR expected a `std::ops::FnOnce<()>` closure, found `fn() {foo}` call(foo_unsafe); //~^ ERROR expected a `std::ops::Fn<()>` closure, found `unsafe fn() {foo_unsafe}` call_mut(foo_unsafe); //~^ ERROR expected a `std::ops::FnMut<()>` closure, found `unsafe fn() {foo_unsafe}` call_once(foo_unsafe); //~^ ERROR expected a `std::ops::FnOnce<()>` closure, found `unsafe fn() {foo_unsafe}` } </ins>

(Moved from with an PoC.) The following program () demonstrates how current implementation of allows using a targetfeature from safe code without ensuring it's actually available: This is unsound because it allows executing (e.g.) AVX instructions on CPUs that do not implement them, which is UB. It only works because "safe fns with targetfeatures" are erroneously considered to implement the FnOnce/FnMut/Fn traits.
Proposed resolution: It would probably be better to add the to functions implicitly during lowering to HIR. Implicit is already to functions in blocks in the same way. That would make the unsafety checker the only place (besides AST lowering) where they would be treated specially. Like, "yes, the function is unsafe, but we know that it's safe to call in this specific context, so the unsafe block can be omitted". The special coercion checks would no longer be necessary in that case.
Or perhaps the RFC should be revised to still require writing and only unsafety checker need to be enhanced to allow calling unsafe functions without unsafe blocks in the situations known to be safe. That would be even less magic, which is good, IMO. The ergonomic regression would be minor because would still be not required at call sites.
Good catch. Another option is that referencing, not calling, a target-feature function is unsafe, but I guess that is a bit inconsistent given that this already compiles (): In other words, accessing a safe target feature 1.1 function would be unsafe (unless the target feature is in scope), not just calling it. I think that this is what I would expect somehow, but I would expect it to apply uniformly to both safe and unsafe target feature functions (and that's not an option). The downside of this approach is that we don't know why the function was declared unsafe, not really -- was it only because of the target feature? Or were there additional requirements that would have made it unsafe?
For example, a whole bunch of functions take raw pointers and use them to access memory, so they need to be unsafe even if the respective target feature is enabled in the calling context.
The downside of this approach is that we don't know why the function was declared unsafe, not really -- was it only because of the target feature? Or were there additional requirements that would have made it unsafe? Ah, right, that's a good argument.


Question: <ins> // only-x86_64 #![feature(target_feature_11)] #[target_feature(enable = "avx")] fn foo() {} #[target_feature(enable = "avx")] unsafe fn foo_unsafe() {} fn call(f: impl Fn()) { f() } fn call_mut(f: impl FnMut()) { f() } fn call_once(f: impl FnOnce()) { f() } fn main() { call(foo); //~ ERROR expected a `std::ops::Fn<()>` closure, found `fn() {foo}` call_mut(foo); //~ ERROR expected a `std::ops::FnMut<()>` closure, found `fn() {foo}` call_once(foo); //~ ERROR expected a `std::ops::FnOnce<()>` closure, found `fn() {foo}` call(foo_unsafe); //~^ ERROR expected a `std::ops::Fn<()>` closure, found `unsafe fn() {foo_unsafe}` call_mut(foo_unsafe); //~^ ERROR expected a `std::ops::FnMut<()>` closure, found `unsafe fn() {foo_unsafe}` call_once(foo_unsafe); //~^ ERROR expected a `std::ops::FnOnce<()>` closure, found `unsafe fn() {foo_unsafe}` } </ins>

The "unsafety checker enhancement" should only affect unsafe functions that are made unsafe through , but not other means (explicit or block).
I'm new to the compiler, but it seemed non-trivial to change functions to unsafe when lowering to HIR. It looks to me like you'd end up with just as many exceptions (ignoring the unsafe in some scenarios), in addition tracking the origin of the . On the other hand it was pretty trivial to not implement the Fn traits instead. I'll open a PR with my fix, but please close it if the other method is preferred.
So there are sort of two questions here. One of them is what user-visible behavior is permitted, and the other is how precisely that is implemented in the compiler. I think the latter only concerns the team in-so-far as it represents the impact on the language spec and on the "mental model" that users must keep in mind. Nominating for the lang-team meeting to discuss solution, which is simply to make "target-feature" functions not implement the traits (just as functions do not implement the traits, along with functions with non-Rust ABIs etc).
I think I was tagged by mistake :wink:
Apologies! Fixed. Github autocompleted that for me. Here I was feeling so grateful to it.
We discussed this in . The conclusion was that the fix that proposed is good for right now. It's already the case that many items do not implement the function trait (e.g., those with custom ABIs or which are unsafe), so this would be "yet another" case (admittedly a somewhat different one in that this case doesn't show up in the type of function pointers, for better or worse). We uncovered a few other interesting observations: pointed out that their ideal preference would be to have something like " only implements " within an unsafe block, but of course the trait system has no precedent for that. It would be sort of like a attached to the impl block (i.e., the impl is usable in some context where unsafe code is allowed). Another possibility might be " only implements within a fn that has a suitable target feature in scope". This is an interesting idea because, although the pointer could escape in the form of a , the idea is that once you enter , you've already demonstrated that you possess the target feature, so it's ok if the value escapes.


Question: <ins> // only-x86_64 #![feature(target_feature_11)] #[target_feature(enable = "avx")] fn foo() {} #[target_feature(enable = "avx")] unsafe fn foo_unsafe() {} fn call(f: impl Fn()) { f() } fn call_mut(f: impl FnMut()) { f() } fn call_once(f: impl FnOnce()) { f() } fn main() { call(foo); //~ ERROR expected a `std::ops::Fn<()>` closure, found `fn() {foo}` call_mut(foo); //~ ERROR expected a `std::ops::FnMut<()>` closure, found `fn() {foo}` call_once(foo); //~ ERROR expected a `std::ops::FnOnce<()>` closure, found `fn() {foo}` call(foo_unsafe); //~^ ERROR expected a `std::ops::Fn<()>` closure, found `unsafe fn() {foo_unsafe}` call_mut(foo_unsafe); //~^ ERROR expected a `std::ops::FnMut<()>` closure, found `unsafe fn() {foo_unsafe}` call_once(foo_unsafe); //~^ ERROR expected a `std::ops::FnOnce<()>` closure, found `unsafe fn() {foo_unsafe}` } </ins>

(This would be like a clause.) To that end, I was thinking that you could model this last point using closures, but I found that it doesn't work. In particular, gives an error, even if it appears inside of a function annotated with . This seems like something we should discuss, but it's a separate issue. We did discuss briefly whether target features should be part of the type of function pointers but I think the conclusion was 'well maybe but there is already stable code out there that lets you coerce, and it seems rather niche'. We also discussed whether we should permit one to annotate closures with target-feature annotations. In any case, those are things we can address separately from this issue, but the point is that adopting more accepting solutions can be done in the future.
I'm going to move the question of whether closures should "inherit" target features to the main tracking issue -- I'm not sure if that is something that was discussed as part of the original RFC discussion?
Opened to discuss closures.


Question: } fn check_fn_decl(&self, fn_decl: &FnDecl, self_semantic: SelfSemantic) { <ins> self.check_decl_num_args(fn_decl); </ins> self.check_decl_cvaradic_pos(fn_decl); self.check_decl_attrs(fn_decl); self.check_decl_self_param(fn_decl, self_semantic); } <ins> /// Emits fatal error if function declaration has more than `u16::MAX` arguments /// Error is fatal to prevent errors during typechecking fn check_decl_num_args(&self, fn_decl: &FnDecl) { let max_num_args: usize = u16::MAX.into(); if fn_decl.inputs.len() > max_num_args { let Param { span, .. } = fn_decl.inputs[0]; self.err_handler().span_fatal( span, &format!("function can not have more than {} arguments", max_num_args), ); } } </ins> fn check_decl_cvaradic_pos(&self, fn_decl: &FnDecl) { match &*fn_decl.inputs { [Param { ty, span, .. }] => {

Obviously a corner case. This would never actually be used for anything, this is just testing the bounds of what the compiler is capable of. Running this Ruby method with numarguments or greater generates a Rust file which can be used to reproduce the output. (via ) : </p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
label +regression-from-stable-to-beta
Nothing that Ruby code can achieve that Rust macros couldn't do as well: ()
Haha, just tried out a different direction of “many arguments”. Apparently this results in a segfault, AFAICT It’s explicitly a stack overflow on stable (and AFAIK segfaults can happen on stack overflow in sound rust code, so maybe it isn’t some memory unsafety). <hrEdit: Opened this as a separate issue
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-low


Question: - [`#[link]` attributes are now checked more strictly,][96885] which may introduce errors for invalid attribute arguments that were previously ignored. <ins> - [Rounding is now used when converting a float to a `Duration`.][96051] The converted duration can differ slightly from what it was. </ins> Internal Changes ----------------

<!-- 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. --- ~Related release note: ~Related PR: ~ ~Though the PR describes the change is related to improve its truncation better, the changed behavior is rounding up which was down before.~ EDIT: The upper changes and issue . It is not related to this issue. I want to check if this is expected change or regression. I tried this code: I expected to see this happen: explanation Until 1.62.1, Instead, this happened: explanation In 1.63.0, <!-- Provide the most recent version this worked on, for example: It most recently worked on: Rust 1.47 --It most recently worked on: Until 1.62.1 <!-- Provide the version you are using that has the regression. --:
-- that PR you linked landed in 1.60, not 1.63?
Oh, I am sorry. I probably didn't check how much I scrolled down from release note. Then which change would be related?


Question: the string entered with a fuzzy matching algorithm that is tolerant of minor typos. <del> By default, the search results give are "In Names", </del> <ins> By default, the search results given are "In Names", </ins> meaning that the fuzzy match is made against the names of items. Matching names are shown on the left, and the first few words of their descriptions are given on the right.

Rustdoc has accumulated a handful of settings that users can toggle as they read docs, but we don't document them anywhere. It would be ideal if we had some documentation about these options in the Rustdoc Book that described their functionality better than the short descriptions shown on the settings page itself. !
I don't mind picking this up, unless you want to do this yourself! I do however have some questions!: The Rustdoc book you mean is right? Do you suggest adding a new section to this book or would you include it in an already existing section? What do you believe is not clear / elaborated enough in the short descriptions? I do not know the specific details of each switch are there any side-effects that are not in the short description?
Triage: no changes. The rustdoc book is that one, ! I am not a rustdoc maintainer these days (cc ) but I would probably make a new section. While the short description is good, I think it would make sense to show the options in slightly more detail, for example, maybe a before/after.
Bit of a late reply :) Do you have something to add to this? Otherwise I will follow what Steve said!


Question: <ins> // Generalizes the suggestion introduced in #100838 trait Foo<T> { fn bar(&self, _: T); } impl Foo<i32> for i32 { fn bar(&self, x: i32) { println!("{}", self + x); } } fn main() { 1.bar::<i32>(0); //~^ ERROR this associated function takes 0 generic arguments but 1 generic argument was supplied //~| HELP consider moving this generic argument to the `Foo` trait, which takes up to 1 argument //~| HELP remove these generics } </ins>

Repros on the /current nightly. But works (gives an error about mismatched number of generic arguments) on stable and beta. s/o to for the minimal example. : <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
label regression-from-stable-to-nightly
Regressed in (nightly-2022-09-02), presumably , though seems to have already made the connection to that PR anyways :-)


Question: |              not allowed in type signatures |              help: replace `_` with the correct type: `i32` <del> error: aborting due to 66 previous errors </del> <ins> error: aborting due to 67 previous errors </ins> Some errors have detailed explanations: E0121, E0282, E0403. For more information about an error, try `rustc --explain E0121`.

First time filing a bug report, apologies if i missed anything or if this is a duplicate. Encountered this bug while writing some non-sensical associated function types. Searched around for any similar issues and the closest i found was , seems closely related? Minimal example: Playground link: The ICE happens on all channels it seems
Yes, I think so too. The snippet is rejected as expected on 1.42 but ICE occurs instead since 1.43.
Assigning as and removing .


Question: /// * if `path` has a root but no prefix (e.g., `windows`), it ///   replaces everything except for the prefix (if any) of `self`. /// * if `path` has a prefix but no root, it replaces `self`. <ins> /// * if `self` has a verbatim prefix (e.g. `?C:windows`) ///   and `path` is not empty, the new path is normalized: all references ///   to `.` and `..` are removed. </ins> /// /// # Examples ///

<!-- 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: Both assertions succeed. Instead, this happened: The second assertion fails, likely due to : Although adding a separator when pushing an empty path is debatable, the behavior should probably be consistent for verbatim and non-verbatim paths. This change caused to . I can add an inefficient workaround, but is this change intentional? <!-- Provide the most recent version this worked on, for example: It most recently worked on: Rust 1.47 --It most recently worked on: 1.56.0-beta.4 <!-- Provide the version you are using that has the regression. --: modify labels: +regression-from-stable-to-nightly -regression-untriaged +O-windows cc
This is an interesting case. The normpath crate has its own path push function to work around the issue of verbatim paths not working with PathBuf::push(), which is exactly the same issue that my PR was trying to solve upstream. The normpath push() function uses pathbuf push function to append a directory separator by calling . Since the pathbuf push now already returns normalized paths (for verbatim paths) this no longer works. I've created a PR on normpath to fix the issue there: So since verbatim paths have special handling to ensure the returned path normalized, yes there are differences. If you call on a verbatim path, then the path will remain unchanged, otherwise it would not be valid any more. We cannot expect push to work the same on verbatim paths as on non-verbatim paths, verbatim paths must be normalized.
Hm, should this not be special cased so that it works the same for all paths? Otherwise the only way to push a trailing separator is to convert to an , push the separator and then convert back to a . IMHO, ideally this would be fixed in so that trailing slashes are never normalized away but I'm uncertain if that change will be accepted.
We could special case it so that is a no-op in all cases.
Would this break existing code though?
on second thought, maybe you are right. Let me see what I can do.


Question: <ins> // check-pass // compile-flags: --edition 2018 #![feature(try_blocks)] #![warn(unused_parens, unused_braces)] fn consume<T>(_: Result<T, T>) -> T { todo!() } fn main() { consume((try {})); //~^ WARN unnecessary parentheses consume({ try {} }); //~^ WARN unnecessary braces match (try {}) { //~^ WARN unnecessary parentheses Ok(()) | Err(()) => (), } if let Err(()) = (try {}) {} //~^ WARN unnecessary parentheses match (try {}) { //~^ WARN unnecessary parentheses Ok(()) | Err(()) => (), } } </ins>

This produces a lint: But removing the parentheses produces an error. This bug was already mentioned in , but that issue is lost in feature-request purgatory since it asks for the version without parentheses to be allowed. I'm opening this issue to track the incorrect lint specifically. (Edit: Fixed the example.) <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim Will wait for to get merged before this is fixed though.


Question: <ins> // check-pass // compile-flags: --edition 2018 #![feature(try_blocks)] #![warn(unused_parens, unused_braces)] fn consume<T>(_: Result<T, T>) -> T { todo!() } fn main() { consume((try {})); //~^ WARN unnecessary parentheses consume({ try {} }); //~^ WARN unnecessary braces match (try {}) { //~^ WARN unnecessary parentheses Ok(()) | Err(()) => (), } if let Err(()) = (try {}) {} //~^ WARN unnecessary parentheses match (try {}) { //~^ WARN unnecessary parentheses Ok(()) | Err(()) => (), } } </ins>

The following code fails to compile (): The compiler error is: Adding parentheses or braces, it will compile fine: The same issue happens with other constructs such as:
cc
I believe the error is expected here, the same as with : Which also needs to be to compile. That said, the warning to remove the necessary parens is definitely wrong. EDIT: Hmm, I might be wrong, actually. The following compiles, which surprised me: as does this: So maybe the parser restriction is only for struct literals, not for keyword-introduced expressions.
Yeah I think is the better comparison here so it's probably a bug.
This is exactly what a thought. I didn't know that this:
For , hmmm... well, I can't come up with a truly devastating example, but eliminating the parentheses could hurt diagnostics.


Question: && this.token.kind == token::Semi { TrailingToken::Semi <ins> } else if this.token.kind == token::Gt { TrailingToken::Gt </ins> } else { // FIXME - pass this through from the place where we know // we need a comma, rather than assuming that `#[attr] expr,`

Found with The attribute applies to The was initially lexed as part of a token This seems to be exactly the case described by the : <details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Do you have any suggestion for this case? The code path is going like this: Parser eat the first one of '' at here and set : fall pass at here: So this assertion is failed: The result is: and is true. Seems the assertion missed this scenario, do we need to add a TrailingToken::Gt ?
The assertion I wrote is overly conservative - it really just needs to check that we don't simultaneously break a token and 'really' capture a trailing token. Specifically, we only need to panic if we actually incremented in the match block. I think the simplest fix would be to add a variable, which gets set to in the parts of the block that increment . The assertion can then be changed to breaklasttoken


Question: <ins> error: overflow evaluating associated type `Carrier<'b>::Focus<i32>` --> $DIR/issue-111879-0.rs:11:25 | LL |     pub type Focus<T> = &'a mut User; |                         ^^^^^^^^^^^^ error: aborting due to previous error </ins>

<!-- 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 --
cc is this fixed by one of your PRs? This looked like it might be , but while was bisected to this one was bisected to , not sure what to make of it :thinking:
Yes, this issue is fixed in (ice → errors): <details<summarystderr</summary</detailsI'm not sure why the bisection points differ, they all share the same root cause. It doesn't really matter though. Btw, I saw about another new reproducer but I dismissed it as irrelevant since I assumed it required , too (I did run it but didn't notice I could omit that flag). Sorry about that. Thanks for opening a separate issue because now we actually have 2 beautiful regression tests for the bug fixed in ! So let's not close this issue then but wait for to get merged and then I will open a separate PR with the regression tests & assign you. claim


Question: extern fn on_tcp_read_cb(stream: *uv::ll::uv_stream_t, nread: libc::ssize_t, <del> ++buf: uv::ll::uv_buf_t) { </del> <ins> buf: uv::ll::uv_buf_t) { </ins> unsafe { debug!("entering on_tcp_read_cb stream: %? nread: %?", stream, nread);

This function still takes its argument by explicit .
also,
I'm doing this, just waiting for tests.
Done, pending
Fixed in


Question: pub const tag_impl_coerce_unsized_kind: usize = 0xa5; pub const tag_items_data_item_constness: usize = 0xa6; <ins> pub const tag_rustc_version: usize = 0x10f; pub fn rustc_version() -> String { format!( "rustc {}", option_env!("CFG_VERSION").unwrap_or("unknown version") ) } </ins>

When trying to update uutils/coreutils to HEAD, I got this ICE: Version: code:
apparently, this happens as a side effect of the build process. i had built with stable, then tried to build with nightly, giving incorrect metadata


Question: <ins> // Copyright 2015 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 foo(x: i32) { |y| x + y //~^ ERROR: mismatched types: //~| expected `()`, //~|     found closure //~| (expected (), //~|     found closure) [E0308] } fn main() { let x = foo(5)(2); //~^ ERROR: expected function, found `()` } </ins>

Minimised example: Both the and the fail in the same way, with an ICE: Adding bounds to and on the trait or in the fn’s where clause doesn’t fix it, but changing to does fix it. (In the particular case that I was dealing with, the lifetime could_ be changed to where this was a problem, but it would only have taken a slight variation of it for me to be in a situation where I needed a non- implementation. There were, of course, other arguments which were using the .) The whole thing around there seems a bit fragile and I’m not quite sure what’s supposed to work and what’s not; if we just take an and transmute it to , for example, we get “error: cannot transmute to or from a type that contains type parameters in its interior [E0139]”. Anyway, an ICE is always a bug, so here’s the report!
No longer repros. compiles now. Fails with: But no ICE.


Question: <ins> // Copyright 2015 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 foo(x: i32) { |y| x + y //~^ ERROR: mismatched types: //~| expected `()`, //~|     found closure //~| (expected (), //~|     found closure) [E0308] } fn main() { let x = foo(5)(2); //~^ ERROR: expected function, found `()` } </ins>

While trying to learn how to return a closure.... I came across this.. gives....
Commenting-out the body of still results in an ICE.
I can't seem to produce an ICE no matter what I do.
Those closure kinds info are already gone, so I think many related bugs are gone as well. e.g. I cannot reproduce a bug related to closure kinds and macro


Question: <ins> //@ check-pass //@ aux-build: another-proc-macro.rs //@ compile-flags: -Zunpretty=expanded #![feature(derive_smart_pointer)] #[macro_use] extern crate another_proc_macro; use another_proc_macro::{pointee, AnotherMacro}; #[derive(core::marker::SmartPointer)] #[repr(transparent)] pub struct Ptr<'a, #[pointee] T: ?Sized> { data: &'a mut T, } #[pointee] fn f() {} #[derive(AnotherMacro)] #[pointee] struct MyStruct; fn main() {} </ins>

https://crater- https://crater- cc <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
cc
label F-derivesmartpointer
Thread on zulip: https://rust-
claim
WG-prioritization assigning priority (). label -I-prioritize +P-high


Question: /// The default panic handler. fn default_hook(info: &PanicInfo<'_>) { <del> panic_hook_with_disk_dump(info, None) } #[unstable(feature = "ice_to_disk", issue = "none")] /// The implementation of the default panic handler. /// /// It can also write the backtrace to a given `path`. This functionality is used only by `rustc`. pub fn panic_hook_with_disk_dump(info: &PanicInfo<'_>, path: Option<&crate::path::Path>) { </del> // If this is a double panic, make sure that we print a backtrace // for this panic. Otherwise only print it if logging is enabled. let backtrace = if info.force_no_backtrace() {

slightly increased default binary size (checked on x8664-pc-windows-msvc), the reason is now code unconditionally includes File::open (~ 2kb out of 130) and friends. can be tracked back by new imports of , for where is Originally posted by in
cc
cc -- I'm surprised that didn't include any libs review in the first place, having modified the default panic hook. Maybe ought to be registering its own panic hook instead?
Size changed back to 123kb.


Question: /// # Example /// /// ```rust <ins> /// # #![allow(deprecated)] </ins> /// use url::decode; /// /// let url = decode("https://example.com/Rust%20(programming%20language)");

The common fix for , , and is to rewrite the module based on the spec at and the tests at (Note: the tests assume the API, designed for JavaScript in web browsers. We do not necessarily want the same API for Rust outside of testing code.)
I'm interested in this
I have a work-in-progress implementation. I’ll publish it later today so you can pick it up if you want.
Here it is: Note that I’m targeting Rust , the version used in Servo. (Though there is an upgrade being worked on.) IDNA and the actual URL parser are not there yet, but everything else (host/domain/ipv6, , percent encoding, test harness) is there. This should start being useful as soon as the URL parser is . The host parser returns an error on non-ASCII domains. This is good enough for now, IDNA support can be later. also made an in-progress implementation: It has some known bugs ( is incorrect with non-ASCII input, at least) but the parser code can probably be reused.
Also, be aware that the URL spec itself is still moving and has a number of open bugs:
I Punycode encoding and decoding (with tests) to but not Nameprep, which is the other big part of IDNA.
is now (IMHO) ready to replace . It is not "done" yet (some bugs remain, including in the spec!), but at this point it has more than feature-parity and is probably correct in more corner cases. Given the current tendency to move things out of , rust-url probably shouldn’t move in. It could be distributed with rustc like the rest of the modules moving out of extra, but this has the downside of tying rust-url upgrades to compiler upgrades, and only weak advantages IMO. So, whenever the Rust team decides it’s appropriate, I suggest removing and recommending rust-url as a replacement.
I would generally be in favor of a in the distribution for now. This would certainly not be a package in long-term, but for now putting everything in this repo is the ad-hoc solution we have until we get a real package manager.
In that case, I’d like to iterate a bit on rust-url (port rust-http and Servo to it, …) before it moves into the distribution. Also, rust-url depends on rust-encoding, which I guess would have to move as well.


Question: /// # Example /// /// ```rust <ins> /// # #![allow(deprecated)] </ins> /// use url::decode; /// /// let url = decode("https://example.com/Rust%20(programming%20language)");

I’d say rust-url is now in "beta" state. I have branches of rust-http and Servo using it: It builds with Cargo. It depends on rust-encoding (which also builds with Cargo), but for something non-essential that could be deactivated if avoiding the additional dependency helps. I’d like people to start using it and give feedback. I think the best way to do that is to get rid of the old liburl. I’ll go through the RFC process, but before that, what would you prefer? Replace liburl with snapshots[] of rust-url. You were in favor of this in February, but Cargo has reached alpha since then. Just remove liburl, and tell people to use rust-url through Cargo. Something else? [] In any case, I’d like to keep a separate rust-url repository that I can update in Servo independently of language upgrades.
+1 on removing liburl. Thanks
Perhaps we can deprecate all of liburl for one release cycle.
This seems like a great place to let cargo shine.
Deprecating sounds reasonable. That means emitting warnings by default, right?
awesome work! I agree with and that I think this is where cargo shines, and we can probably just remove liburl entirely without re-adding rust-url. We can also try to grow more official support for it in terms of documentation and automation (not present currently). We can mark liburl as with a message to use instead which should ferry everyone along quickly.


Question: assert: (".sidebar-elems > .items > ul > li:nth-child(3)", "Enums") assert: (".sidebar-elems > .items > ul > li:nth-child(4)", "Traits") assert: (".sidebar-elems > .items > ul > li:nth-child(5)", "Functions") <del> assert: (".sidebar-elems > .items > ul > li:nth-child(6)", "Keywords") </del> <ins> assert: (".sidebar-elems > .items > ul > li:nth-child(6)", "Type Definitions") assert: (".sidebar-elems > .items > ul > li:nth-child(7)", "Keywords") </ins> assert: ("#structs + table td > a", "Foo") click: "#structs + table td > a"

: Local docs: ! But has the same issue: Probably caused by: ()
It seems like this css rule: applies to this element: !. Before () this rule wouldn't have applied because it would've been contrained by instead of .
This also had some other side-effects here: ! The search results have top/bottom margins compared to the previous styling.
The second issue was fixed in I'm checking for the first one, unless you want to send a PR?
Hmm, sorry I didn't/don't have much time to dig into this more. I couldn't think of an immediate fix for this because it kinda looked non-trivial (to me) :/
Don't worry, I'll send a fix in the next hours then.


Question: /// Writes to a fixed-size byte slice <ins> /// /// If a write will not fit in the buffer, it raises the `io_error` /// condition and does not write any data. </ins> pub struct BufWriter<'self> { priv buf: &'self mut [u8], priv pos: uint

Currently all of its functions immediately . We need to either remove this or implement it. I vote for implementing it.


Question: <del> Subproject commit ae964207bb17911cf96d9744d9469fa2734093a8 </del> <ins> Subproject commit 12dac5c0f7acd106401aa14fec758f0ff552f678 </ins>

Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool miri no longer builds. A follow-up PR to the repository is needed to fix the fallout. cc do you think you would have time to do the follow-up work? If so, that would be great!
It looks like miri just has one instance of , which should be replaced with . Should be easy enough.
This can be closed when the miri submodule is bumped.


Question: AtomicOrderingFence, AtomicOrderingLoad, AtomicOrderingStore, ImproperCTypes, InvalidAtomicOrderingDiag, OnlyCastu8ToChar, OverflowingBinHex, OverflowingBinHexSign, OverflowingBinHexSub, OverflowingInt, OverflowingIntHelp, OverflowingLiteral, <del> OverflowingUInt, RangeEndpointOutOfRange, UnusedComparisons, VariantSizeDifferencesDiag, </del> <ins> OverflowingUInt, RangeEndpointOutOfRange, UnusedComparisons, UseInclusiveRange, VariantSizeDifferencesDiag, </ins> }, }; use crate::{LateContext, LateLintPass, LintContext};

<!-- 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. --I tried this code: I expected to see this happen: printing all numbers from 0 to 255 (inclusive) Instead, this happened: : <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
The error is correct, 256 is indeed out of range for u8. You need to use .
You can run that code if you want, by allowing the lint: if you do you'll see that it will print nothing because the overflows and becomes , so it's which is empty. Examples like this where allowing the literal overflow would do something you don't want are exactly why this lint is deny-by-default
I've renamed this issue because the lint is correct. If there's anything to be done here, it would be to add a range-specific suggestion for this situation to help guide towards the correct code.
claim


Question: <ins> `async fn`s are not yet supported in traits in Rust. Erroneous code example: ```compile_fail,edition2018 trait T { // Neither case is currently supported. async fn foo() {} async fn bar(&self) {} } ``` `async fn`s return an `impl Future`, making the following two examples equivalent: ```edition2018,ignore (example-of-desugaring-equivalence) async fn foo() -> User { unimplemented!() } // The async fn above gets desugared as follows: fn foo(&self) -> impl Future<Output = User> + '_ { unimplemented!() } ``` But when it comes to supporting this in traits, there are [a few implementation issues][async-is-hard]. One of them is returning `impl Trait` in traits is not supported, as it would require [Generic Associated Types] to be supported: ```edition2018,ignore (example-of-desugaring-equivalence) impl MyDatabase { async fn get_user(&self) -> User { unimplemented!() } } impl MyDatabase { fn get_user(&self) -> impl Future<Output = User> + '_ { unimplemented!() } } ``` Until these issues are resolved, you can use the [`async-trait` crate], allowing you to use `async fn` in traits by desugaring to "boxed futures" (`Pin<Box<dyn Future + Send + 'async>>`). Note that using these trait methods will result in a heap allocation per-function-call. This is not a significant cost for the vast majority of applications, but should be considered when deciding whether to use this functionality in the public API of a low-level function that is expected to be called millions of times a second. You might be interested in visiting the [async book] for further information. [`async-trait` crate]: https://crates.io/crates/async-trait [async-is-hard]: https://smallcultfollowing.com/babysteps/blog/2019/10/26/async-fn-in-traits-are-hard/ [Generic Associated Types]: https://github.com/rust-lang/rust/issues/44265 [async book]: https://rust-lang.github.io/async-book/07_workarounds/06_async_in_traits.html </ins>

we currently emit We should tell people that trait functions are not possible , and possibly point them to . <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Created


Question: <ins> error: invalid const generic expression --> $DIR/issue-103143.rs:2:13 | LL |     x::<#[a]y::<z>> |             ^^^^^^ | help: expressions must be enclosed in braces to be used as const generic arguments | LL |     x::<#[a]{ y::<z> }> |             +        + error[E0425]: cannot find value `x` in this scope --> $DIR/issue-103143.rs:2:5 | LL |     x::<#[a]y::<z>> |     ^ not found in this scope error: aborting due to 2 previous errors For more information about this error, try `rustc --explain E0425`. </ins>


Question: } } <del> // Maybe add libLLVM.so to the lib-dir. It will only have been built if // LLVM tools are linked dynamically. // // We add this to both the libdir of the rustc binary itself (for it to load at // runtime) and also to the target directory so it can find it at link-time. // // Note: This function does no yet support Windows but we also don't support //       linking LLVM tools dynamically on Windows yet. pub fn maybe_install_llvm_dylib(builder: &Builder<'_>, target: Interned<String>, sysroot: &Path) { </del> <ins> /// Maybe add libLLVM.so to the given destination lib-dir. It will only have /// been built if LLVM tools are linked dynamically. /// /// Note: This function does not yet support Windows, but we also don't support ///       linking LLVM tools dynamically on Windows yet. fn maybe_install_llvm(builder: &Builder<'_>, target: Interned<String>, dst_libdir: &Path) { </ins> let src_libdir = builder.llvm_out(target).join("lib"); <del> let dst_libdir1 = sysroot.join("lib/rustlib").join(&*target).join("lib"); let dst_libdir2 = sysroot.join(builder.sysroot_libdir_relative(Compiler { stage: 1, host: target })); t!(fs::create_dir_all(&dst_libdir1)); t!(fs::create_dir_all(&dst_libdir2)); </del> if target.contains("apple-darwin") { let llvm_dylib_path = src_libdir.join("libLLVM.dylib"); if llvm_dylib_path.exists() { <del> builder.install(&llvm_dylib_path, &dst_libdir1, 0o644); builder.install(&llvm_dylib_path, &dst_libdir2, 0o644); </del> <ins> builder.install(&llvm_dylib_path, dst_libdir, 0o644); </ins> } return; }

Since , has been distributed in the component in two locations: (presumably as a runtime dependency of ) (not sure, maybe for linking custom drivers?) likely belongs in the component, if the duplication can't be avoided <hr/The difference can be seen in these consecutive nightlies' components: has just the second maybe it's used via relative by ? separate codegen backends are gone, maybe we should just try removing it? first nightly to include has both copies All 3 of those files are identical (even across nightlies, yay for deterministic builds): One fascinating aspect is that the size only increases from to , despite alone being uncompressed, so compression is really helping. Even the only goes from to . (I'm using archive sizes from the and directory listings in , FWIW) <hr/This part of the build system seems relevant, but I'm not sure which of the two this creates: cc
cc -- you've touched code related to this a bunch recently I think, so maybe would have some time to investigate fixing this. I suspect we want to only ship one LLVM per tarball, at least, though ideally we would only have just the one LLVM library total as well.
Half-way through writing up this issue I realized the connection. I'd suggest we try to get rid of the copy and see what breaks, it's possible it's been dead weight for a while now. And only if we have to keep both for some odd reason, we'd move it to .
The purposely orders the tarred files so that similar filenames are adjacent in the compression stream, especially in hope of helping with such duplicate files. I think we may still want the copy for the odd cross-compiled tool using , but that definitely belongs in .
Is that... even possible? Is a per-target component in the same way is?
Yes it is -- try -- but I don't know if anyone really needs that...
Actually, can you try something like cross-compiling a copy of to , after deleting the per-target ? I suspect that it would actually run just fine on a host, because 's s should only really contain the information and maybe some object code that is missing (which we could get rid of if we kept MIR for everything but idk how feasible that is). That is, the result of linking against should still use at runtime, so in is unnecessary. But maybe I'm missing something.


Question: } } <del> // Maybe add libLLVM.so to the lib-dir. It will only have been built if // LLVM tools are linked dynamically. // // We add this to both the libdir of the rustc binary itself (for it to load at // runtime) and also to the target directory so it can find it at link-time. // // Note: This function does no yet support Windows but we also don't support //       linking LLVM tools dynamically on Windows yet. pub fn maybe_install_llvm_dylib(builder: &Builder<'_>, target: Interned<String>, sysroot: &Path) { </del> <ins> /// Maybe add libLLVM.so to the given destination lib-dir. It will only have /// been built if LLVM tools are linked dynamically. /// /// Note: This function does not yet support Windows, but we also don't support ///       linking LLVM tools dynamically on Windows yet. fn maybe_install_llvm(builder: &Builder<'_>, target: Interned<String>, dst_libdir: &Path) { </ins> let src_libdir = builder.llvm_out(target).join("lib"); <del> let dst_libdir1 = sysroot.join("lib/rustlib").join(&*target).join("lib"); let dst_libdir2 = sysroot.join(builder.sysroot_libdir_relative(Compiler { stage: 1, host: target })); t!(fs::create_dir_all(&dst_libdir1)); t!(fs::create_dir_all(&dst_libdir2)); </del> if target.contains("apple-darwin") { let llvm_dylib_path = src_libdir.join("libLLVM.dylib"); if llvm_dylib_path.exists() { <del> builder.install(&llvm_dylib_path, &dst_libdir1, 0o644); builder.install(&llvm_dylib_path, &dst_libdir2, 0o644); </del> <ins> builder.install(&llvm_dylib_path, dst_libdir, 0o644); </ins> } return; }

Like running the cross-compiled on a host without anything more than the component?
Hmm, I can't actually get cross-builds to work with . I this to : ... so it would pick that up from the sysroot. Trying to cross-compile i686, I get: I do have both i686 and x8664 builds of in the sysroot. I suspect the error is because the i686 build has different metadata than my host build, so it can't find the one it wants for the host. That may mean that is really tied to being used on the same host. It works if I just compile native x86_64 though. Then I tried removing the , and it gets essentially the same error as : AFAICS, building normal crates still works fine with that extra removed though. In short: Cross-compiling with seems broken -- maybe it should be shipped native-only. The only difference would be in the manifest created for rustup. Linking to crates will inherit , so that needs to be in the library path.
Ah, fascinating. What happens if you build such an executable and then remove the component entirely? Can it pick up the dylibs outside or does it hardcode the paths inside?
The final executable still isn't actually linked to LLVM, since it didn't need any of those symbols: I can run this with , which set , or even if I set that path myself. But doesn't work if we've removed that library, since needs itself.
Okay, it being dependent on makes sense. Overall, probably the safe thing to do would be to move the duplicate to , oh well.
Oh, also needs LLVM, and those binaries are installed in with RUNPATH . I guess they might be able to find the LLVM in anyway?


Question: } impl<'self> Writer for BufWriter<'self> { <del> fn write(&mut self, _buf: &[u8]) { fail!() } </del> <ins> fn write(&mut self, buf: &[u8]) { // raises a condition if the entire write does not fit in the buffer let max_size = self.buf.len(); if self.pos >= max_size || (self.pos + buf.len()) > max_size { io_error::cond.raise(IoError { kind: OtherIoError, desc: "Trying to write past end of buffer", detail: None }); return; } </ins> <del> fn flush(&mut self) { fail!() } </del> <ins> vec::bytes::copy_memory(self.buf.mut_slice_from(self.pos), buf, buf.len()); self.pos += buf.len(); } </ins> } <ins> // FIXME(#10432) </ins> impl<'self> Seek for BufWriter<'self> { <del> fn tell(&self) -> u64 { fail!() } </del> <ins> fn tell(&self) -> u64 { self.pos as u64 } </ins> <del> fn seek(&mut self, _pos: i64, _style: SeekStyle) { fail!() } </del> <ins> fn seek(&mut self, pos: i64, style: SeekStyle) { // compute offset as signed and clamp to prevent overflow let offset = match style { SeekSet => { 0 } SeekEnd => { self.buf.len() } SeekCur => { self.pos } } as i64; self.pos = max(0, offset+pos) as uint; } </ins> }


Question: assert_eq!(copy(&mut r as &mut dyn Read, &mut w as &mut dyn Write).unwrap(), 1 << 17); } <ins> struct ShortReader { cap: usize, read_size: usize, observed_buffer: usize, } impl Read for ShortReader { fn read(&mut self, buf: &mut [u8]) -> Result<usize> { let bytes = min(self.cap, self.read_size); self.cap -= bytes; self.observed_buffer = max(self.observed_buffer, buf.len()); Ok(bytes) } } struct WriteObserver { observed_buffer: usize, } impl Write for WriteObserver { fn write(&mut self, buf: &[u8]) -> Result<usize> { self.observed_buffer = max(self.observed_buffer, buf.len()); Ok(buf.len()) } fn flush(&mut self) -> Result<()> { Ok(()) } } #[test] fn copy_specializes_bufwriter() { let cap = 117 * 1024; let buf_sz = 16 * 1024; let mut r = ShortReader { cap, observed_buffer: 0, read_size: 1337 }; let mut w = BufWriter::with_capacity(buf_sz, WriteObserver { observed_buffer: 0 }); assert_eq!( copy(&mut r, &mut w).unwrap(), cap as u64, "expected the whole capacity to be copied" ); assert_eq!(r.observed_buffer, buf_sz, "expected a large buffer to be provided to the reader"); assert!(w.get_mut().observed_buffer > DEFAULT_BUF_SIZE, "expected coalesced writes"); } </ins> #[test] fn sink_sinks() { let mut s = sink();

I was using std::io::copy from an SSD to memory using , which reported an eye-raising 30 MB/s. Wrapping it in a BufReader (either as the outer or middle layer) made no real difference. So I googled around a bit and found the recommended size was 64KB according to some random Microsoft article, so I decided to copy-paste the std::io::copy implementation and increase the buffer size. This got up to 600 MB/s at about 256KB which sounded a lot more it continued going upwards from there past the point of believability (unless the files were being pulled from RAM as a consequence of my repeated accesses). With a 10MB Vec, I got 228.36 GB/s . Unrealistic values aside, has anybody checked the buffer value to make sure there isn't some huge low-hanging fruit for std::io::copy speeds?
You mention windows. This may be platform-specific behavior. On unix systems I would fadvise on the input file for copying. Googling tells me that the windows equivalent is . Have you tried that?
After a coarse overview, my intuition is that there is some funny business going on with the length determined by and the subsequent calls on the , that could explain the unrealistic results.
It’s possible. The actual times did increase dramatically from the std::io::copy default though - my suspicion is that there is probably some caching to RAM going on or something as cold runs were generally slower than hot runs. This was for some work code that I’m no longer actively developing. I’ll leave this email marked as unread for awhile in case I have some spare time to write a benchmark. I don’t think the other flag that was mentioned is accessible with the default open file api, but in any case it at least appears there’s some low hanging fruit wrt to std::io::copy perf
I tried benchmarking on Windoze before and after changing to (instead of the original ) and the results were slightly worse (up to ~3%) with the modified setup, both on HDD and SSD. However, I'm not sure if my benchmarks were good enough - I was having a hard time tweaking them so that I could see any difference between results for different file sizes.


Question: assert_eq!(copy(&mut r as &mut dyn Read, &mut w as &mut dyn Write).unwrap(), 1 << 17); } <ins> struct ShortReader { cap: usize, read_size: usize, observed_buffer: usize, } impl Read for ShortReader { fn read(&mut self, buf: &mut [u8]) -> Result<usize> { let bytes = min(self.cap, self.read_size); self.cap -= bytes; self.observed_buffer = max(self.observed_buffer, buf.len()); Ok(bytes) } } struct WriteObserver { observed_buffer: usize, } impl Write for WriteObserver { fn write(&mut self, buf: &[u8]) -> Result<usize> { self.observed_buffer = max(self.observed_buffer, buf.len()); Ok(buf.len()) } fn flush(&mut self) -> Result<()> { Ok(()) } } #[test] fn copy_specializes_bufwriter() { let cap = 117 * 1024; let buf_sz = 16 * 1024; let mut r = ShortReader { cap, observed_buffer: 0, read_size: 1337 }; let mut w = BufWriter::with_capacity(buf_sz, WriteObserver { observed_buffer: 0 }); assert_eq!( copy(&mut r, &mut w).unwrap(), cap as u64, "expected the whole capacity to be copied" ); assert_eq!(r.observed_buffer, buf_sz, "expected a large buffer to be provided to the reader"); assert!(w.get_mut().observed_buffer > DEFAULT_BUF_SIZE, "expected coalesced writes"); } </ins> #[test] fn sink_sinks() { let mut s = sink();

FWIW, I'm providing the benchmark code below; it can easily be expanded to different file sizes:
4MB isn’t a whole lot. That’s well within the size of hard drive caches or possibly an OS memory-based cache. I was noticing the difference with files several gigabytes in size. As a sanity check, maybe look to see what the actual time is, not just the % difference between timings with different buffer sizes. The actual time may be wildly different than the actual steady state performance of the disk if it’s reading the data from a cache. It may also be possible at a low level to pass a flag to encourage the OS to disable or flush the cache, but I don’t know if there’s any way to instruct the hard drive to do the same.
I only pasted the benchmark for 4MB as a reference - I tested files from 4KB up to 16MB. I'm not an expert with low-level hard drive stuff, just hoping my attempt can help someone else.
Ideally you would test with a file approximately twice as big as you have RAM, so if you have 8GB of RAM you would want to test with a 16GB file.
extended open flags are accessible via FWIW lots of bennchmarks exist showing synchronous IO calls improve when matching IO operations to the underlying block size (e.g. 4MB for modern SSD's) across multiple OS's, so its very likely that there are improvements to gain here. However, 4MB is stack-breaking size by default, and heap allocations will destroy potential improvements (and further, if we're optimising, we probably want overlapped IO and a ring of buffers rather than just one buffer which will always leave one device idle).... so its complex;)
heap allocations will destroy potential improvements How come? would allocate once at the beginning. Heap memory isn't inherently slower and one memory allocation is basically free compared to the heavy IO that's happening afterwards.
But we also don't want to be allocating 4MB every time we do as someone might be doing a bunch of small copies.


Question: assert_eq!(copy(&mut r as &mut dyn Read, &mut w as &mut dyn Write).unwrap(), 1 << 17); } <ins> struct ShortReader { cap: usize, read_size: usize, observed_buffer: usize, } impl Read for ShortReader { fn read(&mut self, buf: &mut [u8]) -> Result<usize> { let bytes = min(self.cap, self.read_size); self.cap -= bytes; self.observed_buffer = max(self.observed_buffer, buf.len()); Ok(bytes) } } struct WriteObserver { observed_buffer: usize, } impl Write for WriteObserver { fn write(&mut self, buf: &[u8]) -> Result<usize> { self.observed_buffer = max(self.observed_buffer, buf.len()); Ok(buf.len()) } fn flush(&mut self) -> Result<()> { Ok(()) } } #[test] fn copy_specializes_bufwriter() { let cap = 117 * 1024; let buf_sz = 16 * 1024; let mut r = ShortReader { cap, observed_buffer: 0, read_size: 1337 }; let mut w = BufWriter::with_capacity(buf_sz, WriteObserver { observed_buffer: 0 }); assert_eq!( copy(&mut r, &mut w).unwrap(), cap as u64, "expected the whole capacity to be copied" ); assert_eq!(r.observed_buffer, buf_sz, "expected a large buffer to be provided to the reader"); assert!(w.get_mut().observed_buffer > DEFAULT_BUF_SIZE, "expected coalesced writes"); } </ins> #[test] fn sink_sinks() { let mut s = sink();

possible approaches: thread local buffers or a buffer pool stat the input before deciding on the buffer size (this is what gnu cp does I think) heap-allocate a bigger buffer after a few iterations of the copy loop with an on-stack buffer specialize copy operations from file to memory to directly into the already allocated target, thus skipping the need for a buffer
specialize copy operations from file to memory to directly into the already allocated target, thus skipping the need for a buffer I think some kind of specialization for sources would be ideal. Because in this case, should not buffer at all and simply use the reader's buffer. Effectively this also gives you a customizable buffer size by wrapping your in a with whatever size you want. As of today, if your source is then is always the wrong answer. I got a substantial performance improvement using a simple loop instead:
a single heap allocation is entirely reasonable for a single invocation of copy of a lot of data. For many copies of a small amount of data, one ends up with a lot of allocations again (consider for instance copying data out of a tar, where we have views on the data and there's no actual synchronous IO etc happening. I like some of the suggested possibilities with specialisation.
It's a nice general optimization, but not necesarily ideal if you use a as . Adding a on the reader size does let you control the buffer size but it still introduces an unnecessary memcopy compared to . Perhaps a writer-side optimization would be more flexible. Then you can specialize either for or
That sounds rather uncommon to me though. After all, is provided by the trait so it's always available. The only case I can see where you would invoke with a as destination is some generic interfaces that takes any . But IMO such interfaces are ill-designed, as they could simply implement instead and offer a much more flexible API.
yes, generic code taking a write was the concern. E.g. tar-rs has a tar archive which takes a and is fed with items. I'm not saying that creating an in-memory archive would be a good idea, just pointing out that these patterns do exist.
I had same kind of issue but with different library (). The copy rate was around 70 MB/s (inside single NVMe SSD). The problem was actually with running the debug version of my program.


Question: assert_eq!(copy(&mut r as &mut dyn Read, &mut w as &mut dyn Write).unwrap(), 1 << 17); } <ins> struct ShortReader { cap: usize, read_size: usize, observed_buffer: usize, } impl Read for ShortReader { fn read(&mut self, buf: &mut [u8]) -> Result<usize> { let bytes = min(self.cap, self.read_size); self.cap -= bytes; self.observed_buffer = max(self.observed_buffer, buf.len()); Ok(bytes) } } struct WriteObserver { observed_buffer: usize, } impl Write for WriteObserver { fn write(&mut self, buf: &[u8]) -> Result<usize> { self.observed_buffer = max(self.observed_buffer, buf.len()); Ok(buf.len()) } fn flush(&mut self) -> Result<()> { Ok(()) } } #[test] fn copy_specializes_bufwriter() { let cap = 117 * 1024; let buf_sz = 16 * 1024; let mut r = ShortReader { cap, observed_buffer: 0, read_size: 1337 }; let mut w = BufWriter::with_capacity(buf_sz, WriteObserver { observed_buffer: 0 }); assert_eq!( copy(&mut r, &mut w).unwrap(), cap as u64, "expected the whole capacity to be copied" ); assert_eq!(r.observed_buffer, buf_sz, "expected a large buffer to be provided to the reader"); assert!(w.get_mut().observed_buffer > DEFAULT_BUF_SIZE, "expected coalesced writes"); } </ins> #[test] fn sink_sinks() { let mut s = sink();

When I built and ran the release version, the speed jumped to over 1 GB/s.
With merged you can now (on next nightly) use to control the chunk size of . Since this relies on specialization it only works if you pass a directly, any other wrapper around it would disable this optimization.


Question: <ins> #[macro_export] macro_rules! a{ () => {}} #[macro_export] macro_rules! b{ () => {}} </ins>

Hey! Ran into what appears to be a bug - crate's exported macros each appear twice in the left sidebar: ! Toolchain versions (per log): rustc 1.60.0-nightly ( 2022-02-09), docsrs 0.6.0 ( 2022-02-01) Please let me know if I can provide additional info.
Thank you for the report! This is definitely not an issue with itself, but with rustdoc. is this known? Should a rustdoc issue be created?
Not known afaik. Please do file an issue (or transfer this one)!
Seems similar to
Thanks for transferring the issue. One difference between this and - both macros are exported using a wildcard in crate root (not rename):
Well, just another reexport issue. It's common around here. :laughing: I'll try to take a look in the next days.
This is what I have on currently nightly: ! So I guess it's fixed?
Trying locally with the latest nightly (, more current than that of issue open) I get the same initial landing page for but if I click on one of the macros listed (e.g. "drill down") duplicates still appear on the sidebar: ! So the tiny bug is still there, just deeper/hidden on the latest nightly?
Ah indeed! I can also reproduce it now. Will take another look tomorrow then.


Question: <ins> // Copyright 2015 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 f<F, R>(_: F) where F: Fn() -> R { } fn main() { f(|| -> ! { () }); //~^ ERROR: computation may converge in a function marked as diverging [E0270] } </ins>

Minimised example: Both the and the fail in the same way, with an ICE: Adding bounds to and on the trait or in the fn’s where clause doesn’t fix it, but changing to does fix it. (In the particular case that I was dealing with, the lifetime could_ be changed to where this was a problem, but it would only have taken a slight variation of it for me to be in a situation where I needed a non- implementation. There were, of course, other arguments which were using the .) The whole thing around there seems a bit fragile and I’m not quite sure what’s supposed to work and what’s not; if we just take an and transmute it to , for example, we get “error: cannot transmute to or from a type that contains type parameters in its interior [E0139]”. Anyway, an ICE is always a bug, so here’s the report!
No longer repros. compiles now. Fails with: But no ICE.


Question: <ins> // Copyright 2015 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 f<F, R>(_: F) where F: Fn() -> R { } fn main() { f(|| -> ! { () }); //~^ ERROR: computation may converge in a function marked as diverging [E0270] } </ins>

While trying to learn how to return a closure.... I came across this.. gives....
Commenting-out the body of still results in an ICE.
I can't seem to produce an ICE no matter what I do.
Those closure kinds info are already gone, so I think many related bugs are gone as well. e.g. I cannot reproduce a bug related to closure kinds and macro


Question: id: ast::NodeId, span: syntax_pos::Span, name: ast::Name, <del> node_type: &str) { </del> <ins> node_type: &str, participle: &str) { </ins> if !name.as_str().starts_with("_") { self.tcx .lint_node(lint::builtin::DEAD_CODE, id, span, <del> &format!("{} is never used: `{}`", node_type, name)); </del> <ins> &format!("{} is never {}: `{}`", node_type, participle, name)); </ins> } } }

I was changing some code from integer constants to a proper enum and was greeted by the following warning: The warning sounded weird to me because I was pattern-matching on that damn variant in various places of the code; but I was pointed out to the fact that I wasn't actually creating that value. Maybe the warning should be rewritten to explicitly mention value creation? Cc
cc that looks like your thing
duplicate of
Yup! Closing in favor of that.


Question: [submodule "src/llvm-project"] path = src/llvm-project url = https://github.com/rust-lang/llvm-project.git <del> branch = rustc/17.0-2023-07-29 </del> <ins> branch = rustc/17.0-2023-09-19 </ins> shallow = true [submodule "src/doc/embedded-book"] path = src/doc/embedded-book

Minimized from : This issue was introduced in the build, and so it is likely to be a result of the upgrade to LLVM 17 ().
I have bisected the LLVM pass to the pass on main. I'm trying to get a diff of before/after so I can start tracking down the exact location of the incorrect optimization.
The optimization transforms this switch lookup which appears to correspond to the : with only the calculation of and changing from: to: with the rest of the IR remaining unchanged. The transform of appears to be okay ( by 64 -by 6). The transform of introduces the issue because although the instruction is marked as , is equal to which is negative in the signed representation and so subtracting 128 does cause signed underflow.
The IR output from rustc without any optimization passes outputs is: Which appears correct to me. This suggests that the is being introduced in a later optimization pass. I'll continue bisecting when I get a chance.
Looks like this instruction is being generated by a pass that's run before the pass. Before : Which is correct. So the real errant pass is , it just doesn't cause incorrect x86 to be emitted until a later pass.
Looks like this issue is known and a fix is in progress upstream at


Question: #![allow(non_upper_case_globals)] <ins> use attributes; </ins> use intrinsics::{self, Intrinsic}; use llvm::{self, TypeKind}; use abi::{Abi, FnType, LlvmType, PassMode};

and are both broken on s390x since Rust 1.28. When is built without debuginfo, the tests hang with their backtracing processes stuck in a loop. With debuginfo, it fails with output like: I believe the problem is this part of : where doesn't identify that is a 64-bit platform. See also alexcrichton/backtrace-rs. I plan to update that here when it's published, and make a similar fix in .
fixes the backtrace when is built with debuginfo, but I'm still getting a hang without. In GDB, it looks like the unwinder gets to the that catches panics, then loops unwinding that same PC forever. This part of the regression is older -- happens on 1.27.2 as well, but 1.26.2 is fine. Binaries from the older version don't appear to have a distinct symbol at all, but maybe that's just inlined differently. I'm bisecting for that hang now.
Bisecting pointed me at (cc which attributes to all functions. For s390x the base features actually include a removal, . But it doesn't look like the features are applied to the synthesized (), and as a result it doesn't get inlined anymore since it has more features (w/ ) than the callee. We probably should apply target-features to as well. I don't know why the non-inlined can't be unwound -- maybe we need to force ? By default GDB backtrace stops at crate , but tries to go further: Maybe Rust's could have a similar defensive check, at least.
Nice find Definitely makes sense to me, and this should be fixed up (at least the business) in
With , , and , I believe we have this fixed.


Question: // option. This file may not be copied, modified, or distributed // except according to those terms. <del> #![feature(globs)] </del> <ins> #![feature(globs, lang_items)] </ins> #![no_std] // makes debugging this test *a lot* easier (during resolve) <ins> #[lang = "sized"] pub trait Sized for Sized? {} </ins> // Test to make sure that private items imported through globs remain private // when  they're used.

The following code causes an ICE: Removing the parameter or changing it to be a value instead of a reference stops the crash with an error saying I need to specify a lifetime, which makes me think this is a problem related to inferred lifetimes.
It isn't, you just have to specify a lifetime: ICE-s as well. Returning an unsized type should be a typeck error.
happens to work because it implies , i.e. would also work.


Question: <ins> error: unterminated double quote string --> $DIR/test-compile-fail3.rs:3:1 | 3 | "fail | ^^^^^^ error: aborting due to previous error </ins>

I have a no_std crate that imports std when testing: However, I get this error during testing: Allocating on the heap during testing does appear to work, so I'm assuming this is just a case of the warning still being emitted.
I have the same issue. Any update?
builds the crate both as a library (for doctests) and as a test executable. You only pull in std for the test executable, so the error message could be coming from building as a library.
I have the same issue, error message seems to be spurious
Yeah, the error message is emitted when building the library. Funnily enough, it does not cause the build to fail. That is, still continues running and then exits with success (0). Sadly, there is currently no way to link in a default allocator (or for that matter) for doctests. There is the unstable feature that provides , but I don't see how to achieve something similar without relying on unstable features. I simply use until this is fixed.
Related:
modify labels: +T-rustdoc
Error: Parsing label command in failed: labels +T-rustdo... Please let know if you're having trouble with this bot.
If you don't put inside the doctest it will be linked against even when testing a crate, you can think of each doctest as a separate crate. If you do want a different allocator you can add a static like in a normal binary. Even though this error message is printed the doc tests should still be running.
Also see the error is basically spurious.


Question: <ins> error: unterminated double quote string --> $DIR/test-compile-fail3.rs:3:1 | 3 | "fail | ^^^^^^ error: aborting due to previous error </ins>

I noticed this in the output running locally: and that didn't make tests fail. Cc:
Same with panic_unwind:
This error message is printed when running , but before running any test. The code printing it is in . It looks like rustdoc is using that code in order to load the crate and find doctests in it. But since it’s not actually compiling this crate, not having an allocator is not a problem. So I think there are two issues: rustdoc keeps doing its thing even though there are errors. It probably should call something like on its instance at some point. This error should not occur in the first place. One way to inhibit it would be to tell that we’re "compiling" an rlib () rather than some other crate type. rlibs do not need (yet) to have an allocator defined. This is possibly this line: The first issue could in some other situation hide a real problem, but in this case it makes the second one mostly harmless. The only bad consequence is some noise in the output of a test run.
Related:
modify labels: +T-rustdoc
Error: Parsing label command in failed: labels +T-rustdo... Please let know if you're having trouble with this bot.