jiebi/CodeConvo huggingface dataset:
Change:
<ins> // edition:2018 #![allow(dead_code)] use std::future::Future; use std::pin::Pin; type BoxFuture<'a, T> = Pin<Box<dyn Future<Output = T> + Send + 'a>>; //   ^^^^^^^^^ This would come from the `futures` crate in real code. fn foo<F: Future<Output=i32> + Send + 'static>(x: F) -> BoxFuture<'static, i32> { // We could instead use an `async` block, but this way we have no std spans. x //~ ERROR mismatched types } // FIXME: uncomment these once this commit is in Beta and we can rely on `rustc_on_unimplemented` //        having filtering for `Self` being a trait. // // fn bar<F: Future<Output=i32> + Send + 'static>(x: F) -> BoxFuture<'static, i32> { //     Box::new(x) // } // // fn baz<F: Future<Output=i32> + Send + 'static>(x: F) -> BoxFuture<'static, i32> { //     Pin::new(x) // } // // fn qux<F: Future<Output=i32> + Send + 'static>(x: F) -> BoxFuture<'static, i32> { //     Pin::new(Box::new(x)) // } fn main() {} </ins>

Discussion:
gives The in particular is confusing. This can be a pretty intimidating error message for someone new to async/await, when all they forgot was . I'm not sure if we can fix this without stabilizing so we can sprinkle some magic compiler dust on its error messages. Maybe there's something we can do, though. Maybe some intelligent use of type aliases in our error messages? cc
This can be handled without needing to stabilize the struct. It should act the same way that the primitive type cast suggestions do.
Some observations: There is no struct, it's a type-alias We could suggest invoking but that is a method defined only in the futures crate, which feels a bit awkward to me; I'd rather it were part of libstd We can* suggest as well ()
marking as OnDeck, since BoxFuture gets used quite often
I have a PR that suggests the right code for this: <img width="1269" alt="Screen Shot 2020-02-11 at 5 09 37 PM" src="https://user-"But if first you try : <img width="1271" alt="Screen Shot 2020-02-11 at 5 10 12 PM" src="https://user-"or : <img width="1303" alt="Screen Shot 2020-02-11 at 5 11 11 PM" src="https://user-"we will send you in a wild goose chase: <img width="946" alt="Screen Shot 2020-02-11 at 5 10 53 PM" src="https://user-"
Filed for the uncovered cases.
Change:
<ins> error[E0477]: the type `&'lt u8` does not fulfill the required lifetime --> $DIR/normalization-placeholder-leak.rs:31:40 | LL |     fn test_lifetime<'lt, T: Trait>(_: Foo<&'lt u8>) {} |                                        ^^^^^^^^^^^^ error[E0477]: the type `<T as AnotherTrait>::Ty2<'lt>` does not fulfill the required lifetime --> $DIR/normalization-placeholder-leak.rs:36:44 | LL |     fn test_alias<'lt, T: AnotherTrait>(_: Foo<T::Ty2::<'lt>>) {} |                                            ^^^^^^^^^^^^^^^^^^ error: aborting due to 2 previous errors For more information about this error, try `rustc --explain E0477`. </ins>

Discussion:
In that commit, go to folder and run (tested in nightly, stable 1.69 and stable 1.70) : <details<summary<strongBacktrace</strong</summary<p</p</details
This is causing us to leak placeholders into implied bounds. Minimized:
Change:
<ins> // Copyright 2012 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. // Test that Vec::new() can be used for constants #![feature(const_vec_new)] const MY_VEC: Vec<usize> = Vec::new(); pub fn main() {} </ins>

Discussion:
It should either elaborate on AssertUnwindSafe or else drop the claim that it will elaborate below.
Change:
<ins> error: values of the type `[u8; SIZE]` are too big for the current architecture error: aborting due to previous error </ins>

Discussion:
<!-- 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. --: with cc <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
This would previously just throw an error but not "crash": `
I'll look into it. Thanks for the bug report!
Change:
} } <ins> // Do not trigger on functions that may diverge instead of self-recursing (#54444) pub fn loops(x: bool) { if x { loops(x); } else { loop {} } } pub fn panics(x: bool) { if x { panics(!x); } else { panic!("panics"); } } </ins> fn main() {}

Discussion:
noticed these cases: thinks the way to resolve this is to reimplement the lint on top of the analysis stuff.
Isn't the first one kind of correct, if misleading? The second one is indeed problematic.
Technically correct, because it can't return at all ;)
It's wrong because the function can diverge without recursively calling itself. They're both literally the same example, I just replaced one form of divergence with another.
mmmm.... In my mind I read this as while the latter, being it is also , but can terminate (while the has no side-effects). You're correct, but I'd love it if we could somehow differentiate when evaluating divergence between "can't return" and "can't return but can panic".
Both "stuck in an infinite loop" and "panics" are different from "infinitely self-recurses". What we want to detect is unguarded self-recursion, that is, when you forgot to check some condition that would give you a convergent or divergent "base case", that would stop the infinite recursion. The message of the lint doesn't help my point, it should be more clearly about "infinite recursion". While usually you're missing a condition, or you're calling the wrong function, it's also possible that you're using infinite recursion to infinitely repeat something - but we don't have guaranteed tail calls, so what you really want to do is rewrite the infinite recursion into an infinite loop.
Triage: no change
Since we currently lint this: Wouldn't this need a backwards dataflow analysis to catch this case? It doesn't looks like the bit would ever be propagated to a return block like this. A backwards analysis would instead propagate it to the entry block, if I understand correctly.
You're right, there's no merge for either the or the examples, that could collect the information. Presumably we want to tell these apart: vs So I guess the property you'd propagate backwards is "always reaches self-call", which means every block starts at (except those that contain a self-call) and the merge operator is . The funny thing about this being a 1-bit-per-block analysis is that instead of a you can use a simple and fixpoint is also easier to achieve. Rough sketch:
Change:
/// Whether the layout is from a type that implements [`std::marker::PointerLike`]. /// /// Currently, that means that the type is pointer-sized, pointer-aligned, <del> /// and has a scalar ABI. </del> <ins> /// and has a initialized (non-union), scalar ABI. </ins> pub fn is_pointer_like(self, data_layout: &TargetDataLayout) -> bool { self.size() == data_layout.pointer_size && self.align().abi == data_layout.pointer_align.abi <del> && matches!(self.abi(), Abi::Scalar(..)) </del> <ins> && matches!(self.abi(), Abi::Scalar(Scalar::Initialized { .. })) </ins> } }

Discussion:
<!-- 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. -- In particular, this also happens with . <!-- 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 label F-dyn_star requires-nightly
Regression in nightly-2022-10-16 found 7 bors merge commits in the specified range commit[0] 2022-10-14: Auto merge of - woppopo:const_location, r=scottmcm commit[1] 2022-10-14: Auto merge of - matthiaskrgr:rollup-xxsx6sk, r=matthiaskrgr commit[2] 2022-10-15: Auto merge of - joshtriplett:is-terminal-fd-handle, r=thomcc commit[3] 2022-10-15: Auto merge of - Aaron1011:stability-use-tree, r=cjgillot commit[4] 2022-10-15: Auto merge of - compiler-errors:dyn-star-plus, r=eholk commit[5] 2022-10-15: Auto merge of - Dylan-DPC:rollup-97cvwdv, r=Dylan-DPC commit[6] 2022-10-15: Auto merge of - Nilstrieb:query-cleanups, r=cjgillot ERROR: no CI builds available between and within last 167 days maybe ?
Change:
("trace_macros", Active), ("simd", Active), ("default_type_params", Active), <del> ("quote_tokens", Active), ("quote_expr", Active), ("quote_ty", Active), ("quote_item", Active), ("quote_pat", Active), ("quote_stmt", Active), </del> <ins> ("quote", Active), </ins> // These are used to test this portion of the compiler, they don't actually // mean anything

Discussion:
These all are only useful in the compiler, aren't hygienic, etc. Nominating.
What hygiene issues do they still have? The hygiene issue I'm aware of was fixed by . They'll be very useful for externally defined syntax extensions. I'm okay with feature gating it though.
The only thing I recall is that they require an to be in scope. Perhaps that's not technically a hygiene problem.
Accepted for 1.0, P-backcompat-lang.
I would like to look at this, but I am not familiar to quasi-quoting. Can you list some quasi-quoting macros, or point out the directory of the source tree to look up? What I have found related to quasi-quoting lies on .
All of the quasi-quoting macros live there.
Their .
Change:
fn into_iter(self) -> IntoIter<T, A> { unsafe { let mut me = ManuallyDrop::new(self); <del> let alloc = ptr::read(me.allocator()); </del> <ins> let alloc = ManuallyDrop::new(ptr::read(me.allocator())); </ins> let begin = me.as_mut_ptr(); let end = if mem::size_of::<T>() == 0 { arith_offset(begin as *const i8, me.len() as isize) as *const T

Discussion:
<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. --I'm trying out the allocator api with the goal of being able to track memory usage for parts of a program: I expected this to work (and print 0 at the end), but instead it fails by freeing an invalid pointer: Running with miri gives a bit more context:
This seems to be a problem with the implementation of because if I do: There is no crash and no Miri error, this to me indicate that there is a problem in the implementation of . Another interesting things is the message I have locally , I don't know what it means but it's certainly interesting. label +T-libs +I-unsound
The drop guard used in the implementation of IntoIter makes a raw copy of an allocator when reconstructing RawVec. The allocator is then dropped twice, once by RawVec drop and second time by IntoIter drop. cc .
Minimal reproduction of problem: Prints:
Change:
<ins> // Copyright 2014 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. enum E1 { V1(E2<E1>), } enum E2<T> { V2(E2<E1>), } //~ ERROR illegal recursive enum type; wrap the inner value in a box to make it representable fn main() { } </ins>

Discussion:
The following program causes a stack overflow: There is a check that enums do not recurse in this way, but no such check for structs. (Note, though, that there is a check that structrs are instantiable, which is slightly different)
Huh, so that's why std::list has pointer indirections in it.
This is still an issue, nominating for production ready
accepted for production-ready milestone
So uh, this... doesn't exactly reproduce. It compiles and runs fine, no overflow or anything afaict. It should be rejected by the compiler, I think.
you have to reference the type, just like , which I triaged today. Actually I think they are the same bug.
This applies to non-infinite-sized types that contain themselves unboxed like the following too:
Accepted for 1.0, P-high.

Here is a test case: I think the right approach is to replace with something like . then we have to keeep a stack of def-ids and when we enter a new nominal type check that we do not already have it on the stack. i started this then realized it was a big distraction from what I'm trying to do, so filing a bug instead. Marking as A-typesystem as this check is performed in
Just to make this concrete: both of the cases that Niko describes yield ICE's. The first (the and items) yields an ICE with no useful error information. The second ( and ) yields an error describing the illegal recursive enum type (followed by an ICE :).
I don't believe this is backwards incompatible, renominating.
accepted for production-ready milestone
appears to be properly classified
Accepting for P-high.
Tagging as mentorship bug, with as mentor
This code triggers the same infinite recursion in typestructurallycontains:
I have a fix for this written, in case anyone is wondering whether to start working on it. I'll submit a pull request soon.
Change:
// injected intrinsics by the compiler. #![deny(missing_docs)] #![allow(dead_code)] <del> #![feature(associated_type_defaults)] </del> <ins> #![feature(associated_type_defaults, extern_types)] </ins> //! Some garbage docs for the crate here #![doc="More garbage"]

Discussion:
It seems like this lint should fire if you have an declaration without docs on it. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
modify labels: A-lint T-compiler C-bug
I think I know what causes this and will write a more general fix here this week. claim
the fix wasn't more general but it's a fix none the less
Change:
source = "registry+https://github.com/rust-lang/crates.io-index" checksum = "8c21d40587b92fa6a6c6e3c1bdbf87d75511db5672f9c93175574b3a00df1758" dependencies = [ <ins> "ahash", </ins> "compiler_builtins", "rustc-std-workspace-alloc", "rustc-std-workspace-core",

Discussion:
When compiling for , the resulting binaries should have the OS/ABI () field in the ELF header set to Standalone () as per the LLVM target, which it did before . Now, it is set to "UNIX - System V", which I only tested on Linux. identified the introduction of synthetic object files for exported symbols from to have changed this: I did not have a deep dive into the code yet, but I assume the synthetic object file has the host's OS/ABI, which is prevalent over the other OS/ABI. do you have any insight? Related:
Hmm, the crate sets to , which seems to be an alias of . Unfortunately currently crate provide no ways to set this field, so to fix this I suppose some postprocessing of the generated ELF file would be needed. I am surprised that this doesn't show up earlier, given that exactly the same routine is used to create rmeta files. Does hermit not support dylibs?
Ah, yes, sets the OS/ABI here: . I think there are three possibilities: proper support for setting OS/ABI in . This would probably take a lot of effort. before passing it to in This can be done quite easily. the synthetic object file after (?) the real ones. I think lld infers the OS/ABI from the first proper input object file, if I am reading this correctly:  For 1 and 2 we would need to know the proper OS/ABI from the real object files though. I am not sure how easy that would be to come by. What do you think? Hermit is a unikernel, which is linked statically to the application. There is no support for dynamic libraries. A similar problem occurs when using though (). This issue was closed, because we did not need anyways.
Here's how LLVM determines what OSABI to use: We could look at and use the same logic to determine the OSABI. The synthetic object can be placed after real object files (it only needs to be linked before any libraries), but assuming the linker only looks at the first object file sounds a bit hacky. cc what's your take on this issue?
object-rs has only recently been taught to set expected by some MIPS targets (). In think we can teach object-rs to set too, and then just set it, if some linker expects it.
All right.

Thanks for the quick feedback. I'll cook something up in the coming days.
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-low
I opened , but first the necessary changes in have to be released.
Change:
<ins> # `start` The tracking issue for this feature is: [#29633] [#29633]: https://github.com/rust-lang/rust/issues/29633 ------------------------ Allows you to mark a function as the entry point of the executable, which is necessary in `#![no_std]` environments. The function marked `#[start]` is passed the command line parameters in the same format as the C main function (aside from the integer types being used). It has to be non-generic and have the following signature: ```rust,ignore (only-for-syntax-highlight) # let _: fn(isize, *const *const u8) -> isize # ; ``` This feature should not be confused with the `start` *lang item* which is defined by the `std` crate and is written `#[lang = "start"]`. ## Usage together with the `std` crate `#[start]` can be used in combination with the `std` crate, in which case the normal `main` function (which would get called from the `std` crate) won't be used as an entry point. The initialization code in `std` will be skipped this way. Example: ```rust #![feature(start)] #[start] fn start(_argc: isize, _argv: *const *const u8) -> isize { 0 } ``` Unwinding the stack past the `#[start]` function is currently considered Undefined Behavior (for any unwinding implementation): ```rust,ignore (UB) #![feature(start)] #[start] fn start(_argc: isize, _argv: *const *const u8) -> isize { std::panic::catch_unwind(|| { panic!(); // panic safely gets caught or safely aborts execution }); panic!(); // UB! 0 } ``` </ins>

Discussion:
or The examples don't compile and the list of items is outdated. Should the list at the bottom of the page still be updated? The amount of language items has grown and there's already a list . <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim label: +A-lang-item
I think linking to the source code is better than trying to keep the list up to date, yes. We might still want to document the language items that are required for a binary, since those are "user facing" in a way the others aren't.
Ideally we could find a way to run rustdoc on the examples (as doctests) so they don't get outdated.
The guidance could be to the nomicon because there's already .
Change:
use clone::Clone; use cmp; <del> use cmp::Ord; </del> <ins> use cmp::{Ord, PartialOrd, PartialEq}; </ins> use default::Default; use marker; use mem;

Discussion:
I tried printing all valid s by doing and was surprised to find it only printed up to 254. I'm unsure if this is supposed to be this way ( can be used). If so, I'd propose adding this to the Iterators/Ranges section of the book.
The problem is the next method of RangeFrom: It returns the previous value, then updates itself to store the next one. The value 255 ends up being the value that represents a "done" state, so it can't return it. I can't think of any solution that doesn't involve adding a flag to RangeFrom.
Or impl IntoIter instead of Iterator (and use a helper struct to keep track of the range).
Seems similar to .
Question: What is the origin of this Rust behavior, or what is its justification? e.g.: Why an exclusive upper bound on ranges? This caught me by total surprise, coming from Haskell, and I don't know if any Rust I've written for my own cases is wrong now. It behaves differently from similar syntax in Haskell, Swift, and Go, so I'm wondering if it's fruitful to have behavior different from peer languages (in trying to attract people away from languages where syntax like this does not exist.)
Ruby has both exclusive and inclusive ranges
The origin is related to the for-loop idiom in C. corresponds to the range. It has some nice properties such as how it iterates over exactly elements, whereas an inclusive range does and would require you to say, for example, for the indices of a vector if were inclusive. Essentially, it seems like the exclusive behaviour is useful more often than inclusive in a systems language.
Exclusive behaviour is also a leaner implementation. For inclusive behaviour you need some kind of flag for "now yield the inclusive element". This issue is an exact example of why: How do you statefully write an iterator from to , inclusive?
cc , which adjusts this behavior by triggering an overflow on non-wrapped-arithmetic types; it makes the semantics equivalent to repeatedly updating .
so just to be clear, with the above PR merged, now panics. Is this the intended behavior?
Change:
LL |     let _: for<'a> fn(<() as Foo<T>>::Type<'a>, &'a T) = |_, _| (); |                                                          ^^^^^^^^^ <del> error: aborting due to 8 previous errors </del> <ins> error: aborting due to 9 previous errors For more information about this error, try `rustc --explain E0310`. </ins>

Discussion:
This code compiles after although it shouldn't: () This is similar to in that we're not taking into account placeholder regions when "promoting" type-tests from the closure to its caller: label T-types regression-from-stable-to-beta C-bug A-NLL I-unsound <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I guess it would be an easy fix claim
The unsoundness exploitation in can easily be adapted for this issue, so it is in fact a soundness issue:
issue touched in today's T-compiler meeting, . Will also be discussed tomorrow during the T-types meeting.
WG-prioritization assigning priority (). label -I-prioritize +P-critical