Question: self.as_mut_vec().truncate(0); // verbatim paths need . and .. removed <del> } else if comps.prefix_verbatim() { </del> <ins> } else if comps.prefix_verbatim() && !path.inner.is_empty() { </ins> let mut buf: Vec<_> = comps.collect(); for c in path.components() { match c {

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


Question: split_or_candidate |= self.simplify_candidate(candidate); } <del> if split_or_candidate { // At least one of the candidates has been split into subcandidates. // We need to change the candidate list to include those. let mut new_candidates = Vec::new(); </del> <ins> ensure_sufficient_stack(|| { if split_or_candidate { // At least one of the candidates has been split into subcandidates. // We need to change the candidate list to include those. let mut new_candidates = Vec::new(); </ins> <del> for candidate in candidates { candidate.visit_leaves(|leaf_candidate| new_candidates.push(leaf_candidate)); </del> <ins> for candidate in candidates { candidate.visit_leaves(|leaf_candidate| new_candidates.push(leaf_candidate)); } self.match_simplified_candidates( span, start_block, otherwise_block, &mut *new_candidates, fake_borrows, ); } else { self.match_simplified_candidates( span, start_block, otherwise_block, candidates, fake_borrows, ); </ins> } <del> self.match_simplified_candidates( span, start_block, otherwise_block, &mut *new_candidates, fake_borrows, ); } else { self.match_simplified_candidates( span, start_block, otherwise_block, candidates, fake_borrows, ); }; </del> <ins> }); </ins> } fn match_simplified_candidates(

I just tried the latest nightly (rustc 1.45.0-nightly ( 2020-06-01)) and noticed it can't compile one of the crates I work on. The crate does have an enum with a a huge number of variants (almost 6000), for which I use serde to derive Serialize and Deserialize. When building, even with just 'cargo check', the build fails with It works on stable 1.43.1. I tried running rustc under gdb. It didn't crash exactly the same way, I got SIGSEGV instead. Looking at the callstack in gdb, it is suspiciously deep ( functions deep). The top most functions are: If I reduce the number of enum variants to 5000, or stop using serde to derive Serialize/Deserialize, it starts working again. Since it works using stable, but not using nightly, I thought it might be some kind of regression. I totally realize this may not be a bug and that what I'm doing (Serde + giant enum) is just not a good idea. Accept my apologies if this kind of thing shouldn't be reported here!
cc -- I believe should have fixed this but I guess we're missing at least this case?
As an experiment I tried doubling the number of enum variants and compiling using stable. That still worked. So it seems the code wasn't just on the brink to stop working using the stable compiler.
Here is a github repo with a minimized test case for this issue:
It introduced a mechanism for dealing with this kind of issue, but I don’t doubt that we might have missed instances where the compiler is doing something recursive. MIR construction for matches appears to be one of these cases.
Yeah, that's what I expected, I just recalled seeing some commentary suggesting that we'd perhaps covered all cases. Definitely not unexpected that we didn't, though, nor did I intend to imply we should have :)
The beta seems to not have the problem. The problem does not occur with "rustc 1.44.0-beta.4 ( 2020-05-23)".
I saw the 'E-needs-mcve'-tag. Did you see my repro-case? (but maybe you're talking about something more self-contained, not referencing 'serde'?)


Question: split_or_candidate |= self.simplify_candidate(candidate); } <del> if split_or_candidate { // At least one of the candidates has been split into subcandidates. // We need to change the candidate list to include those. let mut new_candidates = Vec::new(); </del> <ins> ensure_sufficient_stack(|| { if split_or_candidate { // At least one of the candidates has been split into subcandidates. // We need to change the candidate list to include those. let mut new_candidates = Vec::new(); </ins> <del> for candidate in candidates { candidate.visit_leaves(|leaf_candidate| new_candidates.push(leaf_candidate)); </del> <ins> for candidate in candidates { candidate.visit_leaves(|leaf_candidate| new_candidates.push(leaf_candidate)); } self.match_simplified_candidates( span, start_block, otherwise_block, &mut *new_candidates, fake_borrows, ); } else { self.match_simplified_candidates( span, start_block, otherwise_block, candidates, fake_borrows, ); </ins> } <del> self.match_simplified_candidates( span, start_block, otherwise_block, &mut *new_candidates, fake_borrows, ); } else { self.match_simplified_candidates( span, start_block, otherwise_block, candidates, fake_borrows, ); }; </del> <ins> }); </ins> } fn match_simplified_candidates(

I saw the repo, but it still needs some work to be reduced to a viable regression test case that could be included into the repo along with fix. This is what I’m working on now as I already have the fix itself.
Assigning .
If anyone else gets here having the same problem, manually implementing Serialize and Deserialize rather than relying on serde-derive, is one way around the problem. I adapted the examples at for my enum and this made the compile time insignificant. It also improved performance using the old rust considerably.
Mhh, I remember having seen some other issues related to derive macros recently... cc who might know.


Question: } } #[stable(feature = "rust1", since = "1.0.0")] <del> impl Seek for File { </del> <ins> impl Seek for &File { </ins> fn seek(&mut self, pos: SeekFrom) -> io::Result<u64> { self.inner.seek(pos) } } #[stable(feature = "rust1", since = "1.0.0")] <del> impl Read for &File { </del> <ins> impl Read for File { </ins> fn read(&mut self, buf: &mut [u8]) -> io::Result<usize> { <del> self.inner.read(buf) </del> <ins> (&*self).read(buf) } fn read_vectored(&mut self, bufs: &mut [IoSliceMut<'_>]) -> io::Result<usize> { (&*self).read_vectored(bufs) </ins> } fn read_buf(&mut self, cursor: BorrowedCursor<'_>) -> io::Result<()> { <del> self.inner.read_buf(cursor) </del> <ins> (&*self).read_buf(cursor) } #[inline] fn is_read_vectored(&self) -> bool { (&&*self).is_read_vectored() } fn read_to_end(&mut self, buf: &mut Vec<u8>) -> io::Result<usize> { (&*self).read_to_end(buf) } fn read_to_string(&mut self, buf: &mut String) -> io::Result<usize> { (&*self).read_to_string(buf) } } #[stable(feature = "rust1", since = "1.0.0")] impl Write for File { fn write(&mut self, buf: &[u8]) -> io::Result<usize> { (&*self).write(buf) } fn write_vectored(&mut self, bufs: &[IoSlice<'_>]) -> io::Result<usize> { (&*self).write_vectored(bufs) } #[inline] fn is_write_vectored(&self) -> bool { (&&*self).is_write_vectored() } fn flush(&mut self) -> io::Result<()> { (&*self).flush() } } #[stable(feature = "rust1", since = "1.0.0")] impl Seek for File { fn seek(&mut self, pos: SeekFrom) -> io::Result<u64> { (&*self).seek(pos) </ins> } <ins> } #[stable(feature = "io_traits_arc", since = "CURRENT_RUSTC_VERSION")] impl Read for Arc<File> { fn read(&mut self, buf: &mut [u8]) -> io::Result<usize> { (&**self).read(buf) } </ins> fn read_vectored(&mut self, bufs: &mut [IoSliceMut<'_>]) -> io::Result<usize> { <del> self.inner.read_vectored(bufs) </del> <ins> (&**self).read_vectored(bufs) } fn read_buf(&mut self, cursor: BorrowedCursor<'_>) -> io::Result<()> { (&**self).read_buf(cursor) </ins> } #[inline] fn is_read_vectored(&self) -> bool { <del> self.inner.is_read_vectored() </del> <ins> (&**self).is_read_vectored() </ins> } <del> // Reserves space in the buffer based on the file size when available. </del> fn read_to_end(&mut self, buf: &mut Vec<u8>) -> io::Result<usize> { <del> let size = buffer_capacity_required(self); buf.reserve(size.unwrap_or(0)); io::default_read_to_end(self, buf, size) </del> <ins> (&**self).read_to_end(buf) </ins> } <del> // Reserves space in the buffer based on the file size when available. </del> fn read_to_string(&mut self, buf: &mut String) -> io::Result<usize> { <del> let size = buffer_capacity_required(self); buf.reserve(size.unwrap_or(0)); io::default_read_to_string(self, buf, size) </del> <ins> (&**self).read_to_string(buf) </ins> } } <del> #[stable(feature = "rust1", since = "1.0.0")] impl Write for &File { </del> <ins> #[stable(feature = "io_traits_arc", since = "CURRENT_RUSTC_VERSION")] impl Write for Arc<File> { </ins> fn write(&mut self, buf: &[u8]) -> io::Result<usize> { <del> self.inner.write(buf) </del> <ins> (&**self).write(buf) </ins> } fn write_vectored(&mut self, bufs: &[IoSlice<'_>]) -> io::Result<usize> { <del> self.inner.write_vectored(bufs) </del> <ins> (&**self).write_vectored(bufs) </ins> } #[inline] fn is_write_vectored(&self) -> bool { <del> self.inner.is_write_vectored() </del> <ins> (&**self).is_write_vectored() </ins> } fn flush(&mut self) -> io::Result<()> { <del> self.inner.flush() </del> <ins> (&**self).flush() </ins> } } <del> #[stable(feature = "rust1", since = "1.0.0")] impl Seek for &File { </del> <ins> #[stable(feature = "io_traits_arc", since = "CURRENT_RUSTC_VERSION")] impl Seek for Arc<File> { </ins> fn seek(&mut self, pos: SeekFrom) -> io::Result<u64> { <del> self.inner.seek(pos) </del> <ins> (&**self).seek(pos) </ins> } }

Some types ( and in particular) implement and on . If one of these types are wrapped in an (or ), there is no real reason why one shouldn't be able to call or methods on it. For example, this code should compile: I think this can be implemented pretty straightforwardly by adding the following impls to and : Are there good reasons for why impls like these shouldn't be ?
Closing because generic impls like proposed won't behave correctly, as described in .


Question: const D: _ = 42; //~^ ERROR the type placeholder `_` is not allowed within types on item signatures // type E: _; // FIXME: make the parser propagate the existence of `B` <ins> type F: std::ops::Fn(_); //~^ ERROR the type placeholder `_` is not allowed within types on item signatures </ins> } impl Qux for Struct { type A = _;

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


Question: target } <ins> const MAX_INT_REGS: usize = 6; // RDI, RSI, RDX, RCX, R8, R9 const MAX_SSE_REGS: usize = 8; // XMM0-7 </ins> pub fn compute_abi_info<'a, Ty, C>(cx: &C, fty: &mut FnType<'a, Ty>) where Ty: TyLayoutMethods<'a, C> + Copy, C: LayoutOf<Ty = Ty, TyLayout = TyLayout<'a, Ty>> + HasDataLayout { <del> let mut int_regs = 6; // RDI, RSI, RDX, RCX, R8, R9 let mut sse_regs = 8; // XMM0-7 </del> <ins> let mut int_regs = MAX_INT_REGS; let mut sse_regs = MAX_SSE_REGS; </ins> let mut x86_64_ty = |arg: &mut ArgType<'a, Ty>, is_arg: bool| { let mut cls_or_mem = classify_arg(cx, arg); <del> let mut needed_int = 0; let mut needed_sse = 0; </del> if is_arg { if let Ok(cls) = cls_or_mem { <ins> let mut needed_int = 0; let mut needed_sse = 0; </ins> for &c in &cls { match c { Some(Class::Int) => needed_int += 1,

We encountered this with WebRender, where we exposed a method in Rust to the Gecko, and the last parameters supplied appeared random on the Rust side. I made a reduced test case adapted from it that you can grab at: It is a very simple test case where the C++ program puts all the parameters on the stack, prints the expected values of some of them, and calls the Rust method. The Rust method prints the values it received. We have enough parameters to fill up the registers used in the calling convention, and once we get to pushing things on the stack, it goes wrong. You can see from the output that they mismatch. ./build- && ./run- outputs c++ expect width=7 height=8 c++ expect slice=9 10 11 12 c++ expect outset=13. 13. 13. 13. c++ expect repeat h=0 v=0 got rust image 6 width 7 height 8 got rust slice SideOffsets { top: 9, right: 10, bottom: 11, left: 12 } got rust outset LayoutGeometry { top: 0.0, left: 0.0, width: 0.0, height: 0.0 } got rust repeat h=26 v=58 Note that the earlier parameters are correct, but the last 3 (outset, repeat h and repeat v) are all incorrect.
Is there an upstream issue in WebRender you can link? What platform is this happening on?
The Gecko side integrating with WebRender was disabled, and I have been working to re-enable this in You can find the code in question at: I intend to just work around this using structs for the moment as part of the aforementioned bug.
We're seeing this on all of our x64 platforms (win, mac, linux; all using clang). It looks like a pretty clear bug in our sysv callee ABI for x64 when there are lots of arguments.
<details<summaryrustc callee llvm-ir </summary</details<details<summaryclang caller llvm-ir </summary</detailsJust the signatures:
Note to self: can go negative from scalar integer arguments after the 6 integer registers have been exhausted and then is always true. Will try to fix soon (also I wonder if this is a stable-to-stable regression from years ago?).


Question: target } <ins> const MAX_INT_REGS: usize = 6; // RDI, RSI, RDX, RCX, R8, R9 const MAX_SSE_REGS: usize = 8; // XMM0-7 </ins> pub fn compute_abi_info<'a, Ty, C>(cx: &C, fty: &mut FnType<'a, Ty>) where Ty: TyLayoutMethods<'a, C> + Copy, C: LayoutOf<Ty = Ty, TyLayout = TyLayout<'a, Ty>> + HasDataLayout { <del> let mut int_regs = 6; // RDI, RSI, RDX, RCX, R8, R9 let mut sse_regs = 8; // XMM0-7 </del> <ins> let mut int_regs = MAX_INT_REGS; let mut sse_regs = MAX_SSE_REGS; </ins> let mut x86_64_ty = |arg: &mut ArgType<'a, Ty>, is_arg: bool| { let mut cls_or_mem = classify_arg(cx, arg); <del> let mut needed_int = 0; let mut needed_sse = 0; </del> if is_arg { if let Ok(cls) = cls_or_mem { <ins> let mut needed_int = 0; let mut needed_sse = 0; </ins> for &c in &cls { match c { Some(Class::Int) => needed_int += 1,

Looks like this was working circa 1.0, but has been broken at least since 1.12. Oof.
Do you need this fixed on beta as well, btw?
it would certainly be great if you uplifted this, but we have to work around it for the next few weeks anyway


Question: err.help("the semantics of slice patterns changed recently; see issue #62254"); } else if self.autoderef(span, expected_ty) .any(|(ty, _)| matches!(ty.kind(), ty::Slice(..) | ty::Array(..))) <del> && let (Some(span), true) = (ti.span, ti.origin_expr) </del> <ins> && let Some(span) = ti.span && let Some(_) = ti.origin_expr </ins> && let Ok(snippet) = self.tcx.sess.source_map().span_to_snippet(span) { let ty = self.resolve_vars_if_possible(ti.expected);

<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. If you cannot produce a minimal reproduction case (something that would work in isolation), please provide the steps or even link to a repository that causes the problematic output to occur. --Given the following code: The current output is: <!-- The following is not always necessary. --Ideally the output should suggest to the user that they need to initialize the enum variant's value in order to use the . <!-- If the problem is not self-explanatory, please provide a rationale for the change. --<!-- If dramatically different output is caused by small changes, consider also adding them here. If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. The output might also be different depending on the Edition. --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Can you give the output of what it should look like?
It should probably look similar to the suggestion given for and So I guess sth. like: Edit: Or instead of saying “to instantiate this tuple variant” we could say “to call this function” like it's done for the erroneous snippet (where is a ).
claim
commit the fix


Question: use rustc_hir::intravisit::{self, Visitor}; use rustc_hir::Node; use rustc_middle::bug; <del> use rustc_middle::middle::codegen_fn_attrs::CodegenFnAttrFlags; </del> <ins> use rustc_middle::middle::codegen_fn_attrs::{CodegenFnAttrFlags, CodegenFnAttrs}; </ins> use rustc_middle::middle::privacy::{self, Level}; use rustc_middle::mir::interpret::{ConstAllocation, ErrorHandled, GlobalAlloc}; use rustc_middle::query::Providers;

I tried this code: I expected to see this happen: Compiles successfully. Instead, this happened: Fails with this error: nightly-2024-06-26 and earlier. nightly-2024-06-27 and later, starting with . See for a discussion of the issue. : cc
To elaborate, the difference is in symbols.o. Here's a dump of symbols.o before the change: And here's after: Spot the difference. Spoiler: is now present.
So is that right or wrong? The static is "used" so marking it exported to ensure it does not get optimized away seems to make sense? I don't understand why this is a problem only on Windows.
Well that's not a problem per se but if we want to do that then we have to do it properly. is defined as a in (on my machine). This is linked directly and not in a lib file. So it's already being included. There's no reason for to include it. The only issue is that is being emitted as a comdat, meaning the linker is still allowed to remove it. We could just not do that (or add a linker directive). But that's a pre-existing issue.
I don't understand any part of that.^^ Should my PR get reverted or is there a better way to fix this regression? If there is a better way, I am afraid I lack the knowledge to implement and test it. I don't understand symbol handling on Linux, let alone on Windows.
I don't know enough about the Rust compiler to say. My complete guess would be that was silently broken before but now it's nosily broken.
Hm, who would understand our Windows linking story? ?
After CGU partitioning, we try to internalize symbols when possible. What is surprising to me is that this process only looks at export level, ignoring used attribute (in the contrast to say the internalization during fat LTO). Consequently we have a situation where synthetic object file references a symbol that is no longer exported (on Linux that does not result in a linking error, even though reference is unresolved). Anyway, if the consequence of would be to export those symbols for no reason, that seems rather counter productive to me.


Question: use rustc_hir::intravisit::{self, Visitor}; use rustc_hir::Node; use rustc_middle::bug; <del> use rustc_middle::middle::codegen_fn_attrs::CodegenFnAttrFlags; </del> <ins> use rustc_middle::middle::codegen_fn_attrs::{CodegenFnAttrFlags, CodegenFnAttrs}; </ins> use rustc_middle::middle::privacy::{self, Level}; use rustc_middle::mir::interpret::{ConstAllocation, ErrorHandled, GlobalAlloc}; use rustc_middle::query::Providers;

Ah, the behaviour was working to spec before: So I think I'd agree that is the wrong approach and should be reverted because this currently ends up conflating different things. Maybe changes elsewhere would fix this but I don't want to speculate.
the separate issue you pointed out earlier in is presumably still relevant for ?
Could this explain recent CI flakiness? The failure at and a couple other failed merges (linked on that thread, also the retries) have been msvc linker errors.
That's unfortunate. :/ Our reachable symbol code is such a spaghetti mess... I guess I'll just have to copy-paste more things into Miri then. :shrug: I am traveling right now, I'd appreciate if someone else could do the revert.
The following patch should fix the incorrect internalization I mentioned earlier: As for the question whether those symbols should be exported in the first place, it might be necessary for COFF and . The following code suggests that would not have the desired effect otherwise I don't have access to windows environment at the moment to verify that, so I don't plan to work on this myself.
Ooh this is also the stuff that also broke several ci-runs already ...
Looks like this did not fully fix the ci failures :melting_face:
Makes sense: some CI failures look non-deterministic, while we'd expect this error not to be.
Alternative approach for Miri:


Question: } } <del> #[cfg(any(target_arch = "x86_64", target_arch = "arm"))] </del> <ins> #[cfg(not(target_arch = "x86"))] </ins> #[macro_use] mod imp { pub type ptr_t = u32;

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


Question: /// } /// ``` #[stable(feature = "rust1", since = "1.0.0")] <ins> #[inline] </ins> pub fn raw_os_error(&self) -> Option<i32> { match self.repr { Repr::Os(i) => Some(i),

I am facing a problem while reading different kinds of binary formats. If you are going to read primitives like too often, then performance degrades. This is mainly due to the fact that returns box. Also it does boxing TWICE! doc link: I wrote simple bench to show pref problem. Use to get it We can clearly see that performance is degrading. The more calls it takes to read, the worse the results will be. The first very popular crate that comes to mind is . It mainly depends on the data format. But what if you need to receive data over the network? The attacker may abuse wrong data to make ton of pointless memory allocations. stdlib is also use often enough. Let's run a simple bash to make sure of this In many cases, you will see that it is used . stdlib sometimes create with macro, however it doesn't happen very often. Consider adding a new static method such as and new internal member of that's enum. How about using something like , but with static lifetime? : Update 07.03.2021: Benchmarks have been improved as per the comment. This should show the problem better.
The "std_err" bench is still pretty slow though
Yes, I probably made a mistake while copying the code for the benchmark of . It should be . However, this shows that not zero-cost.
This is fixed by
Turns out it was three times, if you also count the that the is copied into.
Running your benchmark (thanks!): Before: After: Looks like it isn't completely solved yet. Adding to now... :)
That fixed it.


Question: <ins> // revisions: current next //[next] compile-flags: -Znext-solver // check-pass #![feature(non_lifetime_binders)] //~^ WARN the feature `non_lifetime_binders` is incomplete pub trait Foo<T: ?Sized> { type Bar<K: ?Sized>: ?Sized; } impl Foo<usize> for () { type Bar<K: ?Sized> = K; } pub fn f<T1, T2>(a: T1, b: T2) where T1: for<T> Foo<usize, Bar<T> = T>, T2: for<T> Foo<usize, Bar<T> = <T1 as Foo<usize>>::Bar<T>>, { } fn it_works() { f((), ()); } 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. --minimal project with full compiler output can be found here cargo 1.77.0-nightly ( 2024-01-09) : <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details


Question: <ins> // Copyright 2016 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. // aux-build:plugin.rs #![feature(proc_macro)] #[macro_use] extern crate plugin; #[derive(Foo, Bar)] struct Baz { a: i32, b: i32, } fn main() {} </ins>

Inlined from Another issue. If a struct has two different custom derives on it and the second one panics, the error span will point to the first one, not the one which panicked. Reproduction Script
was "Reproduction Script" supposed to be a link? I'm spinning this off from as I don't think it's going to block stabilization and/or closing that issue.
Reproduction script there is a summary tag
<details<summaryReproduction Script</summaryIn a crate called In another crate The error will highlight even though panicked. </details
This seems to be fixed now, so this issue can be closed.
I ran this as a test, and got the following output:


Question: /// "successfully written" (by returning nonzero success values from /// `write`), any 0-length writes from `inner` must be reported as i/o /// errors from this method. <del> pub(super) fn flush_buf(&mut self) -> io::Result<()> { </del> <ins> pub(in crate::io) fn flush_buf(&mut self) -> io::Result<()> { </ins> /// Helper struct to ensure the buffer is updated after all the writes /// are complete. It tracks the number of written bytes and drains them /// all from the front of the buffer when dropped.

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


Question: /// "successfully written" (by returning nonzero success values from /// `write`), any 0-length writes from `inner` must be reported as i/o /// errors from this method. <del> pub(super) fn flush_buf(&mut self) -> io::Result<()> { </del> <ins> pub(in crate::io) fn flush_buf(&mut self) -> io::Result<()> { </ins> /// Helper struct to ensure the buffer is updated after all the writes /// are complete. It tracks the number of written bytes and drains them /// all from the front of the buffer when dropped.

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: /// "successfully written" (by returning nonzero success values from /// `write`), any 0-length writes from `inner` must be reported as i/o /// errors from this method. <del> pub(super) fn flush_buf(&mut self) -> io::Result<()> { </del> <ins> pub(in crate::io) fn flush_buf(&mut self) -> io::Result<()> { </ins> /// Helper struct to ensure the buffer is updated after all the writes /// are complete. It tracks the number of written bytes and drains them /// all from the front of the buffer when dropped.

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: /// "successfully written" (by returning nonzero success values from /// `write`), any 0-length writes from `inner` must be reported as i/o /// errors from this method. <del> pub(super) fn flush_buf(&mut self) -> io::Result<()> { </del> <ins> pub(in crate::io) fn flush_buf(&mut self) -> io::Result<()> { </ins> /// Helper struct to ensure the buffer is updated after all the writes /// are complete. It tracks the number of written bytes and drains them /// all from the front of the buffer when dropped.

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: } let size = ret.layout.size; let bits = size.bits(); <del> if bits <= 128 { </del> <ins> if bits <= 256 { </ins> let unit = if bits <= 8 { Reg::i8() } else if bits <= 16 {

I have an issue with rust (now version 1.22.1) on Solaris sparc (64bit). On intel I don't see it. I originally see it as part of Firefox build () I now believe it's rustc issue (though it could be still issue with clang-sys). Any help would be greatly appreciated. Run output looks like: Stack: With tracing: Note that clanggetTranslationUnitCursor isn't called with 'tu' set to 0. I have find out that the issue seems to be with the size of CXCursor structure which is returned: CXCursor is 32 bytes long. But if I tell clang-sys it's 16 bytes everything is perfect (when it's 17 bytes or more it causes the trouble): Following is disassembly when CXCursor is pretended to be just 16 bytes: And now with 17 bytes:
I wrote more minimalistic version of test case which rules out use of clang-sys. On intel it works as expected: But on sparc it looks weird: But with this "hack" it looks better:
Ok. I'm new to both Rust and LLVM. I tried to create for above example llvm-ir data on intel and used llc to build it on sparc. The same result could be seen. Does it mean that that issue is rather in LLVM?! On intel I did: On Sparc I did: The output is bad. See comment above (). [1]
and are wrong; structs up to 32 bytes in size, i.e. 256 bits, are returned in registers. I was also suspicious of this code in general when it was first merged as it doesn't seem very long, and handling mixed float and int structs is a little fiddly. EDIT: Well, actually, should vary based on whether it's an argument (which can be up to 16 bytes) or return value (up to 32 bytes).
Can you please suggest how to implement this? I can confirm that when modifying to contain 256 my above test examples passes as expected (though Firefox still wouldn't build).
As mentioned above. With partial fix Firefox build dies later when it calls . Which takes three arguments and the problematic first one is again 32 bytes long structure ().
Maybe you can suggest a preliminary patch to at least improve the code generation?
Are you sure?


Question: } let size = ret.layout.size; let bits = size.bits(); <del> if bits <= 128 { </del> <ins> if bits <= 256 { </ins> let unit = if bits <= 8 { Reg::i8() } else if bits <= 16 {

That doesn't entirely control whether a is passed by value or indirectly, but specifically it handles s which the ABI treats like arrays of primitives (incl. SIMD vectors).


Question: <ins> error: missing `in` in `for` loop --> $DIR/issue-40782.rs:12:10 | 12 |     for i 0..2 { |          ^ help: try adding `in` here error: aborting due to previous error </ins>

Hello, with rustc 1.17.0-nightly ( 2017-03-22), the following code gives this error message: An improved error message could add a hint :
Current output: 1) How would you want to improve upon this? Adding a suggestion? 2) To do so, we could use the same strategy as in : in , try to continue building the expression as if the keyword had been found. If we find further errors, we revert the state of the compiler to right after trying to continue and return the error from . Otherwise we cancel that one and create a new custom diagnostic: 3) or just modify the existing error with the proposed (so it looks like the 2 above). []:
Looks like current output already is an improvement over the reported one, but eithwr 2 or 3 would make it even more obvious i guess. No strong opinions here
Seems to me that the third error is the most clear ("error: missing in loop"); I suspect people using fancy pattern features will figure out what's going on.


Question:
if !types.is_empty() { write!(w, "
Associated Types

 Associated Types

 ")?; for t in &types {

A page like has many things that could be useful to link to. These should be possible to link to by clicking on: [x] The header [x] 's on a page. [x] at the top On it's hit or miss: [x] Examples [x] Associated Types [x] Required Methods [x] Implementors On [x] Provided Methods I don't have any big use cases but when I want to link to these for something like this bug I can't link to any specific line. I gotta say go to vec page, scroll 75% to bottom. Squint hard to see it.
Just ran into this today; I'd really like to have links from the impls in the Implementors section to the source containing the impl.
Triage: we always need more links....
Update: Headers written in docs and (most) auto-generated headers are either fully hyperlinked or have a "section marker" symbol that shows up on hover. Major auto-generated page headers have links in the top of the sidebar of the page. Impl blocks do not have hyperlinks (yet); that's
Since got merged and closed out , that was the last major request on this issue, so i'll close this out. If you think of something else that needs a hyperlinked header, feel free to open a new issue or reopen this one.


Question: || found_assoc(tcx.types.u64) || found_assoc(tcx.types.u128) || found_assoc(tcx.types.f32) <del> || found_assoc(tcx.types.f32); </del> <ins> || found_assoc(tcx.types.f64); </ins> if found_candidate && actual.is_numeric() && !actual.has_concrete_skeleton()

This line looks like a typo to me, should it be ? Originally posted by in Currently, it affects line 1684. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
Yeah, this could be fixed.
Ideally a test should also be crafted that shows that this missing affects an error message or something.
claim


Question: if v.is_ascii() { bytes.push(cx.expr_u8(expr.span, v as u8)); } else { <del> cx.span_err(expr.span, "non-ascii char literal in bytes!") </del> <ins> cx.span_err(expr.span, "non-ascii char literal in bytes!"); err = true; </ins> } } <del> _ => cx.span_err(expr.span, "unsupported literal in bytes!") </del> <ins> _ => { cx.span_err(expr.span, "unsupported literal in bytes!"); err = true; } </ins> }, <del> _ => cx.span_err(expr.span, "non-literal in bytes!") </del> <ins> _ => { cx.span_err(expr.span, "non-literal in bytes!"); err = true; } </ins> } } <ins> // For some reason using quote_expr!() here aborts if we threw an error. // I'm assuming that the end of the recursive parse tricks the compiler // into thinking this is a good time to stop. But we'd rather keep going. if err { // Since the compiler will stop after the macro expansion phase anyway, we // don't need type info, so we can just return a DummyResult return DummyResult::expr(sp); } </ins> let e = cx.expr_vec_slice(sp, bytes); <ins> let e = quote_expr!(cx, { static BYTES: &'static [u8] = $e; BYTES}); </ins> MacExpr::new(e) }

With landed, the lifetime of is now problematic. Specifically, the following used to work and now fails: The lifetime of is now limited to that branch of the match, so it doesn't live long enough to be assigned to . I'm not sure if this means lifetimes need to change. The other option is that needs to return a . Unfortunately, the only way to do that right now is to make it equivalent to , which makes it no longer usable as the value of a constant (e.g. ). I'm thinking the right solution is to make it legal for me to say . I can type that right now, but the lifetime seems to be wholly ignored, as I get the exact same error with the following as I do with the example above: If becomes a valid expression with the lifetime, then could start evaluating to that and everything should work as expected. Furthermore, it would be nice (but perhaps not required) if , where all elements are compile-time constants, would implicitly be given the lifetime.
/cc
Yeah, this is kind of annoying. I worked around it in one specific case by having bytes! expand as follows: I certainly think one should be allowed to write a concrete lifetime as part of a slice or borrow expression, and ought to be legal -- we'll obviously have to impose more stringent constant-related rules. In the short term, we could adjust to expand in the pattern I showed above. What was unclear to me was whether this is sufficient workaround, or whether we'll want something more general. Interestingly, even if we used full inference, the expression you gave above would be illegal unless we introduce a special case for static byte strings, because it generates a conditional temporary (only on one arm of the match) and we can't handle the cleanup for such a case without zeroing, which we plan to remove (well, I guess we could also have a special case for temporary types [like ) that do not require drop glue, but I'd rather not).
Perhaps the simplest fix for now is to adjust the macro itself to expand to a static item as I showed. I should probably have done that more generally but I was ready to land that expletive branch already.
Won't that prevent from being able to expand to a static?
I already adjusted like that and is correct, it prevents , which is definitely already used in our codebase.
Ah, unfortunate.


Question: if v.is_ascii() { bytes.push(cx.expr_u8(expr.span, v as u8)); } else { <del> cx.span_err(expr.span, "non-ascii char literal in bytes!") </del> <ins> cx.span_err(expr.span, "non-ascii char literal in bytes!"); err = true; </ins> } } <del> _ => cx.span_err(expr.span, "unsupported literal in bytes!") </del> <ins> _ => { cx.span_err(expr.span, "unsupported literal in bytes!"); err = true; } </ins> }, <del> _ => cx.span_err(expr.span, "non-literal in bytes!") </del> <ins> _ => { cx.span_err(expr.span, "non-literal in bytes!"); err = true; } </ins> } } <ins> // For some reason using quote_expr!() here aborts if we threw an error. // I'm assuming that the end of the recursive parse tricks the compiler // into thinking this is a good time to stop. But we'd rather keep going. if err { // Since the compiler will stop after the macro expansion phase anyway, we // don't need type info, so we can just return a DummyResult return DummyResult::expr(sp); } </ins> let e = cx.expr_vec_slice(sp, bytes); <ins> let e = quote_expr!(cx, { static BYTES: &'static [u8] = $e; BYTES}); </ins> MacExpr::new(e) }

(I actually think we should allow statics to include nested blocks with other statics, but I guess that's a separate bug) Well, I'm not sure what's the easiest fix in that case, I guess just to fix the semantics of so that it guarantees static data. I'm not 100% sure what's implied by such a fix: it doesn't seem too hard ;)
cc


Question: let fs = fields.move_map(|f| { Spanned { span: folder.new_span(f.span), node: ast::FieldPat { <del> ident: f.node.ident, </del> <ins> ident: folder.fold_ident(f.node.ident), </ins> pat: folder.fold_pat(f.node.pat), is_shorthand: f.node.is_shorthand, }}

Test case: Compiles successfully on , causes an ICE on . Diff contains only , CC Found while trying to minimize , but filed separately since the error message is different and this one has a small test case.
Do you have a backtrace?
Yes of course. Sorry I forgot to include it: rust error: internal compiler error: attempted .defid() on invalid def: Err note: the compiler unexpectedly panicked. this is a bug. note: we would appreciate a bug report: note: run with for a backtrace thread 'rustc' panicked at 'Box<Any',


Question: let fs = fields.move_map(|f| { Spanned { span: folder.new_span(f.span), node: ast::FieldPat { <del> ident: f.node.ident, </del> <ins> ident: folder.fold_ident(f.node.ident), </ins> pat: folder.fold_pat(f.node.pat), is_shorthand: f.node.is_shorthand, }}

stack backtrace: 1: 0x7fc35e73fdf3 - std::sys::imp::backtrace::tracing::imp::write::hdfa3e34b856f69a3 2: 0x7fc35e74e5dd - std::panicking::defaulthook::{{closure}}::h20f8c1082e0ce86e 3: 0x7fc35e74e17b - std::panicking::defaulthook::hd31552ac08c2a241 4: 0x7fc35e74ea68 - std::panicking::rustpanicwithhook::h73969d230a072c1a 5: 0x7fc357eda667 - std::panicking::beginpanic::hb89a2261f4776ce3 6: 0x7fc357eef99f - rustcerrors::Handler::bug::h13b3b29154320abd 7: 0x7fc35bab053a - rustc::session::optspanbugfmt::{{closure}}::hfea18dd68f59976d 8: 0x7fc35baafff7 - rustc::session::optspanbugfmt::h7d370a0810dbdbbd 9: 0x7fc35baafce2 - rustc::session::bugfmt::hcde5f50c54004a4f 10: 0x7fc35b984552 - rustc::hir::def::Def::defid::h728c22aafbe84efc 11: 0x7fc35c6ddb3a - rustcprivacy::ObsoleteVisiblePrivateTypesVisitor::pathisprivatetype::h24756a49a68d1da9 12: 0x7fc35c6d53db - rustc::hir::intravisit::walkty::h64b13c0c45b7a09a 13: 0x7fc35c6d49ba - rustc::hir::intravisit::Visitor::visitfn::ha8ad665c42b1d643 14: 0x7fc35c6de7cf - <rustcprivacy::ObsoleteVisiblePrivateTypesVisitor<'a,


Question: let fs = fields.move_map(|f| { Spanned { span: folder.new_span(f.span), node: ast::FieldPat { <del> ident: f.node.ident, </del> <ins> ident: folder.fold_ident(f.node.ident), </ins> pat: folder.fold_pat(f.node.pat), is_shorthand: f.node.is_shorthand, }}

'tcxas rustc::hir::intravisit::Visitor<'tcx::visititem::hae9f32c7942ccca1 15: 0x7fc35c6deab5 - <rustcprivacy::ObsoleteVisiblePrivateTypesVisitor<'a, 'tcxas rustc::hir::intravisit::Visitor<'tcx::visititem::hae9f32c7942ccca1 16: 0x7fc35c6e1b7a - rustcprivacy::checkcrate::h5ba75e3c4ebe0690 17: 0x7fc35eaef747 - rustcdriver::driver::phase3runanalysispasses::{{closure}}::h388b9236cf305089 18: 0x7fc35ead66d6 - rustcdriver::driver::phase3runanalysispasses::h080c1a734c4f2909 19: 0x7fc35eac5425 - rustcdriver::driver::compileinput::hab55539b85c4ceed 20: 0x7fc35eb0ea51 - rustcdriver::runcompiler::h128b89b79f649304 21: 0x7fc35ea236fb - std::panicking::try::docall::h15bca94dda232804 22: 0x7fc35e757b06 - rustmaybecatchpanic 23: 0x7fc35ea44d01 - <F as alloc::boxed::FnBox<A::callbox::h8832766c4bda585b 24: 0x7fc35e74d470 - std::sys::imp::thread::Thread::new::threadstart::h7d03d727f96da002 25: 0x7fc357684453 - startthread 26: 0x7fc35e4147de - GI__clone 27: 0x0 - <unknown
triage: P-high Seems bad. Assigning to based on bisection.
Fixed in .


Question: let fs = fields.move_map(|f| { Spanned { span: folder.new_span(f.span), node: ast::FieldPat { <del> ident: f.node.ident, </del> <ins> ident: folder.fold_ident(f.node.ident), </ins> pat: folder.fold_pat(f.node.pat), is_shorthand: f.node.is_shorthand, }}

Servo compiles with rustc 2016-12-18, but not with 2016-12-21. Diff: The crate fails to build with: The method being called here is: Its return type is which is . This call is in another impl of the same method of the same trait: Adding an explicit type annotation works around this error, but only to uncover another very similar one, then another. The third one was in code generated by serde’s , so I gave up that approach. So far I haven’t managed to reduce a test case smaller than "most of Servo", sorry. I’m suspicious of (which is part of ) because it’s commit message mentions inference. I’m not building a compiler to confirm.
CC
Also fails in , so is not to blame. New diff: I don’t have another guess, and doing a full bisect would take a very long time…
I can't find the cause in that range, at least nothing changed in the compiler AFAICT. Can you try (the commit before larger rollup)?
Expanding the macro: (Even simplifying it, this is not using ) gives:
Alright, that matches what I've seen from What about a couple more steps of bisecting? Or maybe compiling this crate with the "servo" feature off (which, AFAICT, turns off all the macros 1.1 - they might be responsible).
Swapping the order of the two arms: Changing the pattern to : Hacking to not use the stable version of the compiler (so effectively disabling the feature and enabling the one) also gives the same error.
New range, based on manual bisect: good, bad. Diff: , which leaves only in-between. CC Also found more clues. More context for the code where the error happens: is a module generated by a macro, that contains re-exports of other modules: If I add a similar not in a macro: or if I change the original code to use the real path without going through a , this seems to work around this issue completely. … only to uncover another one:
Found another ICE, I don’t know if it’s related: .


Question: let fs = fields.move_map(|f| { Spanned { span: folder.new_span(f.span), node: ast::FieldPat { <del> ident: f.node.ident, </del> <ins> ident: folder.fold_ident(f.node.ident), </ins> pat: folder.fold_pat(f.node.pat), is_shorthand: f.node.is_shorthand, }}

Found a smaller test case for the inference issue: rust fn main() {} pub mod a { pub struct FontFamily; impl FontFamily { pub fn tocss(&self) -::std::fmt::Result { Ok(()) } } } macrorules! reexport { () ={ mod b { pub use a; } } } reexport!(); pub mod c { use b::a::FontFamily; struct FontFace { family: FontFamily } impl FontFace { pub fn tocss(&self) -::std::fmt::Result { try!(()); Ok(()) } } }
That "other ICE" is actually a direct observation of the bug, whereas this inference issue is some weird side-effect of the way we handle errors that don't stop compilation.
never mind, apparently it fails locally
triage: P-high Seems bad. Assigning to based on bisection.
Does this affect beta ()?
At the moment the latest successful nightly build is 3 days old. I don’t know how often playpen’s nigthly is updated. merged 2 days ago. (This is the rollup PR that merged , which introduced this issue if I did my manual bisecting correctly.) As far as I can tell no, is not reachable from and so beta is not affected.
Fixed in .


Question: <ins> // Copyright 2016 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. // aux-build:import_crate_var.rs // error-pattern: `$crate` may not be imported // error-pattern: `use $crate;` was erroneously allowed and will become a hard error #![feature(rustc_attrs)] #[macro_use] extern crate import_crate_var; m!(); #[rustc_error] fn main() {} </ins>

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: self.points.contains(row, index) } <ins> /// Returns an iterator of all the elements contained by the region `r` crate fn get_elements(&self, row: N) -> impl Iterator<Item = Location> + '_ { self.points .row(row) .into_iter() .flat_map(|set| set.iter()) .take_while(move |&p| self.elements.point_in_range(p)) .map(move |p| self.elements.to_location(p)) } </ins> /// Returns a "pretty" string value of the region. Meant for debugging. crate fn region_value_str(&self, r: N) -> String { <del> region_value_str( self.points .row(r) .into_iter() .flat_map(|set| set.iter()) .take_while(|&p| self.elements.point_in_range(p)) .map(|p| self.elements.to_location(p)) .map(RegionElement::Location), ) </del> <ins> region_value_str(self.get_elements(r).map(RegionElement::Location)) </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. --code from glacier <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
This one also crashes beta and stable release channel.
Huh, why was this not detected earlier if it was tracked in glacier as fixed?
If you add a annotation to the trait bound on , then it no longer ICEs. Here's the code: Output: And if you add the two feature attributes the above messages ask you to enable, it still does not ICE, but correctly errors with "evaluation of constant value failed." Based on some debugging which I , I think this ICE has to do with the lifetime in the bound , although I'm not exactly sure how. I am new to the Rust compiler, and I just chose this issue because it seemed like a good first issue to work on, so I will read the (thanks to for sharing this) and try to further debug this.
If you plan to work on this issue, I recommend claiming it so other people know that and don't start working on it too. You can claim the issue by commenting with . More details about how to use rustbot are . You may also want to read the of the guide.
claim


Question: /// (e.g. `min`, `minimum`, `max`, `maximum`); other aspects of their semantics and which IEEE 754 /// operation they correspond to are documented with the respective functions. /// <del> /// When a floating-point operation is executed in `const` context, the same rules apply: no /// guarantee is made about which of the NaN bit patterns described above will be returned. The /// result does not have to match what happens when executing the same code at runtime, and the /// result can vary depending on factors such as compiler version and flags. </del> <ins> /// When an arithmetic floating-point operation is executed in `const` context, the same rules /// apply: no guarantee is made about which of the NaN bit patterns described above will be /// returned. The result does not have to match what happens when executing the same code at /// runtime, and the result can vary depending on factors such as compiler version and flags. </ins> /// /// ### Target-specific "extra" NaN values // FIXME: Is there a better place to put this?

Pointed out by in the float docs are using the term "arithmetic" operations in a few places, but that term is never defined. Furthermore, the new NaN docs probably should use that term as well when discussing which operations the NaN rules apply to (instead of "non-bitwise floating point operations" which they use currently). By "arithmetic operations", the docs likely mean all operations except for unary , , , , , and .


Question: use clean::Variant::*; match variant { CLike(disr) => Variant::Plain(disr.map(|disr| disr.into_tcx(tcx))), <del> Tuple(fields) => Variant::Tuple( fields .into_iter() .filter_map(|f| match *f.kind { clean::StructFieldItem(ty) => Some(ty.into_tcx(tcx)), clean::StrippedItem(_) => None, _ => unreachable!(), }) .collect(), ), Struct(s) => Variant::Struct(ids(s.fields, tcx)), </del> <ins> Tuple(fields) => Variant::Tuple(ids_keeping_stripped(fields, tcx)), Struct(s) => Variant::Struct { fields_stripped: s.has_stripped_entries(), fields: ids(s.fields, tcx), }, </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: self.check_export_name(hir_id, &attr, span, target) } else if self.tcx.sess.check_name(attr, sym::rustc_args_required_const) { self.check_rustc_args_required_const(&attr, span, target, item) <ins> } else if self.tcx.sess.check_name(attr, sym::rustc_layout_scalar_valid_range_start) { self.check_rustc_layout_scalar_valid_range(&attr, span, target) } else if self.tcx.sess.check_name(attr, sym::rustc_layout_scalar_valid_range_end) { self.check_rustc_layout_scalar_valid_range(&attr, span, target) </ins> } else if self.tcx.sess.check_name(attr, sym::allow_internal_unstable) { self.check_allow_internal_unstable(hir_id, &attr, span, target, &attrs) } else if self.tcx.sess.check_name(attr, sym::rustc_allow_const_fn_unstable) {

<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --<!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
This isn't really a bug, it's just that it has bad diagnostics because it uses , which is a perma-unstable attribute. I would recommend against reporting bugs that need attributes unless they cause unsoundness.
MCVE:
Should I exclude all test programs that have a line starting with ? Thanks.
I don't personally feel comfortable setting a policy that we'll never fix ICEs with attributes, but they are definitely less likely to be bugs than other ICEs. Note that this isn't sufficient to catch programs that have an attribute, you can have arbitrary macros that play with conditional compilation, like . Catching and will probably hit the common cases, though (you may want to also include inner attributes).


Question: self.check_export_name(hir_id, &attr, span, target) } else if self.tcx.sess.check_name(attr, sym::rustc_args_required_const) { self.check_rustc_args_required_const(&attr, span, target, item) <ins> } else if self.tcx.sess.check_name(attr, sym::rustc_layout_scalar_valid_range_start) { self.check_rustc_layout_scalar_valid_range(&attr, span, target) } else if self.tcx.sess.check_name(attr, sym::rustc_layout_scalar_valid_range_end) { self.check_rustc_layout_scalar_valid_range(&attr, span, target) </ins> } else if self.tcx.sess.check_name(attr, sym::allow_internal_unstable) { self.check_allow_internal_unstable(hir_id, &attr, span, target, &attrs) } else if self.tcx.sess.check_name(attr, sym::rustc_allow_const_fn_unstable) {

Gives:
cc ICE-ing instead of user error on misuse seems somewhat okay given that it's an internal attribute, IMO.
agreed. We don't protect against mis-use of rustc internal attributes beyond making sure that you can't trivially create buggy code. I don't think we should put any effort into making this nicer to use and instead create the const-generic based replacement.


Question: /// Returns a map from a sufficiently visible external item (i.e. an external item that is /// visible from at least one local module) to a sufficiently visible parent (considering /// modules that re-export the external item to be parents). <del> fn visible_parent_map<'a>(&'a self) -> ::std::cell::RefMut<'a, DefIdMap<DefId>> { let mut visible_parent_map = self.visible_parent_map.borrow_mut(); if !visible_parent_map.is_empty() { return visible_parent_map; } </del> <ins> fn visible_parent_map<'a>(&'a self) -> ::std::cell::Ref<'a, DefIdMap<DefId>> { { let visible_parent_map = self.visible_parent_map.borrow(); if !visible_parent_map.is_empty() { return visible_parent_map; } } </ins> use std::collections::vec_deque::VecDeque; use std::collections::hash_map::Entry; <ins> let mut visible_parent_map = self.visible_parent_map.borrow_mut(); </ins> for cnum in (1 .. self.next_crate_num().as_usize()).map(CrateNum::new) { let cdata = self.get_crate_data(cnum);

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: without modifying the original"] #[stable(feature = "unicode_case_mapping", since = "1.2.0")] pub fn to_lowercase(&self) -> String { <del> let out = convert_while_ascii(self.as_bytes(), u8::to_ascii_lowercase); </del> <ins> let (mut s, rest) = convert_while_ascii(self, u8::to_ascii_lowercase); </ins> <del> // Safety: we know this is a valid char boundary since // out.len() is only progressed if ascii bytes are found let rest = unsafe { self.get_unchecked(out.len()..) }; // Safety: We have written only valid ASCII to our vec let mut s = unsafe { String::from_utf8_unchecked(out) }; </del> <ins> let prefix_len = s.len(); </ins> for (i, c) in rest.char_indices() { if c == 'Σ' {

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: without modifying the original"] #[stable(feature = "unicode_case_mapping", since = "1.2.0")] pub fn to_lowercase(&self) -> String { <del> let out = convert_while_ascii(self.as_bytes(), u8::to_ascii_lowercase); </del> <ins> let (mut s, rest) = convert_while_ascii(self, u8::to_ascii_lowercase); </ins> <del> // Safety: we know this is a valid char boundary since // out.len() is only progressed if ascii bytes are found let rest = unsafe { self.get_unchecked(out.len()..) }; // Safety: We have written only valid ASCII to our vec let mut s = unsafe { String::from_utf8_unchecked(out) }; </del> <ins> let prefix_len = s.len(); </ins> for (i, c) in rest.char_indices() { if c == 'Σ' {

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: #[rustc_doc_primitive = "f16"] #[doc(alias = "half")] <del> /// A 16-bit floating point type (specifically, the "binary16" type defined in IEEE 754-2008). </del> <ins> /// A 16-bit floating-point type (specifically, the "binary16" type defined in IEEE 754-2008). </ins> /// /// This type is very similar to [`prim@f32`] but has decreased precision because it uses half as many /// bits. Please see [the documentation for `f32`](prim@f32) or [Wikipedia on half-precision


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. fn f(x: &mut u32) {} fn main() { let x = Box::new(3); f(&mut *x); } </ins>

This code: produces a helpful error message: But the analogous code using a : gives an error which doesn't point at the binding :
This is fixed today. I'm going to mark as E-needstest since it feels like the kind of thing that's easy to regress on -- a UI test would be best here.


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. fn f(x: &mut u32) {} fn main() { let x = Box::new(3); f(&mut *x); } </ins>

Before , this caused an LLVM error Afterwards, this causes an ICE (the rustc size is the correct one):
I am now getting a segfault in LLVM, but I'm uncertain whether that's actually the case, or just a local build problem.
Looks like called on a NULL pointer? Probably some missing check that something is indeed unsized, with actual metadata to go alongside it.
Appears to be fixed today. E-needstest.
It seems that a better diagnostic output is needed:
Why? I believe it's implemented as a feature now (maybe it should be ?).
it's unrelated to this issue, but rather to 's solution, merits at least a clarifying label pointing at the , as otherwise the compiler output makes you look at the following line exclusively, which isn't the cause for the . I know it definitely confused me_ :) Back to this issue, yes, the test in should be .


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. fn f(x: &mut u32) {} fn main() { let x = Box::new(3); f(&mut *x); } </ins>

Triage: this no longer ICEs. <details<summaryMeta</summary: rustc 1.16.0 ( 2017-03-10) binary: rustc commit-hash: commit-date: 2017-03-10 host: x86_64-pc-windows-gnu release: 1.16.0 LLVM version: 3.9 </details


Question: node_to_hir_id: self.node_to_hir_id.clone(), macro_def_scopes: self.macro_def_scopes.clone(), expansions: self.expansions.clone(), <del> keys_created: self.keys_created.clone(), </del> <ins> next_disambiguator: self.next_disambiguator.clone(), </ins> } } }

In investigating I was generating some source code, and using the shell script listed in we can see: That's a lot of time to expand a crate that doesn't have any macros in it!
cc you may be interested in this!
A looks like almost all the time is spent in In which case, cc
Apparently most time is spent
called ~38k times
Since we need to build the module graph and resolve imports during expansion for macros 2.0, we must construct node ids and def ids throughout expansion (i.e. interleaved arbitrarily many times until we hit fix-point). Ideally we'd keep running totals of the time spent assigning node ids, assigning def ids, etc. for more accurate profiling information within the expansion step.
in theory though isn't the fixed point for this crate the crate itself? (e.g. there's no macros here). Or are the def ids persisted for the rest of compilation, so "blaming" expansion isn't quite correct here?
Yeah, the def ids are persisted for the rest of compilation. We could move the "first round" of def id collection (in which we collect the raw, unexpanded source) outside of expansion, but that would introduce more code complexity and wouldn't count the time we spend collecting def ids for AST that comes from macro expansions.
Ah ok, nah it seems fine! I think there's a number of cases where is attributing time in the wrong place nowadays... Still it seems odd that 30-50k invocations of this function would take so long to execute?
Do I understand this correctly that all DefIds generated are actually used, right? There are no "temporary" DefIds? Each of these invocations creates a Blake2 hasher. I'd be interested how the performance looks with other hashing algorithms. I'd like to switch to something faster anyway:
Are you sure this isn't the other quadratic case fixed in ?
It may very well be! Feel free to close this w/ that PR landing, I'll verify to be sure but I'd imagine you're correct in that it's fixed by
er, didn't mean to close just yet


Question: node_to_hir_id: self.node_to_hir_id.clone(), macro_def_scopes: self.macro_def_scopes.clone(), expansions: self.expansions.clone(), <del> keys_created: self.keys_created.clone(), </del> <ins> next_disambiguator: self.next_disambiguator.clone(), </ins> } } }

A of Servo's crate shows a huge amount of time (46 seconds!) in name resolution. It turns out that is calling , specifically . That's a lot of unused imports! Sure enough if we create a synthetic file locally with this script: we find: That's a lot of time spent processing unused imports! The slowdown here isn't quite the same as the style crate, unfortunately. The style crate only has ~7k unused imports, which apparently takes it 48s in that profile. In any case the intent here is clear, lots of unused imports seem to slow down compilation, and the crate looks to have a lot of unused imports!
cc
We could address this quickly by just emitting the first 10 unused imports warnings and then warning that there are more unused imports not shown.
I can never deal with more than 10 lints at a time anyway myself, so seems like a reasonable solution to me!
Dumping out a ton of warnings is useful when you're hooked into an IDE and you can see them as e.g. green squiggles under the offending text as opposed to 10k lines on a terminal.
I think the reason is slow is because it calls , which does this: I don't think we want to read source files multiple times like that.
Thank you for looking into Servo compile times Alex, and great find here! Could you CC me or someone from the Servo team for Servo-related issues? Thanks.
Can do!
In general I've always wanted the lint system to avoid even running in blocks. Currently the lint system runs all lints in parallel on the tree. This is great since it means we only traverse it once, and the cost of the traversal is consolidated. We don't need to reduce that cost itself (which is nice because then we don't have to worry about inside ). Most lints do not maintain state. The lint framework has the capability to do so, and we use this a couple times in Clippy, but most lints are , so they won't notice if or whatever isn't called in a region of . The "allowness" of a lint is tied to where in the tree the lint traversal is, not the span emitted by the lint.


Question: node_to_hir_id: self.node_to_hir_id.clone(), macro_def_scopes: self.macro_def_scopes.clone(), expansions: self.expansions.clone(), <del> keys_created: self.keys_created.clone(), </del> <ins> next_disambiguator: self.next_disambiguator.clone(), </ins> } } }

It's perfectly possible to a block of code and have the lint still be emit there because a different block of code (where it is ) hit the lint but emitted a span it got from elsewhere. We've had trouble with this before in clipyp iirc. All of this enables this proposal: If we had a specialized trait for this, then when we have an we can turn off calling lint methods entirely, and when there's a turn it on again. It doesn't even have to be a trait, really, it could just be a defaulted fake-static method (until happens) on LateLintPass. I suspect this will get significant speedups for crates like Style. I may_ be able to take a crack at this if y'all think this is a good approach.
It occurs to me that a boolean check per lint each tree node might actually end up being more expensive? I'll have look at this code closer. Might be possible to make this fast by having a second array of trait objects which only contains the active lint passes.
It seems like we do a large enough amount of work that the whole "vector of active lints" stuff won't really be necessary. However, I just realized that this bug is not during the lint pass but during the resolution phase (which defers linting to the actual lint pass). This won't be able to help, though we can fix it by doing the spantosnippet in the actual lint and then making this optimization. So in that case I suspect this optimization is unnecessary. In general we've rarely had performance issues with lints in clippy (which has way more lints than rustc), and we've been pretty careful to measure impact there. Still, if folks think this optimization can help, let me know.


Question: } if self.index < self.len { self.len -= 1; <ins> self.a_len -= 1; </ins> let i = self.len; // SAFETY: `i` is smaller than the previous value of `self.len`, // which is also smaller than or equal to `self.a.len()` and `self.b.len()`

Here is called for potential side effects until , ignoring however that it could have already been called in with those indexes. that demonstrates how this can be exploited to get two mutable references to the same data and cause an use-after-free bug.
Assigning as part of the .
The gift that keeps on giving Maybe it is time to get rid of as it exists today and replace it with a ? One that imposes the additional requirement on the caller that it must bring the iterator back into a safe state after it is done iterating. The upside would be eliminating a lot of code in and enabling the same optimization for and similar sources. While the downside would be that external iteration (i.e. loops and manual calls to ) would cease to benefit from optimizations and only internal iteration methods (including ) would continue to do so.
I don't know, I feel like that would just make more complex to upheld the invariants. IMO a good improvement over the current would be separating forward and backward iteration, this way it becomes easier to keep track of the state and I think would also make it possible to implement them for
I don't see how separating the forward and backward state would help with a drop implementation. The issue is that the source () currently does not have access to that state, instead the consumer drives the iteration by direct access through and never informs the source about it.
It would help because it allows the source iterator to keep track of its state by updating it when the method is called. Anyway, looks like someone already and it resulted in worse optimizations, but maybe LLVM got better in the meantime, or maybe that implementation could have been better. Anyway I don't think this is the right place to discuss this, a topic on zulip would probably be better.
https://rust-


Question: <ins> error: this file contains an un-closed delimiter --> $DIR/issue-63135.rs:3:16 | LL | fn i(n{...,f # |     - -        ^ |     | | |     | un-closed delimiter |     un-closed delimiter error: expected field pattern, found `...` --> $DIR/issue-63135.rs:3:8 | LL | fn i(n{...,f # |        ^^^ help: to omit remaining fields, use one fewer `.`: `..` error: expected `}`, found `,` --> $DIR/issue-63135.rs:3:11 | LL | fn i(n{...,f # |        ---^ |        |  | |        |  expected `}` |        `..` must be at the end and cannot have a trailing comma error: expected `[`, found `}` --> $DIR/issue-63135.rs:3:15 | LL | fn i(n{...,f # |               ^ expected `[` error: expected `:`, found `)` --> $DIR/issue-63135.rs:3:15 | LL | fn i(n{...,f # |               ^ expected `:` error: expected one of `->`, `where`, or `{`, found `<eof>` --> $DIR/issue-63135.rs:3:15 | LL | fn i(n{...,f # |               ^ expected one of `->`, `where`, or `{` here error: aborting due to 6 previous errors </ins>

I'm seeing an internal compiler error on the following input (found by ): The error happens on stable, beta, and nightly.
The only early return I see that doesn't emit is here:
Applying the most obvious patch, I get the following non-ICE output: The "expected , found " bit doesn't seem quite right. :slightlysmilingface:
is an unfortunate side effect of the unmatched delimiter recovery logic not accounting for s. Submit a PR with this patch to fix this ICE as fixing the slightly misleading message will require a much larger (unrelated) change.
I'll toss one up after I finish running the test suite. One thing: I'm not sure how to annotate the test. It looks like there's four errors that all point to EOF, but whatever I try to write, only one of them gets recognized as referring to that line.
this is what I did


Question: <ins> PRINT-BANG INPUT (DISPLAY): ; PRINT-BANG INPUT (DEBUG): TokenStream [ Group { delimiter: None, stream: TokenStream [ Punct { ch: ';', spacing: Alone, span: $DIR/issue-80760-empty-stmt.rs:25:17: 25:18 (#0), }, ], span: $DIR/issue-80760-empty-stmt.rs:13:21: 13:23 (#4), }, ] </ins>

This the the of a proc macro crate : And here is the of another crate: When building, this outputs: 49.0, 1.50.0-beta.5 rustc 1.51.0-nightly ( 2021-01-05) binary: rustc commit-hash: commit-date: 2021-01-05 host: x86_64-unknown-linux-gnu release: 1.51.0-nightly
cc
cc
Assigning as discussed as part of the and removing .
assigning to self to confirm if is the cause of the breakage, and if so, revert the PR until it can be revised to handle this case.
This is caused by us not handling properly - I'm working on a fix.
Opened


Question: <ins> #![crate_type="lib"] #[repr(i8)] pub enum Type { Type1 = 0, Type2 = 1 } // CHECK: define signext i8 @test() #[no_mangle] pub extern "C" fn test() -> Type { Type::Type1 } </ins>

<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --<!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
modify labels: +regression-from-stable-to-stable This happens since rust
More minimal reproducer. Does not occur with just 1 variant. Or if one of the variants has a negative discriminant. Affects most targets if not all of them, despite the failure seemingly occurring inside the target-specific code.
Assigning P-medium as .20enum.20from.20an.20extern.20c.E2.80.A6) and removing I-prioritize.


Question: rc::Rc, }; <ins> require std::time::Duration; //~^ ERROR expected item, found `require` include std::time::Instant; //~^ ERROR expected item, found `include` </ins> pub using std::io; //~^ ERROR expected item, found `using` fn main() { let x = Rc::new(1); let _ = write!(io::stdout(), "{:?}", x); <ins> let _ = Duration::new(5, 0); let _ = Instant::now(); </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: <ins> error[E0594]: cannot assign to `self.foo`, which is behind a `&` reference --> $DIR/issue-93093.rs:8:9 | LL |     async fn bar(&self) { |                  ----- help: consider changing this to be a mutable reference: `&mut self` LL | LL |         self.foo += 1; |         ^^^^^^^^^^^^^ `self` is a `&` reference, so the data it refers to cannot be written error: aborting due to previous error For more information about this error, try `rustc --explain E0594`. </ins>

Given the following code: The current output is: <!-- The following is not always necessary. --Ideally the output should look like: <!-- If the problem is not self-explanatory, please provide a rationale for the change. --is not a valid argument; it needs to be either or . For some reason this problem only happens when the function is async.
This is the same diagnostic you get when mutably dereferencing let-bindings that are : So it seems like this has to do with the fact that ast_lowering emits a binding when desugaring. I wonder if we can get the name of the variable when emitting this diagnostic, and special-case when it .
Another (possibly related?) bug: doesn't have the suggestion if it's in an async block:
Same with closures. I would probably classify that as a separate bug, since the original bug has to do specifically with desugaring, and the latter has to do with closure/generator captures.
Thanks for the report and getting a PR up so quickly! label +AsyncAwait-Triaged +AsyncAwait-Polish
Another similar error, not related to async this time: isn't valid Rust.


Question: t!(read_byte(file)); // compensate for padding } <del> let numbers_map: HashMap<String, u16> = t! { (0..numbers_count).filter_map(|i| match read_le_u16(file) { Ok(0xFFFF) => None, Ok(n) => Some(Ok((nnames[i].to_string(), n))), Err(e) => Some(Err(e)) </del> <ins> let numbers_map: HashMap<String, u32> = t! { (0..numbers_count).filter_map(|i| { let number = if extended { read_le_u32(file) } else { read_le_u16(file).map(Into::into) }; match number { Ok(0xFFFF) => None, Ok(n) => Some(Ok((nnames[i].to_string(), n))), Err(e) => Some(Err(e)) } </ins> }).collect() };

does not emit color output when running under a tmux session with set correctly to (supported by the latest versions of ncurses) even with when is set to . On the machine in question (macOS) the term file for is installed and returns the following: Per cargo should be invoking rustc with the flag, and indeed, returns 'Option color given more than once. Executing also does not produce color output, but does.
I have a similar bug on Archlinux. I used to get colored output on this system, but that recently stopped working for rustc. (Cargo is still fine for me.) If I add in and run in , I get Result::unwrap()Err/lib/terminfo/x/xterm-256colorncursesNEWS file does mention a new (incompatible) file format with a different magic number: Could rustc switch to whatever Cargo uses for colored terminal output?
A work-around for my machine was temporarily downgrading the packages, and copying the old file to .
Yes rustc should be able to switch at any time
Thanks for the workaround!
Changing from to also seems to work as a temporary workaround. (note: this may affect other terminal applications)
Another work-around if you're using sh: This sets to a possibly incorrect value, but limits its impact to only the output of a command.
That worked for me as well. I had no colour with . I downgraded to , which was what I had in , and now I have colour again.
I have a similar issue: In my regular terminal emulator (not tmux), there are no colors from rustc (as executed with ), colors from cargo itself are working fine. The default setting for there is: . The problem is fixed by setting to . Inside tmux however, colors work just fine, there seems to be by default.
Colors are fixed in the latest nightly (thanks to o/)
This is fixed for me in today’s nigthly, presumably by
With the current nightly I still have no colors with and have to use as a work around. What might still be broken?
Terminal colors are still broken with . however, does use colors, so there's clearly still a discrepancy between how and use termcolor
It works fine for me with ncurses 6.1, even rustup has colors again since the last version .


Question: t!(read_byte(file)); // compensate for padding } <del> let numbers_map: HashMap<String, u16> = t! { (0..numbers_count).filter_map(|i| match read_le_u16(file) { Ok(0xFFFF) => None, Ok(n) => Some(Ok((nnames[i].to_string(), n))), Err(e) => Some(Err(e)) </del> <ins> let numbers_map: HashMap<String, u32> = t! { (0..numbers_count).filter_map(|i| { let number = if extended { read_le_u32(file) } else { read_le_u16(file).map(Into::into) }; match number { Ok(0xFFFF) => None, Ok(n) => Some(Ok((nnames[i].to_string(), n))), Err(e) => Some(Err(e)) } </ins> }).collect() };

I’d like to note though that things like destroy this for some reason (even if is set). It took me some time to figure that out
I'm using ncurses 6.1 on Fedora 28 and everything appears to be working fine except for test colors. In mentioned that a bit tricky due to how the build works, but we can always tackle that later. What is the barrier to migrating libtest from to ? For now, it's leaving my test output looking like this. !
I have an in-progress patch for libtest but I ran into I'm guessing that's the build issue that is referring to. I don't know how linking libtest works, but I'm happy to try to fix the build if someone can point me in the right direction.