jiebi/CodeConvo huggingface dataset:
Code change:
candidates.vec.push(FnPointerCandidate); } } <ins> // Provide an impl for suitable functions, rejecting `#[target_feature]` functions (RFC 2396). ty::FnDef(def_id, _) => { if let ty::FnSig { unsafety: hir::Unsafety::Normal, abi: Abi::Rust, c_variadic: false, .. } = self_ty.fn_sig(self.tcx()).skip_binder() { if self.tcx().codegen_fn_attrs(def_id).target_features.is_empty() { candidates.vec.push(FnPointerCandidate); } } } </ins> _ => {} }

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

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

Related discussion:
text: (This would be like a clause.) To that end, I was thinking that you could model this last point using closures, but I found that it doesn't work. In particular, gives an error, even if it appears inside of a function annotated with . This seems like something we should discuss, but it's a separate issue. We did discuss briefly whether target features should be part of the type of function pointers but I think the conclusion was 'well maybe but there is already stable code out there that lets you coerce, and it seems rather niche'. We also discussed whether we should permit one to annotate closures with target-feature annotations. In any case, those are things we can address separately from this issue, but the point is that adopting more accepting solutions can be done in the future.
I'm going to move the question of whether closures should "inherit" target features to the main tracking issue -- I'm not sure if that is something that was discussed as part of the original RFC discussion?
Opened to discuss closures.
Code change:
// highlighted text will always be `&<expr>` and // thus can transform to `&mut` by slicing off // first ASCII character and prepending "&mut ". <del> let borrowed_expr = src[1..].to_string(); return (assignment_rhs_span, format!("&mut {}", borrowed_expr)); </del> <ins> if src.starts_with('&') { let borrowed_expr = src[1..].to_string(); return (assignment_rhs_span, format!("&mut {}", borrowed_expr)); } </ins> } }

Related discussion:
text: When I build this code on nightly... ...I get these errors: The first error is fine, but the second one is missing the first character of . It looks like rustc assumes the first character is an and removes it without checking. :
Currently working on a fix here: Still need to add UI tests, which I'll do once I figure out how they work.
Adding to the Rust 2018 Edition Preview milestone. Has a pending PR, too.
Code change:
<ins> // Copyright 2017 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. fn iterate<T, F>(initial: T, f: F) -> Iterate<T, F> { Iterate { state: initial, f: f, } } pub struct Iterate<T, F> { state: T, f: F } impl<T: Clone, F> Iterator for Iterate<T, F> where F: Fn(&T) -> T { type Item = T; #[inline] fn next(&mut self) -> Option<Self::Item> { self.state = (self.f)(&self.state); Some(self.state.clone()) } #[inline] fn size_hint(&self) -> (usize, Option<usize>) { (std::usize::MAX, None) } } fn main() { let a = iterate(0, |x| x+1); println!("{:?}", a.iter().take(10).collect::<Vec<usize>>()); //~^ ERROR no method named `iter` found for type `Iterate<{integer} } </ins>

Related discussion:
text: I was playing around with some code which can be found and is attached below. When I click on output I get the following output: I don't have a rust installation locally right now, so I cannot create the backtrace. I'll add it later today. The code which triggers this:
Stack trace: (There is no ICE with (nothing generated either due to type error). Perhaps playpen should use instead.)
You can get backtrace on playpen here: !
Looks like this has been fixed recently
Code change:
<ins> // Copyright 2017 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. fn iterate<T, F>(initial: T, f: F) -> Iterate<T, F> { Iterate { state: initial, f: f, } } pub struct Iterate<T, F> { state: T, f: F } impl<T: Clone, F> Iterator for Iterate<T, F> where F: Fn(&T) -> T { type Item = T; #[inline] fn next(&mut self) -> Option<Self::Item> { self.state = (self.f)(&self.state); Some(self.state.clone()) } #[inline] fn size_hint(&self) -> (usize, Option<usize>) { (std::usize::MAX, None) } } fn main() { let a = iterate(0, |x| x+1); println!("{:?}", a.iter().take(10).collect::<Vec<usize>>()); //~^ ERROR no method named `iter` found for type `Iterate<{integer} } </ins>

Related discussion:
text: I was in the middle of making a big changes to some code when this panic occurred. I was expecting a lot of compiler errors but got a compiler panic instead! :fearful: I ran the build with and the panic still occurred. Run to get this. Here's the full output with : Since I was in the middle of editing, there's no commit to point to, so I just attached my source code as is so you have something to debug. When you download it and run , the compiler should panic. The repo is called . I don't know how to narrow this issue down, or else I would try to find a smaller example for you. Hope this is good enough.
Some context for the change that caused this: Before this error happened, I changed the file . I split into two structs, and . I was relying on the compiler to find all the places where that change would effect things, and it seems that something went wrong in the compiler while trying to do that.
Once I fix that, everything works again. No more compiler panic. So it seems to have something to do with when I split up that struct. All the messed up pattern matches caused a panic. (Actually just fixing 2 broken pattern matches fixed the problem.)
I've just encountered this myself. I managed to reduce it down: It looks like this happens when a closure's body is a single (non-block) expression, and a tuple struct pattern is used somewhere in the expression. A simple workaround (if anyone needs one for some reason), then, is to just make the closure body a block:
Code change:
<ins> // Copyright 2017 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. fn iterate<T, F>(initial: T, f: F) -> Iterate<T, F> { Iterate { state: initial, f: f, } } pub struct Iterate<T, F> { state: T, f: F } impl<T: Clone, F> Iterator for Iterate<T, F> where F: Fn(&T) -> T { type Item = T; #[inline] fn next(&mut self) -> Option<Self::Item> { self.state = (self.f)(&self.state); Some(self.state.clone()) } #[inline] fn size_hint(&self) -> (usize, Option<usize>) { (std::usize::MAX, None) } } fn main() { let a = iterate(0, |x| x+1); println!("{:?}", a.iter().take(10).collect::<Vec<usize>>()); //~^ ERROR no method named `iter` found for type `Iterate<{integer} } </ins>

Related discussion:
text: Related code: Compiler panic: Note that everything is fine if I annotate the lifetimes: I am running , the MSVC x64 version.
I just ran into this. Managed to reduce the crash to Explicit lifetimes indeed fix it:
don't know if this helps, but I came up with minimal test case
Code change:
<ins> // Copyright 2017 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. fn iterate<T, F>(initial: T, f: F) -> Iterate<T, F> { Iterate { state: initial, f: f, } } pub struct Iterate<T, F> { state: T, f: F } impl<T: Clone, F> Iterator for Iterate<T, F> where F: Fn(&T) -> T { type Item = T; #[inline] fn next(&mut self) -> Option<Self::Item> { self.state = (self.f)(&self.state); Some(self.state.clone()) } #[inline] fn size_hint(&self) -> (usize, Option<usize>) { (std::usize::MAX, None) } } fn main() { let a = iterate(0, |x| x+1); println!("{:?}", a.iter().take(10).collect::<Vec<usize>>()); //~^ ERROR no method named `iter` found for type `Iterate<{integer} } </ins>

Related discussion:
text: Playground Output: Other example (possibly different bug): Output:
I just got the same ICE on linux with both the and builds. My case is essentially the same. You create an iterator of references to sub-elements of some thing which has been passed in by reference. The compiler should figure out that the iterator can only live as long as the original object, but ICEs instead. ()
Code change:
<ins> // Copyright 2017 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. fn iterate<T, F>(initial: T, f: F) -> Iterate<T, F> { Iterate { state: initial, f: f, } } pub struct Iterate<T, F> { state: T, f: F } impl<T: Clone, F> Iterator for Iterate<T, F> where F: Fn(&T) -> T { type Item = T; #[inline] fn next(&mut self) -> Option<Self::Item> { self.state = (self.f)(&self.state); Some(self.state.clone()) } #[inline] fn size_hint(&self) -> (usize, Option<usize>) { (std::usize::MAX, None) } } fn main() { let a = iterate(0, |x| x+1); println!("{:?}", a.iter().take(10).collect::<Vec<usize>>()); //~^ ERROR no method named `iter` found for type `Iterate<{integer} } </ins>

Related discussion:
text: Spawned off of There are still some cases where referencing an inaccessible item can cause the compiler to ICE. Here is one crafted example () but if 's module structure is revised then that example may fail to compile without ICE'ing for other reasons, so take care in understanding the issue: the change introduced by is skipping the requirement for stability attributes is slightly too narrow, in that it uses a local notion of pub/non-pub instead of overall accessibility. One simple solution to this may be to just follow the suggestion here and just remove the assertion entirely. (I did not want to adopt that solution for a PR to be backported to beta, but I think it is worth considering doing in nightly alone to resolve this low priority issue.)
Keywords: for better search
Code change:
<ins> error[E0308]: mismatched types --> $DIR/default-body-type-err-2.rs:8:9 | LL |         42 |         ^^- help: try using a conversion method: `.to_string()` |         | |         expected struct `String`, found integer error: aborting due to previous error For more information about this error, try `rustc --explain E0308`. </ins>

Related discussion:
text: Here's a MVCE: I expected to see this happen: compilation fails because I'm clearly returning an instead of a Instead, this happened: bad codegen ("async fn resumed after completion") :
This is specifically a bug with default body in traits, this doesn't happen in s. I'll check it out, it's probably a very simple fix.
Code change:
<ins> // check-pass // This is a valid macro. Commit 4 in #95159 broke things such that it failed // with a "missing tokens in macro arguments" error, as reported in #95267. macro_rules! f { ( /// ab ) => {}; } fn main() { f!(); } </ins>

Related discussion:
text: Cross post from Works fine on stable Rust.
That post is written by me. I've opened a PR , and made some comments there. I'm not an expert on Rust, actually I'm an amateur programmer, and this is what I can do for now.
61.0-nightly ( 2022-03-22) works so this is a very recent nightly regression.
I see that too when compiling
same issue on ubuntu20
Maybe related to this issue. Here is a snippet of macro with on the match side: Pass with rustc 1.61.0-nightly ( 2022-03-22), you can try this snippet via Failed with rustc 1.61.0-nightly ( 2022-03-23), you can try this snippet via , the code can be expanded on playground with: Expand macros in code using the nightly compiler. 61.0-nightly (2022-03-19 )
The piece of code looks surprising, but bisection lead to
Ok, I found it :smile:
Thanks for the report. Should be an easy fix, I will get to it on Monday.
I think is right to some extent. Even in previous Rust version, stuff in the matcher is not so useful and will be ignored like normal comments : With rustc 1.61.0-nightly ( 2022-03-22) or other versions before, the result is: With rustc 1.61.0-nightly ( 2022-03-23), the result is:
Note that the playground's nightly is a few days old and cannot be upgraded because of how this issue affects ring ;-)
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-critical
That's an interesting observation! But I'm not a language expert and I never intended to change behaviour in , so I will fix this problem by going back to the old behaviour.
Code change:
make_test!(split_space_str, s, s.split(" ").count()); make_test!(split_ad_str, s, s.split("ad").count()); <ins> make_test!(to_lowercase, s, s.to_lowercase()); </ins>

Related discussion:
text: 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.
Code change:
make_test!(split_space_str, s, s.split(" ").count()); make_test!(split_ad_str, s, s.split("ad").count()); <ins> make_test!(to_lowercase, s, s.to_lowercase()); </ins>

Related discussion:
text: 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.
Code change:
should_continue = suggest(err, false, span, message, sugg); } } <del> LifetimeRibKind::Item => break, </del> <ins> LifetimeRibKind::Item | LifetimeRibKind::ConstParamTy => break, </ins> _ => {} } if !should_continue {

Related discussion:
text: <!-- 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
searched nightlies: from nightly-2023-02-17 to nightly-2023-02-19 regressed nightly: nightly-2023-02-18 searched commit range: regressed commit: - -cc <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.6</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details