Question: <del> use crate::io::{self, ErrorKind, Read, Write}; </del> <ins> use super::{BufWriter, ErrorKind, Read, Result, Write, DEFAULT_BUF_SIZE}; </ins> use crate::mem::MaybeUninit; /// Copies the entire contents of a reader into a writer.

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: <del> use crate::io::{self, ErrorKind, Read, Write}; </del> <ins> use super::{BufWriter, ErrorKind, Read, Result, Write, DEFAULT_BUF_SIZE}; </ins> use crate::mem::MaybeUninit; /// Copies the entire contents of a reader into a writer.

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: <del> use crate::io::{self, ErrorKind, Read, Write}; </del> <ins> use super::{BufWriter, ErrorKind, Read, Result, Write, DEFAULT_BUF_SIZE}; </ins> use crate::mem::MaybeUninit; /// Copies the entire contents of a reader into a writer.

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> // ignore-tidy-linelength #![feature(no_core)] #![no_core] pub enum Foo { // @set Unit = "$.index[*][?(@.name=='Unit')].id" // @is "$.index[*][?(@.name=='Unit')].inner.variant_kind" '"plain"' // @is "$.index[*][?(@.name=='Unit')].inner.variant_inner" null Unit, // @set Named = "$.index[*][?(@.name=='Named')].id" // @is "$.index[*][?(@.name=='Named')].inner.variant_kind" '"struct"' // @is "$.index[*][?(@.name=='Named')].inner.variant_inner" '{"fields": [], "fields_stripped": false}' Named {}, // @set Tuple = "$.index[*][?(@.name=='Tuple')].id" // @is "$.index[*][?(@.name=='Tuple')].inner.variant_kind" '"tuple"' // @is "$.index[*][?(@.name=='Tuple')].inner.variant_inner" [] Tuple(), // @set NamedField = "$.index[*][?(@.name=='NamedField')].id" // @set x = "$.index[*][?(@.name=='x' && @.kind=='struct_field')].id" // @is "$.index[*][?(@.name=='NamedField')].inner.variant_kind" '"struct"' // @is "$.index[*][?(@.name=='NamedField')].inner.variant_inner.fields[*]" $x // @is "$.index[*][?(@.name=='NamedField')].inner.variant_inner.fields_stripped" false NamedField { x: i32 }, // @set TupleField = "$.index[*][?(@.name=='TupleField')].id" // @is "$.index[*][?(@.name=='TupleField')].inner.variant_kind" '"tuple"' // @set tup_field = "$.index[*][?(@.name=='0' && @.kind=='struct_field')].id" // @is "$.index[*][?(@.name=='TupleField')].inner.variant_inner[*]" $tup_field TupleField(i32), } // @is    "$.index[*][?(@.name=='Foo')].inner.variants[0]" $Unit // @is    "$.index[*][?(@.name=='Foo')].inner.variants[1]" $Named // @is    "$.index[*][?(@.name=='Foo')].inner.variants[2]" $Tuple // @is    "$.index[*][?(@.name=='Foo')].inner.variants[3]" $NamedField // @is    "$.index[*][?(@.name=='Foo')].inner.variants[4]" $TupleField // @count "$.index[*][?(@.name=='Foo')].inner.variants[*]" 5 </ins>

At some point their should also be a for , and probably a way to tell what position each of the non stripped items are, as currently each of these 3 variants are documented with the same inner. but HTML gets a good representation:  The solution is probably to do what we do for structs, and store the , and a , such that each field of a varient gets an to hold the . We also should have a numfields, as even in that schema, you can't tell the difference between This also effects struct AFAIKT. I don't think this needs to be done now. I'll file an issue for it. Originally posted by in modify labels: +A-rustdoc-json +T-rustdoc
Related:


Question: let sp = var_origin.span(); let return_sp = sub_origin.span(); let param = self.find_param_with_region(*sup_r, *sub_r)?; <ins> let simple_ident = param.param.pat.simple_ident(); </ins> let lifetime_name = if sup_r.has_name() { sup_r.to_string() } else { "'_".to_owned() }; let (mention_influencer, influencer_point) =

[ ] Previous Stable [ ] Current Stable [ ] Current Beta [X] Current Nightly No response <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
This is another case for And except for the missing argument issue, there is an copy-paste bug in :


Question: <ins> // Copyright 2017 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. trait VecN { const DIM: usize; } trait Mat { type Row: VecN; } fn m<M: Mat>() { let x = M::Row::DIM; } fn main() {} </ins>

I was playing around with some code which can be found and is attached below. When I click on output I get the following output: I don't have a rust installation locally right now, so I cannot create the backtrace. I'll add it later today. The code which triggers this:
Stack trace: (There is no ICE with (nothing generated either due to type error). Perhaps playpen should use instead.)
You can get backtrace on playpen here: !
Looks like this has been fixed recently


Question: <ins> // Copyright 2017 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. trait VecN { const DIM: usize; } trait Mat { type Row: VecN; } fn m<M: Mat>() { let x = M::Row::DIM; } fn main() {} </ins>

I was in the middle of making a big changes to some code when this panic occurred. I was expecting a lot of compiler errors but got a compiler panic instead! :fearful: I ran the build with and the panic still occurred. Run to get this. Here's the full output with : Since I was in the middle of editing, there's no commit to point to, so I just attached my source code as is so you have something to debug. When you download it and run , the compiler should panic. The repo is called . I don't know how to narrow this issue down, or else I would try to find a smaller example for you. Hope this is good enough.
Some context for the change that caused this: Before this error happened, I changed the file . I split into two structs, and . I was relying on the compiler to find all the places where that change would effect things, and it seems that something went wrong in the compiler while trying to do that.
Once I fix that, everything works again. No more compiler panic. So it seems to have something to do with when I split up that struct. All the messed up pattern matches caused a panic. (Actually just fixing 2 broken pattern matches fixed the problem.)
I've just encountered this myself. I managed to reduce it down: It looks like this happens when a closure's body is a single (non-block) expression, and a tuple struct pattern is used somewhere in the expression. A simple workaround (if anyone needs one for some reason), then, is to just make the closure body a block:


Question: <ins> // Copyright 2017 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. trait VecN { const DIM: usize; } trait Mat { type Row: VecN; } fn m<M: Mat>() { let x = M::Row::DIM; } fn main() {} </ins>

Related code: Compiler panic: Note that everything is fine if I annotate the lifetimes: I am running , the MSVC x64 version.
I just ran into this. Managed to reduce the crash to Explicit lifetimes indeed fix it:
don't know if this helps, but I came up with minimal test case


Question: <ins> // Copyright 2017 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. trait VecN { const DIM: usize; } trait Mat { type Row: VecN; } fn m<M: Mat>() { let x = M::Row::DIM; } fn main() {} </ins>

Playground Output: Other example (possibly different bug): Output:
I just got the same ICE on linux with both the and builds. My case is essentially the same. You create an iterator of references to sub-elements of some thing which has been passed in by reference. The compiler should figure out that the iterator can only live as long as the original object, but ICEs instead. ()


Question: <ins> // Copyright 2017 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. trait VecN { const DIM: usize; } trait Mat { type Row: VecN; } fn m<M: Mat>() { let x = M::Row::DIM; } fn main() {} </ins>

Spawned off of There are still some cases where referencing an inaccessible item can cause the compiler to ICE. Here is one crafted example () but if 's module structure is revised then that example may fail to compile without ICE'ing for other reasons, so take care in understanding the issue: the change introduced by is skipping the requirement for stability attributes is slightly too narrow, in that it uses a local notion of pub/non-pub instead of overall accessibility. One simple solution to this may be to just follow the suggestion here and just remove the assertion entirely. (I did not want to adopt that solution for a PR to be backported to beta, but I think it is worth considering doing in nightly alone to resolve this low priority issue.)
Keywords: for better search


Question: <ins> // compile-flags: -Zmir-opt-level=2 -Copt-level=0 // run-pass type M = [i64; 2]; fn f(a: &M) -> M { let mut b: M = M::default(); b[0] = a[0] * a[0]; b } fn main() { let mut a: M = [1, 1]; a = f(&a); assert_eq!(a[0], 1); } </ins>

This little matrix processing code shows miscompilation if compiled with: But it compiles correctly with: With:
Hmm, on first glance the replacement it performs looks correct: It replaces local () with the return place . Previously the return place was only used in the block by a copy statement, so this transformation should be correct. Maybe this part of the diff causes a problem? We're using our return place as the return destination for the inner call. It's possible that there's an undocumented (and maybe unintended) assumption that the return place is not reused like this, either in other MIR optimizations or in codegen. Haven't looked too deeply yet though.
Ah, there's this bad call in LLVM IR: It passes a reference to as both the return pointer, and the second (immutable) argument.
we have this corresponding MIR, where we already incorrectly pass a reference to as an argument, while also assigning the call result to it: The destination propagation pass already has code that prevents merging a call destination with one of the arguments, but here we pass a reference instead. Curiously, the was produced by merging with , which is not really something the pass should be doing since a reference is taken to , and we avoid touching any local that has its address taken.
The propagation is disabled only if both locals have their address taken. Changing that to be more conservative does fix this issue. Minimized:
Oof, this should have been an , not an
Thanks
Opened with a fix


Question: }; let column_width = if let Some(width) = self.terminal_width { <del> width </del> <ins> width.saturating_sub(code_offset) </ins> } else if self.ui_testing { 140 } else { <del> term_size::dimensions().map(|(w, _)| w - code_offset).unwrap_or(140) </del> <ins> term_size::dimensions() .map(|(w, _)| w.saturating_sub(code_offset)) .unwrap_or(std::usize::MAX) </ins> }; let margin = Margin::new(

Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool miri has failing tests. 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! cc the PR reviewer, and -- nominating for prioritization.
introduced an ICE (integer overflow) in the error emitting code, that Miri runs into.
will fix the issue on 's end, which should automatically fix this one.


Question: |        ^^^^^^^^^^^^^^^^^^^^^^^ type aliases cannot be used as traits | help: you might have meant to use `#![feature(trait_alias)]` instead of a `type` alias <del> --> $DIR/unboxed-closure-sugar-nonexistent-trait.rs:4:1 </del> | <del> LL | type Typedef = isize; | ^^^^^^^^^^^^^^^^^^^^^ </del> <ins> LL | trait Typedef = isize; | </ins> error: aborting due to 2 previous errors

I managed to reproduce the problem with this snippet: The compiler yells E0404 at me, but fair enough I always ask it to a bit more about it :) However this time, it only says this: This is confusing because the snippet above doesn't involve the keyword so I didn't understand initially what I was doing wrong, then I read the error message again: I first tried this, and it worked, but having to repeat the whole syntax everywhere wasn't too compelling, hence the alias: The compiler error message makes it very clear that I can't alias a trait, but the E0404 explanation doesn't mention it at all. I hope the description could also include this use case as I've seen sometimes EXXXX explanations go over several facets of the same problem. That won't help me, but maybe others that may trip on the same problem. I would have submitted a pull request for the docs myself, but I have no idea why you can't use type aliases for traits so I can't it ;) I'm using stable Rust 1.19.0 (on Fedora).
One more thing, even though the compiler lets me create an alias for a trait, I don't know when I can use such an alias. Maybe this should be explained too.
Current output (in nightly):
Current output: No structured suggestion for the nightly feature (should be and the feature flag).


Question: fn resolve_module_prefix(&mut self, module_path: &[Ident], span: Option<Span>) -> ResolveResult<ModulePrefixResult<'a>> { if &*module_path[0].name.as_str() == "$crate" { <del> let mut ctxt = module_path[0].ctxt; while ctxt.source().0 != SyntaxContext::empty() { ctxt = ctxt.source().0; } let module = self.invocations[&ctxt.source().1].module.get(); let crate_root = if module.def_id().unwrap().is_local() { self.graph_root } else { module }; return Success(PrefixFound(crate_root, 1)) </del> <ins> return Success(PrefixFound(self.resolve_crate_var(module_path[0].ctxt), 1)); </ins> } // Start at the current module if we see `self` or `super`, or at the

When on latest rust nightly , you get an ICE when compiling .
Its a pretty recent regression, it can't be reproduced with .
Okay, managed to minimize it: Looks like a regression of . cc any ideas on this?
Yeah, this was caused by an oversight in -- fixed in .


Question: <ins> // Copyright 2018 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. #![feature(specialization)] trait Iterate<'a> { type Ty: Valid; fn iterate(self); } impl<'a, T> Iterate<'a> for T where T: Check { default type Ty = (); default fn iterate(self) {} } trait Check {} impl<'a, T> Check for T where <T as Iterate<'a>>::Ty: Valid {} trait Valid {} fn main() { Iterate::iterate(0); } </ins>

Code works cc
Bug triage: on current nightly (), this no longer is an ICE, but yields the following error:


Question: } ast::ExprMatch(ref discr, ref arms) => { <del> // treatment of the discriminant is handled while // walking the arms: self.walk_expr(&**discr); </del> let discr_cmt = return_if_err!(self.mc.cat_expr(&**discr)); <ins> self.borrow_expr(&**discr, ty::ReEmpty, ty::ImmBorrow, MatchDiscriminant); // treatment of the discriminant is handled while walking the arms. </ins> for arm in arms.iter() { self.walk_arm(discr_cmt.clone(), arm); }

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: inner: VaListImpl<'f>, #[cfg(all( <del> any(target_arch = "aarch64", target_arch = "powerpc", target_arch = "x86_64"), </del> <ins> any( target_arch = "aarch64", target_arch = "powerpc", target_arch = "s390x", target_arch = "x86_64" ), </ins> any(not(target_arch = "aarch64"), not(any(target_os = "macos", target_os = "ios"))), not(target_family = "wasm"), not(target_arch = "asmjs"),

fails this test on native : (This is not a new failure, but I am cleaning up issues from downstream Red Hat bugzilla.)
We started discussing this in , and looking at the clang implementation here: I tried that minimal step with , but it still gives the same "Cannot select" error. I don't see any lowering of in like other targets, only stuff implementing the calling convention. So I guess we do need custom support, or perhaps the clang bits could be moved down into the LLVM lowering?
Hi , I ran into the same problem and noticed you had already opened an issue. I've now submitted a PR to implement valist and vaarg for s390x to fix this.


Question: llvm::LLVMRustAddAnalysisPasses(tm, pm, llmod); llvm::LLVMRustAddPass(pm, "verify0".as_ptr() as *const _); <del> let opt = sess.opts.cg.opt_level.unwrap_or(0) as libc::c_uint; </del> <ins> let opt = match sess.opts.optimize { config::No => 0, config::Less => 1, config::Default => 2, config::Aggressive => 3, }; </ins> let builder = llvm::LLVMPassManagerBuilderCreate(); llvm::LLVMPassManagerBuilderSetOptLevel(builder, opt);

The test run-pass/sepcomp-lib- can fail on android apparently due to the fact that a pthread shim dependency is present in libstd (as part of librust_builtin), but it stripped out early. It may be possible to work around this by moving the dependency into liballoc instead, but a more thorough examination is needed.
cc
The problem here on android was as follows: jemalloc requires the symbol, which android does not provide. jemalloc is also statically linked to liballoc We provide a dummy definition of in , which is assembled into and is statically linked to . When building with LTO, we remove all rust-generated code from an rlib (it's all in the LTO object), but we still link the rlib. When linking, we pass libstd's rlib first, then liballoc's rlib on the command line. The linker detects that we're not using any symbols from the libstd's rlib by the time its reached on the command line (scans from left-to-right) because we actually aren't using any symbols from or any other objects in the archive. The linker then strips from the linkage step, which then later yields an unresolved reference. The solution here is to break apart to be less of a conglomerate and instead link specific symbols to specific libraries wherever necessary. For example all of the time-related functionality should be a lib linked directly to , not to . In this example we need to link the symbol directly to , not to , because is not the one that needs it. Just some general cleanup, most things should still work as advertised!
Triage: this test is still ignored on android, but I don't know what is nowadays.
! So I guess this can be closed, but should we check if the affected test was actually fixed?
Yeah I think this is all taken care of, so closing.


Question: emit_ptr_va_arg(bx, addr, target_ty, false, Align::from_bytes(8).unwrap(), true) } "aarch64" => emit_aapcs_va_arg(bx, addr, target_ty), <ins> "s390x" => emit_s390x_va_arg(bx, addr, target_ty), </ins> // Windows x86_64 "x86_64" if target.is_like_windows => { let target_ty_size = bx.cx.size_of(target_ty).bytes();


Question: false } <ins> /// Suggest possible range with adding parentheses, for example: /// when encountering `0..1.map(|i| i + 1)` suggest `(0..1).map(|i| i + 1)`. fn suggest_wrapping_range_with_parens( &self, tcx: TyCtxt<'tcx>, actual: Ty<'tcx>, source: SelfSource<'tcx>, span: Span, item_name: Ident, ty_str: &str, ) -> bool { if let SelfSource::MethodCall(expr) = source { for (_, parent) in tcx.hir().parent_iter(expr.hir_id).take(5) { if let Node::Expr(parent_expr) = parent { let lang_item = match parent_expr.kind { ExprKind::Struct(ref qpath, _, _) => match **qpath { QPath::LangItem(LangItem::Range, ..) => Some(LangItem::Range), QPath::LangItem(LangItem::RangeTo, ..) => Some(LangItem::RangeTo), QPath::LangItem(LangItem::RangeToInclusive, ..) => { Some(LangItem::RangeToInclusive) } _ => None, }, ExprKind::Call(ref func, _) => match func.kind { // `..=` desugars into `::std::ops::RangeInclusive::new(...)`. ExprKind::Path(QPath::LangItem(LangItem::RangeInclusiveNew, ..)) => { Some(LangItem::RangeInclusiveStruct) } _ => None, }, _ => None, }; if lang_item.is_none() { continue; } let span_included = match parent_expr.kind { hir::ExprKind::Struct(_, eps, _) => { eps.len() > 0 && eps.last().map_or(false, |ep| ep.span.contains(span)) } // `..=` desugars into `::std::ops::RangeInclusive::new(...)`. hir::ExprKind::Call(ref func, ..) => func.span.contains(span), _ => false, }; if !span_included { continue; } let range_def_id = self.tcx.require_lang_item(lang_item.unwrap(), None); let range_ty = self.tcx.bound_type_of(range_def_id).subst(self.tcx, &[actual.into()]); let pick = self.probe_for_name( span, Mode::MethodCall, item_name, IsSuggestion(true), range_ty, expr.hir_id, ProbeScope::AllTraits, ); if pick.is_ok() { let range_span = parent_expr.span.with_hi(expr.span.hi()); tcx.sess.emit_err(errors::MissingParentheseInRange { span, ty_str: ty_str.to_string(), method_name: item_name.as_str().to_string(), add_missing_parentheses: Some(errors::AddMissingParenthesesInRange { func_name: item_name.name.as_str().to_string(), left: range_span.shrink_to_lo(), right: range_span.shrink_to_hi(), }), }); return true; } } } } false } </ins> fn suggest_constraining_numerical_ty( &self, tcx: TyCtxt<'tcx>,

<!-- 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 something like this: label +D-confusing +D-invalid-suggestion <!-- If the problem is not self-explanatory, please provide a rationale for the change. --<!-- If dramatically different output is caused by small changes, consider also adding them here. If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. The output might also be different depending on the Edition. --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim


Question: <ins> struct Wrapper<'rom>(T); //~^ ERROR cannot find type `T` in this scope trait Foo { fn bar() -> Wrapper<impl Sized>; //~^ ERROR missing lifetime specifier //~| ERROR struct takes 0 generic arguments but 1 generic argument was supplied } impl Foo for () { fn bar() -> i32 { //~^ ERROR method `bar` has an incompatible type for trait //~| ERROR method `bar` has an incompatible return type for trait 0 } } fn main() {} </ins>

<!-- ICE: Rustc '' 'thread 'rustc' panicked at 'assertion failed: expect 1 RPITITs in call to '', 'thread 'rustc' panicked at 'assertion failed: expect 1 RPITITs in call to '' File: --auto-reduced (treereduce-rust): original: Version information ` Command: <!-- query stack: [collectreturnpositionimpltraitintraittys] comparing an impl and trait method signature, inferring any hidden types in the process [typeof] computing type of [checkmodimplwf] checking that impls are well-formed in top-level module [analysis] running analysis passes on this crate --
<!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details
fyi


Question: <ins> // Copyright 2012-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. // ignore-fast // Be sure that when a SIGPIPE would have been received that the entire process // doesn't die in a ball of fire, but rather it's gracefully handled. use std::os; use std::io::{PipeStream, Process}; fn test() { let os::Pipe { input, out } = os::pipe(); let input = PipeStream::open(input); let mut out = PipeStream::open(out); drop(input); let _ = out.write([1]); } fn main() { let args = os::args(); if args.len() > 1 && args[1].as_slice() == "test" { return test(); } let mut p = Process::new(args[0], [~"test"]).unwrap(); assert!(p.wait().success()); } </ins>

Scripts to reproduce Steps to reproduce: Output:  Backtrace: None Exit code: 141 Version:
What are you expecting to happen? When you send a TERM signal to a process without a registered handler, it terminates promptly. The runtime currently doesn't register any TERM/INT handlers, that's up to you.
I was expecting the runtime to return some upon requesting an action from a defunct process. I also tried polling the state of the defunct process using (as mentioned in the ), but this returned as well. Even if the runtime dosn't "catch" the SIG{TERM,INT}, is it not possible at all to or return in any of the two cases mentioned above?
Oh whoops, sorry! I had my understanding backwards, and apparently this isn't a bug on OSX which caused more confusion for me. Anyway, closing as a dupe of , it's the same cause.
Oh wow, I've done it again. I'm sorry, again! I apologize for not investigating more thoroughly. This is indeed separate from


Question: <ins> // run-rustfix // check-only #[derive(Debug)] struct Demo { a: String } trait GetString { fn get_a(&self) -> &String; } trait UseString: std::fmt::Debug { fn use_string(&self) { println!("{:?}", self.get_a()); //~ ERROR no method named `get_a` found for type `&Self` } } trait UseString2 { fn use_string(&self) { println!("{:?}", self.get_a()); //~ ERROR no method named `get_a` found for type `&Self` } } impl GetString for Demo { fn get_a(&self) -> &String { &self.a } } impl UseString for Demo {} impl UseString2 for Demo {} #[cfg(test)] mod tests { use crate::{Demo, UseString}; #[test] fn it_works() { let d = Demo { a: "test".to_string() }; d.use_string(); } } fn main() {} </ins>

The following example code yields an error: It's unclear from this error message how to proceed - I'm not sure of the syntax, location, or where I should be putting the "GetString" trait bound. It should be shown with a better example or link when this error is presented, as the current message is not sufficient for a resolution to be arrived at.
cc
Fixing in . To fix your code write:
Thanks!


Question: self.borrow(assignee_place, diag_expr_id, ty::BorrowKind::MutBorrow); } } <ins> /// Rust doesn't permit moving fields out of a type that implements drop fn restrict_precision_for_drop_types<'a, 'tcx>( fcx: &'a FnCtxt<'a, 'tcx>, mut place: Place<'tcx>, mut curr_mode: ty::UpvarCapture<'tcx>, span: Span, ) -> (Place<'tcx>, ty::UpvarCapture<'tcx>) { let is_copy_type = fcx.infcx.type_is_copy_modulo_regions(fcx.param_env, place.ty(), span); if let (false, UpvarCapture::ByValue(..)) = (is_copy_type, curr_mode) { for i in 0..place.projections.len() { match place.ty_before_projection(i).kind() { ty::Adt(def, _) if def.destructor(fcx.tcx).is_some() => { truncate_place_to_len_and_update_capture_kind(&mut place, &mut curr_mode, i); break; } _ => {} } } } (place, curr_mode) } </ins> /// Truncate `place` so that an `unsafe` block isn't required to capture it. /// - No projections are applied to raw pointers, since these require unsafe blocks. We capture ///   them completely.

I tried this code: This does not issue a warning for , however it fails to compile with enabled: I would expect to give a suggestion to add . Found in the 2021 crater run for: I'm uncertain if this is a duplicate of or , they seem very similar, but this case is specific to implementing Drop. : cc <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
claim


Question: <ins> //! Regression test for #128622. //! //! PR #128581 introduced an assertion that all builtin attributes are actually checked via //! `CheckAttrVisitor` and aren't accidentally usable on completely unrelated HIR nodes. //! Unfortunately, the check had correctness problems. //! //! The match on attribute path segments looked like //! //! ```rs,ignore //! [sym::should_panic] => /* check is implemented */ //! match BUILTIN_ATTRIBUTE_MAP.get(name) { //!     // checked below //!     Some(BuiltinAttribute { type_: AttributeType::CrateLevel, .. }) => {} //!     Some(_) => { //!         if !name.as_str().starts_with("rustc_") { //!             span_bug!( //!                 attr.span, //!                 "builtin attribute {name:?} not handled by `CheckAttrVisitor`" //!             ) //!         } //!     } //!     None => (), //! } //! ``` //! //! However, it failed to account for edge cases such as an attribute whose: //! //! 1. path segments *starts* with a builtin attribute such as `should_panic` //! 2. which does not start with `rustc_`, and //! 3. is also an `AttributeType::Normal` attribute upon registration with the builtin attribute map //! //! These conditions when all satisfied cause the span bug to be issued for e.g. //! `#[should_panic::skip]` because the `[sym::should_panic]` arm is not matched (since it's //! `[sym::should_panic, sym::skip]`). //! //! This test checks that the span bug is not fired for such cases. //! //! issue: rust-lang/rust#128622 // Notably, `should_panic` is a `AttributeType::Normal` attribute that is checked separately. struct Foo { #[should_panic::skip] //~^ ERROR failed to resolve pub field: u8, #[should_panic::a::b::c] //~^ ERROR failed to resolve pub field2: u8, } fn foo() {} fn main() { #[deny::skip] //~^ ERROR failed to resolve foo(); } </ins>

<!-- ICE: Rustc '' 'error: internal compiler error: builtin attribute "shouldpanic" not handled by ', 'error: internal compiler error: builtin attribute "shouldpanic" not handled by ' 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: [checkmodattrs] checking attributes in top-level module [analysis] running analysis passes on this crate --
there are a bunch more which probably all follow the pattern... 2 "errorreason": "error: internal compiler error: builtin attribute "allow" not handled by ", 2 "errorreason": "error: internal compiler error: builtin attribute "cfgattr" not handled by ", 4 "errorreason": "error: internal compiler error: builtin attribute "cfg" not handled by ", 2 "errorreason": "error: internal compiler error: builtin attribute "cmsenonsecureentry" not handled by ", 2 "errorreason": "error: internal compiler error: builtin attribute "collapsedebuginfo" not handled by ", 6 "errorreason": "error: internal compiler error: builtin attribute "deny" not handled by ", 2 "errorreason": "error: internal compiler error: builtin attribute "doc" not handled by ", 4 "errorreason": "error: internal compiler error: builtin attribute "inline" not handled by ", 2 "errorreason": "error: internal compiler error: builtin attribute "macroexport" not handled by ", 2 "errorreason": "error: internal compiler error: builtin attribute "optimize" not handled by ", 4 "errorreason": "error: internal compiler error: builtin attribute "procmacroderive" not handled by ", 14 "errorreason": "error: internal compiler error: builtin attribute "procmacro" not handled by ", 2 "errorreason": "error: internal compiler error: builtin attribute "shouldpanic" not handled by ",
cc
Taking a look
Problem is the previous match falls through to the fallback case for etc. because it has 1 segments ... and then since et al. is a attribute, it triggers the ICE.
I have a candidate fix locally, doing some more testing
Opened as a candidate fix.


Question: <ins> // This used to mis-compile because the mir-opt `SimplifyArmIdentity` // did not check that the types matched up in the `Ok(r)` branch. // // run-pass // compile-flags: -Zmir-opt-level=2 #[derive(Debug, PartialEq, Eq)] enum SpecialsRes { Res(u64) } fn e103() -> SpecialsRes { if let Ok(r) = "1".parse() { SpecialsRes::Res(r) } else { SpecialsRes::Res(42) } } fn main() { assert_eq!(e103(), SpecialsRes::Res(1)); } </ins>

PR introduced an ICE in the following code with :
cc with mir-opt-level=1: with mir-opt-level=2: Where the types are


Question: <ins> // This used to mis-compile because the mir-opt `SimplifyArmIdentity` // did not check that the types matched up in the `Ok(r)` branch. // // run-pass // compile-flags: -Zmir-opt-level=2 #[derive(Debug, PartialEq, Eq)] enum SpecialsRes { Res(u64) } fn e103() -> SpecialsRes { if let Ok(r) = "1".parse() { SpecialsRes::Res(r) } else { SpecialsRes::Res(42) } } fn main() { assert_eq!(e103(), SpecialsRes::Res(1)); } </ins>

Since few Rustc nightly versions I see a miscompilation problem with the code below. I am using: If I compile with: The code:
NB: this is because it needs an unstable CLI flag to reproduce.
cc since this might have something to do with recent const-eval work (apologies if I left anyone out)
I've managed to minify it to
Bisected it to , most probably the same issue as


Question: for (idx, (param_ty, param)) in inputs_fn.chain(maybe_va_list).zip(body.params).enumerate() { // Check the pattern. let ty_span = try { inputs_hir?.get(idx)?.span }; <del> fcx.check_pat_top(&param.pat, param_ty, ty_span, false); </del> <ins> fcx.check_pat_top(&param.pat, param_ty, ty_span, None); </ins> // Check that argument is Sized. // The check for a non-trivial pattern is a hack to avoid duplicate warnings

<!-- 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: /// Converts a vector of bytes to a `String`. /// <del> /// A string slice ([`&str`]) is made of bytes ([`u8`]), and a vector of bytes </del> <ins> /// A string ([`String`]) is made of bytes ([`u8`]), and a vector of bytes </ins> /// ([`Vec<u8>`]) is made of bytes, so this function converts between the /// two. Not all byte slices are valid `String`s, however: `String` /// requires that it is valid UTF-8. `from_utf8()` checks to ensure that

This chunk was supposedly copy-pasted as is from It should read A String ([]) is made of bytes
Hi there. Can I pick this up as first-timer task?


Question: use rustc_span::symbol::{kw, sym, Symbol}; use rustc_span::Span; <del> use crate::clean::{self, Attributes, AttributesExt, FakeDefId, GetDefId, ToSource}; </del> <ins> use crate::clean::{ self, Attributes, AttributesExt, FakeDefId, GetDefId, NestedAttributesExt, ToSource, Type, }; </ins> use crate::core::DocContext; use crate::formats::item_type::ItemType;

Last line yields several occurrences of in the generated file. ## Expected behavior No occurrences of anywhere since it was label C-bug T-rustdoc cc <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I expect the fix is to check for just after
claim
cc I checked for doc(hidden) like this: But it doesn't seem to work, as my test would fail. I also tried using the same way to check for but it also failed. I noticed that the issue involves so I might need to iterate over generic parameters, I cannot find any function that does that in , so can someone point me in the right direction? Thanks :)
You can look at how the pass works:
am I right in understanding this only happens for cross-crate traits, and impls for hidden traits in the same crate are still hidden? In other words, just makes the cross-crate case consistent?
I believe so, yes: the pass was already taking care of such cases for local types. FWIW, the thing that motivated this discussion was noticing a leaking on the docs for , but not on the ones for


Question: <ins> // Regression test for #71546. // ignore-compare-mode-nll // NLL stderr is different from the original one. pub fn serialize_as_csv<V>(value: &V) -> Result<String, &str> where V: 'static, for<'a> &'a V: IntoIterator, for<'a> <&'a V as IntoIterator>::Item: ToString + 'static, { let csv_str: String = value //~ ERROR: the associated type `<&'a V as IntoIterator>::Item` may not live long enough .into_iter() .map(|elem| elem.to_string()) .collect::<String>(); Ok(csv_str) } fn main() {} </ins>

Playground: UPDATE: MCVE is here: Code: Crashes compiler with
Would be nice to figure out if this is a regression or not and if it is when has this regressed. ping cleanup
Hey Cleanup Crew ICE-breakers! This bug has been identified as a good "Cleanup ICE-breaking candidate". In case it's useful, here are some [instructions] for tackling these sorts of bugs. Maybe take a look? Thanks! <3 [instructions]: https://rustc-dev- cc
It has been present since at least 2019-08-01 according to bisect-rustc
Simplified code to remove dependencies This compiles for 1.20.0 and not for 1.30.0 (setting edition to 2015) I'll try and pinpoint at least the version where it causes the ICE
From what I can tell the first time this ICE would happen is in 1.24.0
Assigning
Even simpler:
Triage: This ICE has been fixed in the latest nightly, I assume it's fixed by . Marking as .
Wait, the original code and still triggers the ICE... glacier was tracking with but it seems the others encounter another roadblock. Dropping .
No longer ICEs since , likely from


Question: // check if the RHS is from desugaring let opt_assignment_rhs_span = self.body.find_assignments(local).first().map(|&location| { <del> let stmt = &self.body[location.block].statements [location.statement_index]; match stmt.kind { mir::StatementKind::Assign(box ( _, mir::Rvalue::Use(mir::Operand::Copy(place)), )) => { self.body.local_decls[place.local].source_info.span } _ => self.body.source_info(location).span, </del> <ins> if let Some(mir::Statement { source_info: _, kind: mir::StatementKind::Assign(box ( _, mir::Rvalue::Use(mir::Operand::Copy(place)), )), }) = self.body[location.block] .statements .get(location.statement_index) { self.body.local_decls[place.local].source_info.span } else { self.body.source_info(location).span </ins> } }); match opt_assignment_rhs_span.and_then(|s| s.desugaring_kind()) {

<!-- 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. --: In case it helps, when using the stable toolchain, the compiler does not panic but instead emits this error: <!-- 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 --
Bisected to . CC searched nightlies: from nightly-2021-10-01 to nightly-2021-11-25 regressed nightly: nightly-2021-11-23 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.1</summaryHost triple: aarch64-apple-darwin Reproduce with: </details label regression-from-stable-to-nightly
I can fix this quickly -- seems like just changing an to a since the can be out of bounds. claim
(only tangentially related) I also noticed a regression in error spans between stable and beta... stable: beta:
That was an intentional change, meant to highlight the fact that the attempted mutable borrow is occurring because of the method call. However, it seems to be confusing for a lot of people, so I'll look into improving it.
Ah thanks for letting me know. Maybe we can split the span up into the receiver and the method, and add a note on the latter like "due to this method which takes &mut self". Not sure if that much info bubbles down into borrowck. I'd be interested in making that change if you've got a lot on your plate and it's (relatively) easy to do.
See for discussion about this exact idea. It'd be nice, but likely hard to implement.
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-high


Question: 2) } <ins> // Indicate that we want CodeView debug information on MSVC if cx.sess().target.target.options.is_like_msvc { llvm::LLVMRustAddModuleFlag(cx.llmod(), "CodeView0".as_ptr() as *const _, 1) } </ins> // Prevent bitcode readers from deleting the debug info. let ptr = "Debug Info Version0".as_ptr(); llvm::LLVMRustAddModuleFlag(cx.llmod(), ptr as *const _,

Symbol names are not properly supported yet on msvc, so backtraces are generally unhelpful. As a result, is currently disabled. This issue can be closed when it's been reenabled.


Question: if let ast::ExprKind::Await(_, _) | ast::ExprKind::Yield(_) = e.kind { ControlFlow::Break(()) } else { <del> visit::walk_expr(self, e); ControlFlow::Continue(()) </del> <ins> visit::walk_expr(self, e) </ins> } }

searched nightlies: from nightly-2024-03-07 to nightly-2024-03-10 regressed nightly: nightly-2024-03-09 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.8</summaryHost triple: aarch64-apple-darwin Reproduce with: </details modify labels: +regression-from-stable-to-nightly -regression-untriaged
I suspect caused this regression, but I don't know how to use to test this pr(I tried some times but all failed). Do you have any ideas about this?
if you use the latest version of cargo-bisect-rustc it will bisect the roll-up for you.
Hi, I'm using the latest version of , but seems that it fails to bisect the roll-up. Here's the complete log: bash cargo bisect-rustc --start 2024-03-08 --end 2024-03-09
It does bisect to for me. (With this visitor change in particular )
The fix has landed on master. Reopening to track beta backport.
Hi, 1.77.0 has been released, can this be backported to beta now?
I wasn’t at the weekly meeting and I don’t know for sure: is not yet marked as accepted for backport (it may just be an oversight in labeling, I’ll try to find out). Once that is done though, the release team, I believe, will backport it.
updated labels on (sorry for the delay)
That was backported in .


Question: self.rust_codegen_backends.get(0).cloned() } <ins> pub fn check_build_rustc_version(&self) { if self.dry_run() { return; } // check rustc version is same or lower with 1 apart from the building one let mut cmd = Command::new(&self.initial_rustc); cmd.arg("--version"); let rustc_output = output(&mut cmd) .lines() .next() .unwrap() .split(' ') .nth(1) .unwrap() .split('-') .next() .unwrap() .to_owned(); let rustc_version = Version::parse(&rustc_output.trim()).unwrap(); let source_version = Version::parse(&fs::read_to_string(self.src.join("src/version")).unwrap().trim()) .unwrap(); if !(source_version == rustc_version || (source_version.major == rustc_version.major && source_version.minor == rustc_version.minor + 1)) { let prev_version = format!("{}.{}.x", source_version.major, source_version.minor - 1); eprintln!( "Unexpected rustc version: {}, we should use {}/{} to build source with {}", rustc_version, prev_version, source_version, source_version ); crate::detail_exit(1); } } </ins> /// Returns the commit to download, or `None` if we shouldn't download CI artifacts. fn download_ci_rustc_commit(&self, download_rustc: Option<StringOrBool>) -> Option<String> { // If `download-rustc` is not set, default to rebuilding.

I'm trying to build Rust on a Tier 3 platform (; actually it's that's listed in Tier 3, but I don't think that affects the problem). Since there are no snapshots for this platform, I installed rustc from the distro's package manager (apk) and created a file to force using the pre-installed rustc rather than downloading snapshots: And the output of : I ran ; when it got as far as building the core library, I got a series of errors that were very hard to make sense of until I realized that it's because core library code depends on unstable features and I was using a stable rustc to compile it: There were many more errors, but I think they all relate to unstable features. It took me ages to figure out that (for example) the first error is due to the feature being disabled in stable. I understand that the stable compiler won't allow using unstable features even with , but is it possible for the parser to recognize this code even so and reject it with something like "feature is not enabled" instead of the much more generic "expected identifier" error?
Huh, usually Rust gets around this by setting , and usually when we bootstrap it's with a beta compiler, which does need that set by , and that would allow all the features. I wonder if wasn't set?
It's set, but the command that's actually failing (it took some effort to figure out which executable was actually failing) is: And what's installed for me in is a stable compiler. I realized after the fact that I can't use it to bootstrap, but with a different error message I might have noticed that sooner.
Forwards compatibility in diagnostics seems extremely hard. I think a much simpler and more helpful fix is to check the output of in bootstrap and give a hard error if it's not either the current version or N-1.
Note that the problem here is that you were trying to use 1.68 to build 1.70; it's unrelated to stable vs beta, the problem is that it was two versions behind instead of only one.
Mentoring instructions: in , if is set, run that process with . Compare that output to the contents of using the crate; if the minor versions aren't either the same or 1 apart, give a hard error. Note that this should also disallow e.g.


Question: self.rust_codegen_backends.get(0).cloned() } <ins> pub fn check_build_rustc_version(&self) { if self.dry_run() { return; } // check rustc version is same or lower with 1 apart from the building one let mut cmd = Command::new(&self.initial_rustc); cmd.arg("--version"); let rustc_output = output(&mut cmd) .lines() .next() .unwrap() .split(' ') .nth(1) .unwrap() .split('-') .next() .unwrap() .to_owned(); let rustc_version = Version::parse(&rustc_output.trim()).unwrap(); let source_version = Version::parse(&fs::read_to_string(self.src.join("src/version")).unwrap().trim()) .unwrap(); if !(source_version == rustc_version || (source_version.major == rustc_version.major && source_version.minor == rustc_version.minor + 1)) { let prev_version = format!("{}.{}.x", source_version.major, source_version.minor - 1); eprintln!( "Unexpected rustc version: {}, we should use {}/{} to build source with {}", rustc_version, prev_version, source_version, source_version ); crate::detail_exit(1); } } </ins> /// Returns the commit to download, or `None` if we shouldn't download CI artifacts. fn download_ci_rustc_commit(&self, download_rustc: Option<StringOrBool>) -> Option<String> { // If `download-rustc` is not set, default to rebuilding.

building 1.68 with 1.69; we use deny-warnings in most cases and have no guarantees that unstable features will be the same between releases. Only building 1.68 with 1.67 or 1.68 should be allowed.
btw I've noticed you running into a few different bootstrap bugs the past few days — reading through https://rustc-dev- may or may not make it easier to diagnose these issues without having to spend ages interpreting the diagnostics. I'm also happy to chat about "how should this work" sorts of things .
Yes, I've read that. Thanks!
The error message could be improved though. Maybe one could make the to put into libcore/bootstrap's
I don't think rust-version is a good way to solve this, no - that won't give a warning or error if you use a future version to compile an older version. Also it won't be able to catch local-rebuild issues where the nightly version of the bootstrap compiler is too old. See my suggestion in
Hmm, I'm afraid I might have said something unclear. I'm not asking for forward compatibility in diagnostics. The feature was in version 1.68.0, according to , and I was using rustc version 1.68.2. So it should "know" about that feature, but my understanding is that when I was invoking rustc it was with flags that prevent unstable features from being used.
hmm, in that case something strange is going on because playground gives a much more reasonable error than the one you saw:
what commit of rustc were you trying to build when you got this error? I'm going to see if I can replicate it locally.
I was trying to build .
Ah ok, it was related to the context of the closure: If you look at the same gist with beta, the error message is much better: So I think this particular diagnostic issue has already been fixed. I still want to keep this issue open to track checking the version of the bootstrap compiler, though.


Question: LL | import std::{ | ^^^^^^ help: items are imported using the `use` keyword <ins> error: expected item, found `require` --> $DIR/use_instead_of_import.rs:9:1 | LL | require std::time::Duration; | ^^^^^^^ help: items are imported using the `use` keyword error: expected item, found `include` --> $DIR/use_instead_of_import.rs:12:1 | LL | include std::time::Instant; | ^^^^^^^ help: items are imported using the `use` keyword </ins> error: expected item, found `using` <del> --> $DIR/use_instead_of_import.rs:9:5 </del> <ins> --> $DIR/use_instead_of_import.rs:15:5 </ins> | LL | pub using std::io; |     ^^^^^ help: items are imported using the `use` keyword <del> error: aborting due to 2 previous errors </del> <ins> error: aborting due to 4 previous errors </ins>

I was looking at namely issue when I thought about this. If work is being put into improving error messages when somebody uses a keyword that defines a function in another language, there should also be improved error messages if someone uses the incorrect directive to bring something into the scope of their module or namespace/ Given the following code: The current output is: The error message should preferably suggest the user to use the directive to bring something into scope of their module. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
For the record, on nightly, both and suggest using . I'm sure it's not that difficult to add .
ah. I was not aware of this. Less work to do then!
[Ignore this, just notes]
And also add ? Rust may go tooooo friendly in diagnostic message . Do you mind that I make a PR for it? I'm a newbie in hacking Rust compiler.
Sure! The earlier message should clarify where the edits are needed to be made. Ain't nothing as a diagnostic too friendly. =)
Remember to assign yourself using rustbot. Just a note for the future, usually if someone has already claimed an issue, it's not exactly common for someone else to fix it [aside from if the issue is abandoned by the claimee]. Since you're a newcomer here, I removed my assignment (and because I was working on another). However, you can find loads of easy issues with the E-Easy and/or E-Mentor tag for gaining experience. A few resources that might be helpful - Have fun hacking on Rust!
claim
Totally forgot about ! Good catch!


Question: ref s => { tcx.sess.span_bug( span, <del> format!("ty_region() invoked on in appropriate ty: {:?}", </del> <ins> format!("ty_region() invoked on an inappropriate ty: {:?}", </ins> s).as_slice()); } }

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: /// assert_eq!("GRüßE, JüRGEN ❤", s); /// ``` #[stable(feature = "ascii_methods_on_intrinsics", since = "1.23.0")] <del> #[rustc_const_unstable(feature = "const_make_ascii", issue = "130698")] </del> <ins> #[rustc_const_stable(feature = "const_make_ascii", since = "CURRENT_RUSTC_VERSION")] </ins> #[inline] <ins> #[cfg_attr(bootstrap, rustc_allow_const_fn_unstable(const_mut_refs))] </ins> pub const fn make_ascii_uppercase(&mut self) { // SAFETY: changing ASCII letters only does not invalidate UTF-8. let me = unsafe { self.as_bytes_mut() };

Feature gate: This is a tracking issue for marking the and methods in , , , and as "const." [x] Implementation for : [x] Implementation for : [x] Implementation for and : [x] Final comment period (FCP) [x] Stabilization PRNone yet.
fcp merge / have been stable in const since 1.52. / are unblocked now by the stabilization of
Team member has proposed to merge this. The next step is review by the rest of the tagged team members: [x] [x] [x] [ ] [ ] No concerns currently listed. Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See for info about what commands tagged team members can give me.
Can the methods be included in this? Similarly const stable / since 1.52.
Yes, that sounds like a good idea. I'll try adding another PR later.
:bell: This is now entering its final comment period, as per the . :bell:
stabilises this.
The final comment period, with a disposition to merge, as per the , is now complete. As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed. This will be merged soon.


Question: #[stable(feature = "rust1", since = "1.0.0")] #[inline] pub fn len_utf8(self) -> usize { <del> let code = self as u32; if code < MAX_ONE_B { 1 } else if code < MAX_TWO_B { 2 } else if code < MAX_THREE_B { 3 } else { 4 } </del> <ins> len_utf8(self as u32) </ins> } /// Returns the number of 16-bit code units this `char` would need if

The following program causes UB: Miri says: The problem is this code: This calls unless the new code point is in , but what about surrogates in ? This code is unchanged since its introduction in I am not sure what the intended safety contract of is. That method is not marked but clearly should be -- it calls . So my guess is the safety precondition is that must not be part of a surrogate pair, but the thing is, calls it without actually ensuring that condition. The condition it does ensure is that the codepoint is not in , but that does not help.
is excluded from Unicode scalar values a.k.a. , but it’s fine as a Unicode code point. I think this bug is not in the contract of (which is private anyway) but in its implementation, namely going through . The fix is to either duplicate the logic of into , or (to avoid duplication) move that logic to a new function in libcore that takes a parameter and that is called by both and . This function would need to be public because is in a different crate, but it should be prema-unstable and .
I would classify the priority of this bug as low. Although this call to is UB, I expect Miri checking for it explicitly is the only case where that has any consequence in today’s implementation: behaves as expected (for the purpose of WTF-8) in the surrogate range and does not exploit this UB The "layout" of in rustc excludes values beyond but not surrogates:
By the way, the docs at feel insufficient: Which values are invalid? Similarly, and say that represents Unicode Scalar values, but I couldn’t find it documented anywhere that constructing an out of range is Undefined Behavior rather than "merely" a logic bug. Is this specified elsewhere? What is the closest we have to a written down normative resource that specifies what is or isn’t UB in the the Rust language? (For APIs I assume this is the responsibility of their respective doc-comments.)
I agree the impact is low, but it's not just Miri -- this blocks , which is how I discovered the problem. That would be
But then what is "unchecked" about it? Elsewhere in that file the code is careful not to construct a from a without checking for surrogates: That made me assume the author was aware that surrogates in are UB.


Question: #[stable(feature = "rust1", since = "1.0.0")] #[inline] pub fn len_utf8(self) -> usize { <del> let code = self as u32; if code < MAX_ONE_B { 1 } else if code < MAX_TWO_B { 2 } else if code < MAX_THREE_B { 3 } else { 4 } </del> <ins> len_utf8(self as u32) </ins> } /// Returns the number of 16-bit code units this `char` would need if

The type contains a (generalized-UTF-8-encoded) sequence of code point (including potentially surrogates) that doesn’t form a surrogate pair. doesn’t check for surrogate pairs. is a public method that is documented as returning a scalar value, therefore excluding all surrogates. Ok I looked into it, there are three different people involved. The original code in 2014 was YOLO Later in 2014, moved to duplicating logic instead. In 2015, PR which first imported WTF-8 support in libstd deduplicated that logic by adding a function that takes . (I knew that approach sounded familiar…) In 2016, PR changed the signature of and in passing removed . It made use + instead, presumably in the middle of updating many callers other.
Okay, so the fix would be to revert the part of that removed ?
That or copy into . I find them both not great, so meh.
Even with that done, there's still UB in another testcase: This is converting something to a before calling -- so probably the same issue as the above, just for a different encoding.


Question: <ins> #![feature(no_core)] #![no_core] // @set 1.1.0 = "$.index[*][?(@.docs=='1.1.0')].id" // @set 2.1.0 = "$.index[*][?(@.docs=='2.1.0')].id" // @set 2.1.1 = "$.index[*][?(@.docs=='2.1.1')].id" // @set 2.2.1 = "$.index[*][?(@.docs=='2.2.1')].id" // @set 2.3.0 = "$.index[*][?(@.docs=='2.3.0')].id" // @set 3.1.1 = "$.index[*][?(@.docs=='3.1.1')].id" // @set 3.1.2 = "$.index[*][?(@.docs=='3.1.2')].id" // @set 3.2.0 = "$.index[*][?(@.docs=='3.2.0')].id" // @set 3.2.2 = "$.index[*][?(@.docs=='3.2.2')].id" // @set 3.3.0 = "$.index[*][?(@.docs=='3.3.0')].id" // @set 3.3.1 = "$.index[*][?(@.docs=='3.3.1')].id" pub enum EnumWithStrippedTupleVariants { // @is    "$.index[*][?(@.name=='None')].inner.variant_kind" '"tuple"' // @count "$.index[*][?(@.name=='None')].inner.variant_inner[*]" 0 None(), // @is    "$.index[*][?(@.name=='One')].inner.variant_kind" '"tuple"' // @count "$.index[*][?(@.name=='One')].inner.variant_inner[*]" 1 // @is    "$.index[*][?(@.name=='One')].inner.variant_inner[0]" $1.1.0 One(/** 1.1.0*/ bool), // @is    "$.index[*][?(@.name=='OneHidden')].inner.variant_kind" '"tuple"' // @count "$.index[*][?(@.name=='OneHidden')].inner.variant_inner[*]" 1 // @is    "$.index[*][?(@.name=='OneHidden')].inner.variant_inner[0]" null OneHidden(#[doc(hidden)] bool), // @is    "$.index[*][?(@.name=='Two')].inner.variant_kind" '"tuple"' // @count "$.index[*][?(@.name=='Two')].inner.variant_inner[*]" 2 // @is    "$.index[*][?(@.name=='Two')].inner.variant_inner[0]" $2.1.0 // @is    "$.index[*][?(@.name=='Two')].inner.variant_inner[1]" $2.1.1 Two(/** 2.1.0*/ bool, /** 2.1.1*/ bool), // @is    "$.index[*][?(@.name=='TwoLeftHidden')].inner.variant_kind" '"tuple"' // @count "$.index[*][?(@.name=='TwoLeftHidden')].inner.variant_inner[*]" 2 // @is    "$.index[*][?(@.name=='TwoLeftHidden')].inner.variant_inner[0]" null // @is    "$.index[*][?(@.name=='TwoLeftHidden')].inner.variant_inner[1]" $2.2.1 TwoLeftHidden(#[doc(hidden)] bool, /** 2.2.1*/ bool), // @is    "$.index[*][?(@.name=='TwoRightHidden')].inner.variant_kind" '"tuple"' // @count "$.index[*][?(@.name=='TwoRightHidden')].inner.variant_inner[*]" 2 // @is    "$.index[*][?(@.name=='TwoRightHidden')].inner.variant_inner[0]" $2.3.0 // @is    "$.index[*][?(@.name=='TwoRightHidden')].inner.variant_inner[1]" null TwoRightHidden(/** 2.3.0*/ bool, #[doc(hidden)] bool), // @is    "$.index[*][?(@.name=='TwoBothHidden')].inner.variant_kind" '"tuple"' // @count "$.index[*][?(@.name=='TwoBothHidden')].inner.variant_inner[*]" 2 // @is    "$.index[*][?(@.name=='TwoBothHidden')].inner.variant_inner[0]" null // @is    "$.index[*][?(@.name=='TwoBothHidden')].inner.variant_inner[1]" null TwoBothHidden(#[doc(hidden)] bool, #[doc(hidden)] bool), // @is    "$.index[*][?(@.name=='Three1')].inner.variant_kind" '"tuple"' // @count "$.index[*][?(@.name=='Three1')].inner.variant_inner[*]" 3 // @is    "$.index[*][?(@.name=='Three1')].inner.variant_inner[0]" null // @is    "$.index[*][?(@.name=='Three1')].inner.variant_inner[1]" $3.1.1 // @is    "$.index[*][?(@.name=='Three1')].inner.variant_inner[2]" $3.1.2 Three1(#[doc(hidden)] bool, /** 3.1.1*/ bool, /** 3.1.2*/ bool), // @is    "$.index[*][?(@.name=='Three2')].inner.variant_kind" '"tuple"' // @count "$.index[*][?(@.name=='Three2')].inner.variant_inner[*]" 3 // @is    "$.index[*][?(@.name=='Three2')].inner.variant_inner[0]" $3.2.0 // @is    "$.index[*][?(@.name=='Three2')].inner.variant_inner[1]" null // @is    "$.index[*][?(@.name=='Three2')].inner.variant_inner[2]" $3.2.2 Three2(/** 3.2.0*/ bool, #[doc(hidden)] bool, /** 3.2.2*/ bool), // @is    "$.index[*][?(@.name=='Three3')].inner.variant_kind" '"tuple"' // @count "$.index[*][?(@.name=='Three3')].inner.variant_inner[*]" 3 // @is    "$.index[*][?(@.name=='Three3')].inner.variant_inner[0]" $3.3.0 // @is    "$.index[*][?(@.name=='Three3')].inner.variant_inner[1]" $3.3.1 // @is    "$.index[*][?(@.name=='Three3')].inner.variant_inner[2]" null Three3(/** 3.3.0*/ bool, /** 3.3.1*/ bool, #[doc(hidden)] bool), } // @is "$.index[*][?(@.docs=='1.1.0')].name" '"0"' // @is "$.index[*][?(@.docs=='2.1.0')].name" '"0"' // @is "$.index[*][?(@.docs=='2.1.1')].name" '"1"' // @is "$.index[*][?(@.docs=='2.2.1')].name" '"1"' // @is "$.index[*][?(@.docs=='2.3.0')].name" '"0"' // @is "$.index[*][?(@.docs=='3.1.1')].name" '"1"' // @is "$.index[*][?(@.docs=='3.1.2')].name" '"2"' // @is "$.index[*][?(@.docs=='3.2.0')].name" '"0"' // @is "$.index[*][?(@.docs=='3.2.2')].name" '"2"' // @is "$.index[*][?(@.docs=='3.3.0')].name" '"0"' // @is "$.index[*][?(@.docs=='3.3.1')].name" '"1"' // @is "$.index[*][?(@.docs=='1.1.0')].inner" '{"kind": "primitive", "inner": "bool"}' // @is "$.index[*][?(@.docs=='2.1.0')].inner" '{"kind": "primitive", "inner": "bool"}' // @is "$.index[*][?(@.docs=='2.1.1')].inner" '{"kind": "primitive", "inner": "bool"}' // @is "$.index[*][?(@.docs=='2.2.1')].inner" '{"kind": "primitive", "inner": "bool"}' // @is "$.index[*][?(@.docs=='2.3.0')].inner" '{"kind": "primitive", "inner": "bool"}' // @is "$.index[*][?(@.docs=='3.1.1')].inner" '{"kind": "primitive", "inner": "bool"}' // @is "$.index[*][?(@.docs=='3.1.2')].inner" '{"kind": "primitive", "inner": "bool"}' // @is "$.index[*][?(@.docs=='3.2.0')].inner" '{"kind": "primitive", "inner": "bool"}' // @is "$.index[*][?(@.docs=='3.2.2')].inner" '{"kind": "primitive", "inner": "bool"}' // @is "$.index[*][?(@.docs=='3.3.0')].inner" '{"kind": "primitive", "inner": "bool"}' // @is "$.index[*][?(@.docs=='3.3.1')].inner" '{"kind": "primitive", "inner": "bool"}' </ins>

At some point their should also be a for , and probably a way to tell what position each of the non stripped items are, as currently each of these 3 variants are documented with the same inner. but HTML gets a good representation:  The solution is probably to do what we do for structs, and store the , and a , such that each field of a varient gets an to hold the . We also should have a numfields, as even in that schema, you can't tell the difference between This also effects struct AFAIKT. I don't think this needs to be done now. I'll file an issue for it. Originally posted by in modify labels: +A-rustdoc-json +T-rustdoc
Related:


Question: use rustc_span::{BytePos, Span, Symbol}; use rustc_trait_selection::infer::InferCtxtExt; use rustc_trait_selection::traits::ObligationCtxt; <ins> use std::iter; </ins> use crate::borrow_set::TwoPhaseActivation; use crate::borrowck_errors;

<!-- 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 look like: or similar. The note and/or help are both subject to changes, this is just a basic idea. We could also conceivably rewrite the error message to expand on what the note says, like so: <!-- If the problem is not self-explanatory, please provide a rationale for the change. --<!-- If dramatically different output is caused by small changes, consider also adding them here. If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. The output might also be different depending on the Edition. --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
It's hard to get 'c' in line 3 during the context where the compiler errors out the second mutable borrow message, because the mutable borrow happens between
I don't think it's critical to mention in the diagnostic. We shouldn't let the difficulty of doing that stop us from trying to improve the message. label +D-newcomer-roadblock
I'd love to try to fix this, but sadly I'm not familiar with the internals of rustc. If someone could point me towards the section where this error is, I could give it a try.
Hi ! Whenever I try to dive into fixing a problem with rustc, I usually start with a search through the codebase. In this case, I'd search for strings that come from the error message: , , or : <img width="528" alt="image" src="https://user-"And that leads me to here: So then I'd use rust-analyzer to try to find all the usages of that method.


Question: use rustc_span::{BytePos, Span, Symbol}; use rustc_trait_selection::infer::InferCtxtExt; use rustc_trait_selection::traits::ObligationCtxt; <ins> use std::iter; </ins> use crate::borrow_set::TwoPhaseActivation; use crate::borrowck_errors;

In this case, turns out there's only one: And there we see that there is already some conditional suggestion being made; it calls . And it seems there's a family of those . So I think it would make sense to try to write your own or something like that. You'll need to figure out how to sort of "back track" from the MIR back to the HIR or the AST so you can figure out whether you're inside a loop. I would study the code in to try to figure out how to do that. And don't forget to write a handful of regression tests in somewhere, maybe in : https://rustc-dev- It might also be possible to perform this check at a higher level, say, in . If you can figure out that you're in a for loop, and that the user is trying to call on the iterator, then you could raise the error then.


Question: .primitive_type() .and_then(|t| self.cache.primitive_locations.get(&t).cloned()); <del> if let Some(did) = did { dids.insert(did); } </del> <ins> dids.extend(did); </ins> } } if let Some(generics) = i.trait_.as_ref().and_then(|t| t.generics()) { for bound in generics { <del> if let Some(did) = bound.def_id(self.cache) { dids.insert(did); } </del> <ins> dids.extend(bound.def_id(self.cache)); </ins> } } let impl_item = Impl { impl_item: item }; <del> if impl_item.trait_did().map_or(true, |d| self.cache.traits.contains_key(&d)) { </del> <ins> let impl_did = impl_item.def_id(); let trait_did = impl_item.trait_did(); if trait_did.map_or(true, |d| self.cache.traits.contains_key(&d)) { </ins> for did in dids { <del> if self.impl_ids.entry(did).or_default().insert(impl_item.def_id()) { self.cache .impls .entry(did) .or_insert_with(Vec::new) .push(impl_item.clone()); </del> <ins> if self.impl_ids.entry(did).or_default().insert(impl_did) { self.cache.impls.entry(did).or_default().push(impl_item.clone()); </ins> } } } else { <del> let trait_did = impl_item.trait_did().expect("no trait did"); </del> <ins> let trait_did = trait_did.expect("no trait did"); </ins> self.cache.orphan_trait_impls.push((trait_did, dids, impl_item)); } None

Generated rustdoc JSON for every one of dozens of crates I've looked at seems to contain unexpected inlined items that look like an block and its contents. I expected to see this happen: rustdoc JSON file contains only the items defined or re-exported by the corresponding crate. Instead, this happened: the rustdoc JSON file contains items like this: In this example, is and here are the names of the items contained in that impl (also part of the rustdoc JSON): Similarly, you can find items from : Invocation for generating rustdoc JSON: : You can find a variety of pre-generated rustdoc JSON files with this issue here: Briefly discussed in Zulip: https://rust- I'll have to work around this behavior to shield , which uses the same codebase as the playground link above. I can hold off on updating the playground for, say, another week, but at some point I'll need to upgrade it to include my workaround which means those items will cease being shown. label +T-rustdoc +A-rustdoc-json
Possibly duplicate of
Might be! Definitely at least some overlap, not entirely sure if duplicate. Do you mind if I ship the workaround for this in cargo-semver-checks and the playground, which will hide these items from our lints and from queries in the playground?
Yeah, it's easy enough to reproduce in raw json, I'm not worried about the repro breaking.


Question: // Now create the real type parameters. for i in 0..ast_generics.ty_params.len() { <del> let def = get_or_create_type_parameter_def(ccx, ast_generics, space, i as u32); </del> <ins> let def = get_or_create_type_parameter_def(ccx, ast_generics, space, i as u32, allow_defaults); </ins> debug!("ty_generics: def for type param: {:?}, {:?}", def, space); result.types.push(space, def); }

If I understand correctly, type parameter defaults have no effect in the block . Just like in PR , this should have a warning and then an error. Example cc
Argh, I guess I failed to cover those?
Nominating for triage.
triage: P-high


Question: <ins> error[E0004]: non-exhaustive patterns: `Tag(Exif, _)` not covered --> $DIR/issue-50900.rs:15:11 | LL | pub struct Tag(pub Context, pub u16); | ------------------------------------- `Tag` defined here ... LL |     match Tag::ExifIFDPointer { |           ^^^^^^^^^^^^^^^^^^^ pattern `Tag(Exif, _)` not covered | = help: ensure that all possible cases are being handled, possibly by adding wildcards or more match arms error: aborting due to previous error For more information about this error, try `rustc --explain E0004`. </ins>

I hope this is not already known, but my searching has not turned up anything. Compiling a rust binary with the dependency panices in nightly. How to reproduce: a new rust binary. to dependencies in This gives the following output It compiles on stable and beta. Edit: Just running in gives the same result.
Tried a few different nightlies. And it looks like it broke sometime between and
I have managed to get a much smaller example. Compiling this on nightly gives the above panic:
Looks like it's fixed in the newest nightly ()
Bisecting between ... gives as the regression PR.


Question: <ins> #![feature(const_generics)] #![allow(incomplete_features)] fn func<A, const F: fn(inner: A)>(outer: A) { //~^ ERROR: using function pointers as const generic parameters is forbidden F(outer); } fn main() {} </ins>

I've tried reducing this but wasn't really able to so far. I might try again some other time. The code below currently ICEs on Nightly (). When trying to reproduce locally for the backtrace, I had an older Nightly first () where this actually didn't crash the compiler, so it's apparently a regression. <details<summary<strongBacktrace</strong</summary<p</p</details
This is my first time using cargo-bisect-rustc and it's fantastic. It identified the regression as... searched nightlies: from nightly-2020-02-13 to nightly-2020-05-14 regressed nightly: nightly-2020-03-20 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.5.2</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
is a rollup commit. The only PR which was part of that and (to me) looks like it could have caused this issue is .
Triage: the feature was removed by and the ICE no longer occurs with the latest nightly.


Question: <ins> #![feature(const_generics)] #![allow(incomplete_features)] fn func<A, const F: fn(inner: A)>(outer: A) { //~^ ERROR: using function pointers as const generic parameters is forbidden F(outer); } fn main() {} </ins>

produces: <details</detailsIt should not be possible to access the type parameter in the type of the const parameter. cc Thanks to for .
Hi, I am new to rust compiler development and have decided to try to fix this issue to get started. If I understand the const-generics RFC correctly, type parameters can not be used in a const generic parameter because it cannot be ensured that the actual types have the "structural match" property. However, checking reveals that fn pointers (as well as raw pointers and empty arrays) always support structural matching, regardless of the types used within. My question is: is there another reason why const generic parameters are not allowed to use type parameters? If so, I think an additional check has to be to .
Actually, I think I may have interpreted. It looks like this example is intended to work to me. cc just to clarify.
Triage: the feature was removed by and the ICE no longer occurs with the latest nightly.


Question: <ins> #![feature(const_generics)] #![allow(incomplete_features)] fn func<A, const F: fn(inner: A)>(outer: A) { //~^ ERROR: using function pointers as const generic parameters is forbidden F(outer); } fn main() {} </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
Probably related to
Triage: the feature was removed by and the ICE no longer occurs with the latest nightly.


Question: <ins> #![feature(const_generics)] #![allow(incomplete_features)] fn func<A, const F: fn(inner: A)>(outer: A) { //~^ ERROR: using function pointers as const generic parameters is forbidden F(outer); } fn main() {} </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
Depends on const generics in type dependent paths afaict. See for more info. EDIT: Also depends on const generics with generic types. Merging does not close this issue
Triage: the feature was removed by and the ICE no longer occurs with the latest nightly.
Adding the following as a test might still be useful, even if it only errors with "using function pointers as const parameters is forbidden":


Question: [[package]] name = "rls" <del> version = "1.39.0" </del> <ins> version = "1.40.0" </ins> dependencies = [ "cargo", "cargo_metadata 0.8.0", "clippy_lints", "crossbeam-channel", "difference", <del> "env_logger 0.6.2", </del> <ins> "env_logger 0.7.0", </ins> "failure", "futures", "heck",

Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool rls 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! cc the PR reviewer, and nominating for compiler team prioritization.


Question: <ins> error[E0080]: evaluation of constant value failed --> $DIR/issue-81899.rs:10:5 | LL | const _CONST: &[u8] = &f(&[], |_| {}); |                        -------------- inside `_CONST` at $DIR/issue-81899.rs:4:24 ... LL |     panic!() |     ^^^^^^^^ |     | |     the evaluated program panicked at 'explicit panic', $DIR/issue-81899.rs:10:5 |     inside `f::<[closure@$DIR/issue-81899.rs:4:31: 4:37]>` at $SRC_DIR/std/src/panic.rs:LL:COL | = note: this error originates in the macro `$crate::panic::panic_2015` (in Nightly builds, run with -Z macro-backtrace for more info) error: aborting due to previous error For more information about this error, try `rustc --explain E0080`. </ins>

The following code causes compiler panics due to the first line without which the issue isn't reproducible. Calling the function outside of a constant context emits the right compiler errors. <!-- 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. --: <details<summary<strongBacktrace</strong</summary<p</p</details
FWIW, replacing the function body with still gives an ICE:
Minimized slightly further, without const generics: <details<summarybacktrace</summary</detailsThe ICE occurs back to . In , it errors with By making small changes such as making the closure no longer take paramters or removing the reference at It errors, instead of an ICE, on stable and nightly with
searched nightlies: from nightly-2020-08-16 to nightly-2021-02-03 regressed nightly: nightly-2020-12-28 searched commits: from to regressed commit: edit: for this code sample <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.0</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with:
cc
Just to clarify, AFAICT, this issue is not due to , the stabilization just allowed code with const generics to run into this. MCVE ICEs before and shows that this is a borrowck bug not related to const generics
Assigning as discussed as part of the and removing .
I'm not sure if this is identical problem or not. The error message is: and my code is: I need both parts or the COPY tuple for the error to trigger and I'm unsure why. And also, if I put in its own const the bug is not triggered.
Triage: No longer ICE with the latest nightly, I guess fixed it? Marking as .


Question: }; let encl_def_id = parent_item.unwrap_or(first_item.def_id); <ins> // If parent of encl_def_id is an enum, use the parent ID intead. let encl_def_id = get_parent_if_enum_variant(tcx, encl_def_id); </ins> let ignored_derived_impls = if let Some(ign_traits) = self.ignored_derived_traits.get(&encl_def_id) { let trait_list = ign_traits

<!-- 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: build cleanly Instead, this happened: Running the program shows the field is used: <!-- 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. --Rust version 1.77.0 (tested in playground) </p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Derived code is intentionally ignored for dead code analysis - if you try just You'll get a note explaining this. The note doesn't seem to be attached for warnings, just
Ah, so it's intentional. Interesting. I assume the solution is to mark it with then.
claim
release-assignment so can claim it
Error: Parsing assign command in failed: ...'assignment' ' so Please file an issue on GitHub at if there's a problem with this bot, or reach out on on Zulip.
claim
Note that while getting a warning if is just derived but never explicitly used may be understandable (as discussed in other issues), you will get a warning if you do use it explicitly (see ) which, in my opinion, should not be the case.
As mentioned above, the fix for this issue is adding a note about how derived traits are intentionally ignored, not to stop ignoring them.


Question: - [You can now pass the `--features` option multiple times to enable multiple features.][cargo/7084] <ins> Rustdoc ------- - [Documentation on `pub use` statements is prepended to the documentation of the re-exported item][63048] </ins> Misc ---- - [`rustc` will now warn about some incorrect uses of

At some point between Rust 1.34.0 and 1.39.0, the ability to add documentation to reexported items was , but I can't find it mentioned in either or the rust- blog posts. Maybe this should be mentioned in the RELEASE notes for the version that that feature? I have a crate that I use to test stuff, and used to document this: !
This was changed in 1.38 (coincidentally also the release rust-std spiked from a 61.2 MB to 173.3 MB download). are you interested in making a PR?
Sure, what are the PRs that made this possible?
Oh I have no idea :laughing: I found it by bisecting.
Looks like is it


Question: let ptr_ty = ptr.ty; // Create an *internal* temp for the pointer, so that unsafety // checking won't complain about the raw pointer assignment. <del> let ptr_temp = this.local_decls.push(LocalDecl::with_source_info( ptr_ty, source_info, ).internal()); </del> <ins> let ptr_temp = this .local_decls .push(LocalDecl::with_source_info(ptr_ty, source_info).internal()); </ins> let ptr_temp = Place::from(ptr_temp); let block = unpack!(this.into(ptr_temp, block, ptr)); this.into(this.hir.tcx().mk_place_deref(ptr_temp), block, val)

<!-- 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. --The code fails to pass <!-- 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. --Repo is at <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Oh that is interesting: is that expected? The other way around would make sense (assigning a into anything, really), but with a on the left, that seems odd? Or maybe the message just gets the sides wrong.
Yeah, that MIR looks really broken: Cc
This is probably due to this line: , and shouldn't have this, since they have type , not .
This is a super old issue going back all the way to the initial MIR implementation and I’m somewhat confident is documented somewhere, though I cannot find an issue for this. IIRC these invalid assignments only happen in unreachable basic blocks, so however wrong it looks in isolation, it is dead code and I think it never was a priority to fix either generation or the MIR validation we had back then for exactly that reason. Looks like is a new take on validation? Perhaps the easy fix would be to not validate unreachable blocks.


Question: fn run(self, builder: &Builder<'_>) { let stage = self.stage; let target = self.target; <ins> let crates = if self.crates.is_empty() { builder .in_tree_crates("sysroot", Some(target)) .iter() .map(|c| c.name.to_string()) .collect() } else { self.crates }; </ins> let out = match self.format { DocumentationFormat::Html => builder.doc_out(target), DocumentationFormat::Json => builder.json_doc_out(target),

I have pinned down the regression to a specific commit, thanks to recommending me . searched nightlies: from nightly-2024-07-28 to nightly-2024-07-30 regressed nightly: nightly-2024-07-30 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.9</summaryHost triple: aarch64-apple-darwin Reproduce with: : </details
Based on the commits in that rollup, I feel like might be the culprit, but it isn't obvious to me why that might be the case (cc
Thanks for the ping, will fix this.


Question: <ins> // Copyright 2017 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. pub struct Test; </ins>

I was going through some refactoring and the compiler exploded. No unsafe. The last bits of code I was playing with can be found , before I tried to refactor the example, the tests were building and passing. The macro that might be to blame is . I parked a branch with the code that made it blew up, you can find it here works, blows up. a happy compiler, worst case an unhappy one a dead compiler : Backtrace:
Minimal example:
Thanks that was a quick fix. Do you have a workaround until the fix makes it to master?
The ICE occurs when you have an item referenced in an impl signature is imported from an statement occurs within an impl. To work around the ICE, you can move the call to to a different free function.
Got it, it works , thanks!


Question: use core::borrow::{Borrow, BorrowMut}; use core::iter::FusedIterator; <ins> use core::mem::MaybeUninit; </ins> #[stable(feature = "encode_utf16", since = "1.8.0")] pub use core::str::EncodeUtf16; #[stable(feature = "split_ascii_whitespace", since = "1.34.0")]

I'm looking into the performance of / on mostly ascii strings, using a small microbenchmark to . Using linux perf tooling I see that the hot part of the code is the following large loop, which despite heavy use of sse2 instructions only seems to process 32 bytes per iteration. I don't see an easy way to improve the autovectorization of this code, but it should be relatively easy to explicitly vectorize it using , and I would like to prepare such a PR if there are no objections. As far as I know, is already in use inside , for example by .
The way the loop ors the bits for the is-ascii check into a single usize doesn't seem ideal for vectorization. keeping the lanes independent should yield better autovectorization results.
Thanks for the suggestion. I already started with a simd implementation, but now checked again if the autovectorization could be improved. With the following main loop The assembly and performance is indeed better, but there is still some weird shuffling and shifting going on: The explicit simd version looks a bit better, mostly because the ascii check directly translates to a : Do you have a preference here between autovectorization and explicit simd?
If the SIMD impl results in reasonable code across architectures, including some without SIMD then that should be fine. I think it would be the first time where we use portable simd unconditionally, so it could use some additional scrutiny. If it's only meant to target x86 with SSE2 then that'd mean having multiple paths and in that case we'd still have to tweak the generic path anyway. At that point we might as well just optimize the latter further. You can probably get rid of those too by keeping multiple bools in a small array. That way the optimizer will more easily see that it can shove them into independent simd lanes. Increasing the unroll count might help too to fit better into simd registers. We do get pretty decent autovectorization in other places in the standard library by massaging things into a state that basically looks like arrays-instead-of-SIMD-types. E.g.
It seems llvm is too "smart" for this trick, on its own that generates the exact same code. The trick does work, although it seems a bit fragile.


Question: use core::borrow::{Borrow, BorrowMut}; use core::iter::FusedIterator; <ins> use core::mem::MaybeUninit; </ins> #[stable(feature = "encode_utf16", since = "1.8.0")] pub use core::str::EncodeUtf16; #[stable(feature = "split_ascii_whitespace", since = "1.34.0")]

The following creates a instruction just like the simd version, but a slightly different alternative with a array and comparing against 0 does not. It only needs to be better than the autovectorized version on those platforms ;) My initial idea was to gate the simd code on either SSE2 or Neon (possibly also Altivec and RiscV). I'd also add a scalar loop for the non-multiple-of-N remainder, so all-ascii strings are fully handled by specialized code. Currently this remainder goes through the generic and code path. On other platforms, only the scalar loop would be used, since I assume the autovectorization would also generate suboptimal code. But I agree that if similar code quality can be achieved with autovectorization, that would be preferable. I'll open a PR after a little bit more polishing the code.


Question: version = "0.1.5" source = "registry+https://github.com/rust-lang/crates.io-index" dependencies = [ <del> "backtrace 0.3.25 (registry+https://github.com/rust-lang/crates.io-index)", </del> <ins> "backtrace 0.3.29 (registry+https://github.com/rust-lang/crates.io-index)", </ins> "failure_derive 0.1.5 (registry+https://github.com/rust-lang/crates.io-index)", ]

Every since a recent nightly update, both distributed nightlies and locally built produce backtraces where every level of the stack is represented only by their memory address and the label : Sadly I don't have a more specific repro case, but I can consistently reproduce locally. Older distributed nightlies do not present this behavior.
This happens consistently for me as well (also macOS).
I've been seeing this on Linux too, though it's been at least a week. (It also may have been fixed in a rustc newer than the one servo uses)
We should have tests for backtraces, so they don't regress again in the future.
this is certainly happening on master, and it's been happening for a while, but I assumed it was my env.
It just occurred to me that this might be related to the new symbol mangling (although I doubt it).
I've been experiencing this for about a week now (also on macOS). It definitely started prior to being merged. I also have the following in my :
has absolutely no changes if you don't use the flag, so it's not from there.
It's definitely , I tried before and after. It works if you enable the "coresymbolication" feature, though that's obviously not an option for distribution. I tried the latest master of , but it didn't help.
To confirm, is everyone only experiencing problems on OSX for rustc itself? Are there problems with other projects on OSX? can you please confirm or deny your experience from Linux? Throwing in a new platform here changes this quite a lot
Ok I believe I've found the issue for OSX, but if other platforms are still an issue that would be good to know
I've only experienced this with rustc itself on OSX. Things it builds seem ok, and linux/windows seem to be ok.
No, it's still happening on Linux as of yesterday (I can try again today). I also assumed it was my env.
I think the Linux issue is separate since it's been happening much longer than the OSX one
Hey, this seems to an issue on nightly for Windows (msvc) as well: This uses backtrace via :
if that's only using the crate and not using libstd, can you open an issue on the repository? The OSX issue should be fixed in , which I'd like to finish testing and then I'll send an update to libstd.