jiebi/CodeConvo huggingface dataset:
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. fn main() { let v = vec![1, 2, 3]; let boxed: Box<Iterator<Item=i32>> = Box::new(v.into_iter()); assert_eq!(boxed.max(), Some(3)); let v = vec![1, 2, 3]; let boxed: &mut Iterator<Item=i32> = &mut v.into_iter(); assert_eq!(boxed.max(), Some(3)); } </ins>

Discussion:
This code fails to compile: error message: A similar error occurs if is used instead of . However, if you comment out the for loop, the call to works just fine. I thought maybe it had something to do with auto-deref, so I tried dereferencing the iterator: but dumps core: I'm not sure, but this may be related to ? dumps core when I try too. version:
CC
I think the problem is worse than this; trait objects in general don’t seem to be being recognised as implementing their traits: All three fail:
I'm not sure this is a bug at all. You're pretty much asking for an automatic - I did come up with a & -based model that would kinda work for this and IIRC pointed out that object-safe traits would eventually qualify for this. We do have object safety now, so it might be doable, but I wouldn't bet on it making into 1.0. In the meanwhile, does work? If it doesn't, is it just the case of missing in a couple places?
This a particular case of . See comments over there. is leaning towards an opt-in syntax extension that handles the boiler plate code, instead of automatic s by the compiler.
ByRef for trait objects seems to hit the same llvm assertion: output:
Interesting. So if I have a value with type where is a trait, then we can't say that implements in the general case? (Assuming object safety.) So my guess is that can still call because of auto deref? Shouldn't that mean it can work with ? Maybe that is what is about... You have to explicitly deref a to use it in ? (Sorry for all the questions. I'm just confused!)
doing autoderef on the iterator in seems like something reasonable to have. looks like the compiler is mistakenly treating an unsized lvalue as an rvalue, in trans.
On Mon, Jan 12, 2015 at 01:33:08PM -0800, Andrew Gallant wrote: Actually, I believe it works with , but not with the other types.
Just thank you for this issue. It resolves all my problems perfectly!
Change:
pub use check::{check_item_type, check_wf_new}; pub use diverges::Diverges; pub use expectation::Expectation; <del> pub use fn_ctxt::FnCtxt; </del> <ins> pub use fn_ctxt::*; </ins> pub use inherited::{Inherited, InheritedBuilder}; use crate::astconv::AstConv;

Discussion:
Branching this from . Originally, for was over 6,000 lines. I was able to push that to around 1,100 lines (PR ). However, in the process, I found that was rather long, with 13 fields in the struct and some rather long s attached. The sum total is 3,200 lines, which effectively means that the comment was moved from to . The goal of this issue is to smaller, at minimum less than 3,000 lines by some of its functionality into "sub-structs" that will be in separate files Unknowns to solve: [ ] How do the 13 fields group into nice sub-structs [ ] What to name the above mentioned sub-structs [X] How to achieve this refactoring without changing the interface of Solution: Cannot do
modify labels to +T-compiler and +C-cleanup.
The third unknown is probably impossible. All fields (except ) can be accessed from outside the file (). So the interface must change.
modify labels to +E-needs-mentor.
Change:
<del> // run-pass </del> <ins> // Regression test for various issues related to normalization & inlining. // * #68347, #77306, #77668 - missed normalization during inlining. // * #78442 - missed normalization in validator after inlining. // // build-pass </ins> // compile-flags:-Zmir-opt-level=2 <del> // Previously ICEd because we did not normalize during inlining, // see https://github.com/rust-lang/rust/pull/77306 for more discussion. </del> pub fn write() { create()() } <ins> pub fn write_generic<T>(_t: T) { hide()(); } </ins> pub fn create() -> impl FnOnce() { || () } <ins> pub fn hide() -> impl Fn() { write } </ins> fn main() { write(); <ins> write_generic(()); </ins> }

Discussion:
Previously: Now: <!-- 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
Inlining exposes a use of unnormalized local in a call terminator (not sure if this is more of an issue with inlining or a validator): Note: revision annotation doesn't work in an auxiliary file (so it isn't tested on CI with mir-opt-level=2). modify labels: +A-mir-opt-inlining
This ICEs again because the fix was reverted Can someone reopen please?
Due to this new requires to trigger. <details<summaryICE:</summary</details
(FWIW can also trigger this: )
fixes this for and , but it still ICEs with on its own or with mir-opt-level 1/2 cc
Change:
} } <ins> impl<T> ops::Index<uint, T> for [T] { fn index(&self, &index: &uint) -> &T { assert!(index < self.len()); unsafe { mem::transmute(self.repr().data.offset(index as int)) } } } impl<T> ops::IndexMut<uint, T> for [T] { fn index_mut(&mut self, &index: &uint) -> &mut T { assert!(index < self.len()); unsafe { mem::transmute(self.repr().data.offset(index as int)) } } } </ins> impl<T> ops::Slice<uint, [T]> for [T] { #[inline] fn as_slice_<'a>(&'a self) -> &'a [T] {

Discussion:
As titled. Although slices support the operator, it does not implement , so one cannot pass in a slice in the following example:
I'm somewhat inclined to think we could just remove the built-in indexing from entirely and thus remove/reduce the need for the special lang-items, although there's at least three considerations: the failure message for out-of-bounds indexing would be less informative (no file/line information), but debugging any other (e.g. ) already requires a debugger to get this info, so maybe it's not so bad. can't yet implement properly, so this would still need built-in support with (and thus the out-of-bounds failure lang items can't be entirely removed just yet), unless implicit coercions will work. needs to be fixed before will work properly (and I guess DST would make it work more nicely). Users would theoretically not see a change, since this would all happen inside (and ).
It's not possible due to lack of CTFE.
cc me
Should I send a PR implementing / for now, and we can evaluate later removing the built-in indexing? I already tested that PR, and the built-in indexing is preferred in the operation , but one go through the trait using .
Yes, please go ahead and do so. Thanks!
Change:
#[cfg_attr(not(test), rustc_diagnostic_item = "eprint_macro")] #[allow_internal_unstable(print_internals)] macro_rules! eprint { <del> ($($arg:tt)*) => { $crate::io::_eprint($crate::format_args!($($arg)*)) }; </del> <ins> ($($arg:tt)*) => {{ $crate::io::_eprint($crate::format_args!($($arg)*)); }}; </ins> } /// Prints to the standard error, with a newline.

Discussion:
https://crater- https://crater- https://crater- https://crater- https://crater- https://crater- is likely cause (cc
I'll fix this.
Fixed on beta with and on master. will be a more complete change and will likely land in 1.63 (or later).
Change:
ifdef TRACE CFG_RUSTC_FLAGS += -Z trace endif <del> ifdef CFG_DISABLE_RPATH CFG_RUSTC_FLAGS += -C no-rpath </del> <ins> ifdef CFG_ENABLE_RPATH CFG_RUSTC_FLAGS += -C rpath </ins> endif # The executables crated during this compilation process have no need to include

Discussion:
Followup to and . Can we completely eliminate our usage of rpath? Doing so would make our linkage more consistent across platforms since it doesn't work on windows. Nominating.
I think that the largest difficulty for this is that we build dynamically, and this means that if you have a fresh install of rust in a new location it won't work by default (you'll have to munge your os library path). If we could print out some helpful instructions of what to do, then I think that would be a much better situation, but I'm also not entirely sure how we'd do that.
If we defaulted to static linking then there would it would be easier to justify making people use LDLIBRARYPATH when they opt in to dylibs.
The only consideration that I have about static linking is that you'll install 5 copies of (as opposed to 3): with static linking rustdoc rustc rustpkg without static linking That being said, our distributions are already pretty big, so maybe this isn't much of a concern? I agree though that if we statically linked everything then we could easily take this route of action
IMO this is a concern. What's wrong with the current approach (link rust's own tools dynamically)? It works fine on windows since the DLLs are in the bin folder and for everything else it will soon link statically ().
Another use case for this came up on IRC. If you've got a rust installed locally in , then when you try to recompile rust again, the rpath for all the stage0-produced libraries will have something pointing into /usr/local. Apparently on some platforms when you run the stage1 , this means that you'll pick up all the /usr/local libs at runtime instead of the stage0-produced libs (causing errors until you uninstall rustc).
Accepted for 1.0, P-backcompat-lang.
Rust now builds and passes tests with . This feature could be disabled by default or completely removed, with as a suggestion for those who want to use a dynamically linked in their home directory on *nix.
Change:
pub trait Seek { /// Seek to an offset, in bytes, in a stream. /// <del> /// A seek beyond the end of a stream is allowed, but implementation /// defined. </del> <ins> /// A seek beyond the end of a stream is allowed, but behavior is defined /// by the implementation. </ins> /// /// If the seek operation completed successfully, /// this method returns the new position from the start of the stream.

Discussion:
std::io::Seek I got confused by this line and over on so after a little discussion it seems like this might be better wording for those of us who are silly A seek beyond the end of a stream is allowed, but it is implementation-defined. The hyphen makes it clear “implementation defined” is a known concept (and matches it’s usage elsewhere) and the “it is” makes it a bit more clear that the full sentence is considered and intentional. While normally I find brevity improves clarity, in this case if you don’t realize “implementation defined” is a single concept, it sounds like a thought that trailed off after an edit
Thanks I know other projects I've worked with have Easy and Documentation as tags so I wasn't sure if you guys might do the same
Yep, they're just actual labels over on the right ;-) (I also tabbed away and forgot to put the easy label on immediately )
Don't worry about that! It's very easy for developers to misjudge whether such descriptions will make sense to the target users. Pointing these things out is a great way to contribute to documentation.
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. pub trait OpInt<'a> { fn call<'a>(&'a self, int, int) -> int; } impl<'a> OpInt<'a> for 'a |int, int| -> int { fn call(&self, a:int, b:int) -> int { (*self)(a, b) } } fn squarei<'a>(x: int, op: &'a OpInt) -> int { op.call(x, x) } fn muli(x:int, y:int) -> int { x * y } pub fn main() { let f = |x,y| muli(x,y); { let g = &f; let h = g as &OpInt; squarei(3, h); } } </ins>

Discussion:
While trying to port the bug case from forward to more modern Rust syntax, I hit the following ICE:
Reproduced with ; nominating for milestone 5, production-ready
accepted for production-ready milestone
(still a bug. assigning to self for investigation as part of grokking the type/borrow check code.)
Probably a subbug of .
This is an updated code for this issue. With the following code, it is not possible to reproduce this issue: Can we close this issue?
A test should be checked in to close the issue.
+1, I'll submit a PR with the same example used here
Change:
<ins> // check-pass // // This tests checks that clashing_extern_declarations handles types that are recursive through a // pointer or ref argument. See #75512. #![crate_type = "lib"] mod raw_ptr_recursion { mod a { #[repr(C)] struct Pointy { pointy: *const Pointy, } extern "C" { fn run_pointy(pointy: Pointy); } } mod b { #[repr(C)] struct Pointy { pointy: *const Pointy, } extern "C" { fn run_pointy(pointy: Pointy); } } } mod raw_ptr_recursion_once_removed { mod a { #[repr(C)] struct Pointy1 { pointy_two: *const Pointy2, } #[repr(C)] struct Pointy2 { pointy_one: *const Pointy1, } extern "C" { fn run_pointy2(pointy: Pointy2); } } mod b { #[repr(C)] struct Pointy1 { pointy_two: *const Pointy2, } #[repr(C)] struct Pointy2 { pointy_one: *const Pointy1, } extern "C" { fn run_pointy2(pointy: Pointy2); } } } mod ref_recursion { mod a { #[repr(C)] struct Reffy<'a> { reffy: &'a Reffy<'a>, } extern "C" { fn reffy_recursion(reffy: Reffy); } } mod b { #[repr(C)] struct Reffy<'a> { reffy: &'a Reffy<'a>, } extern "C" { fn reffy_recursion(reffy: Reffy); } } } mod ref_recursion_once_removed { mod a { #[repr(C)] struct Reffy1<'a> { reffy: &'a Reffy2<'a>, } struct Reffy2<'a> { reffy: &'a Reffy1<'a>, } extern "C" { #[allow(improper_ctypes)] fn reffy_once_removed(reffy: Reffy1); } } mod b { #[repr(C)] struct Reffy1<'a> { reffy: &'a Reffy2<'a>, } struct Reffy2<'a> { reffy: &'a Reffy1<'a>, } extern "C" { #[allow(improper_ctypes)] fn reffy_once_removed(reffy: Reffy1); } } } </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. --It seems rustc can no longer handle how much is defined in these two binding files. If I comment out either module, it will successfully build. It was previously building on . Building this project on Windows: <!-- 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 --<!-- TRIAGEBOT_END --
This is the stack overflow. Some recursive call in ClashingExternDeclaration checking. I think this is . I tried to set across the files to see if it might help, but I am not sure if that is exposed. I didn't dig into too much, but it still seems to trigger. <!-- 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. --I am not sure why I don't see the commit hash in the build. First time building the compiler. : <details<summary<strongWindbg stacktrace</strong</summary</details
Pinging for clashingexterndeclarations in the meantime.
Uh oh, that's not good. Thanks for reporting! I'll get on this now. claim
Change:
} } <ins> ast::ItemDefaultImpl(..) => { self.gate_feature("optin_builtin_traits", i.span, "default trait implementations are experimental  and possibly buggy"); } </ins> ast::ItemImpl(_, polarity, _, _, _, _) => { match polarity { ast::ImplPolarity::Negative => {

Discussion:
I suspect that we may want more experience with this syntax before freezing it, but I may also be misremembering! cc cc
triage: I-nominated
I believe you're right. I'll work on a fix for this. Here's a test case:
0 beta, P-backcompat-lang.
Change:
// removing the "spoofed" `VaListImpl` that is used by Rust defined C-variadics. #[unwind(aborts)] // FIXME(#58794) pub unsafe extern "C" fn use_foreign_c_variadic_1_0(ap: VaList) { <del> // CHECK: invoke void ({{.*}}*, ...) @foreign_c_variadic_1({{.*}} %ap) </del> <ins> // CHECK: call void ({{.*}}*, ...) @foreign_c_variadic_1({{.*}} %ap) </ins> foreign_c_variadic_1(ap); } #[unwind(aborts)] // FIXME(#58794) pub unsafe extern "C" fn use_foreign_c_variadic_1_1(ap: VaList) { <del> // CHECK: invoke void ({{.*}}*, ...) @foreign_c_variadic_1({{.*}} %ap, [[PARAM]] 42) </del> <ins> // CHECK: call void ({{.*}}*, ...) @foreign_c_variadic_1({{.*}} %ap, [[PARAM]] 42) </ins> foreign_c_variadic_1(ap, 42i32); } #[unwind(aborts)] // FIXME(#58794) pub unsafe extern "C" fn use_foreign_c_variadic_1_2(ap: VaList) { <del> // CHECK: invoke void ({{.*}}*, ...) @foreign_c_variadic_1({{.*}} %ap, [[PARAM]] 2, [[PARAM]] 42) </del> <ins> // CHECK: call void ({{.*}}*, ...) @foreign_c_variadic_1({{.*}} %ap, [[PARAM]] 2, [[PARAM]] 42) </ins> foreign_c_variadic_1(ap, 2i32, 42i32); } #[unwind(aborts)] // FIXME(#58794) pub unsafe extern "C" fn use_foreign_c_variadic_1_3(ap: VaList) { <del> // CHECK: invoke void ({{.*}}*, ...) @foreign_c_variadic_1({{.*}} %ap, [[PARAM]] 2, [[PARAM]] 42, [[PARAM]] 0) </del> <ins> // CHECK: call void ({{.*}}*, ...) @foreign_c_variadic_1({{.*}} %ap, [[PARAM]] 2, [[PARAM]] 42, [[PARAM]] 0) </ins> foreign_c_variadic_1(ap, 2i32, 42i32, 0i32); }

Discussion:
I guess intrinsics need to be ed and not d? Maybe the MIR inliner is inlining the intrinsic's wrapper, but keeps the target intact when it shouldn't. Or this should be handled in codegen, not sure.
The implementation ends up calling pause intrinsic declared as follows: The rustc codegen is completely unaware that it is dealing with an intrinsic, it just changes the symbol name. Looks like the whole feature was introduced by accident, and feature gate was introduced after the fact to make it unstable.
Change:
self.parent_scope.module = module; } <ins> // These items do not add names to modules. ItemKind::Impl(..) | ItemKind::ForeignMod(..) | ItemKind::GlobalAsm(..) => {} </ins> ItemKind::MacroDef(..) | ItemKind::Mac(_) => unreachable!(), } }

Discussion:
<short summary of the bugI tried this code: Running on a project that has as its direct or indirect dependency. I expected to see this happen: All packages documented. Instead, this happened: — also fails on . : Does also happen for older nightlies, though I forgot to capture the versions before updating in hope it'd fix the issue. There are more ICE issues pointing at , but none on this line here. Backtrace:
I can confirm that this ICE does not occur on Rust 1.37.0 stable, as shown in This might be a regression that slipped through the stable release somehow.
This still happens on 1.39 stable.
cc
It also does it when documenting a project with on nightly. I had no trouble documenting all deps more than 2 weeks ago though.
This happened on our recent build rust 1.39.0 as well.
cc please triage regressions! If anyone would like to help out here: This is in need of a minimal example that reproduces the issue, as well as a bisection to pinpoint the PR that introduced this regression.
Sorry for not getting to this earlier. I've reduced down to: The is coming from the path inside which is messed up somehow by the macro. Bisecting this pointed to which almost certainly means it was caused by (cc. This is an issue in rustc as well because if you try to use the method from another crate like this for example: rather than the expected new` error since it now produces an ICE: <details<summarybacktrace</summary</detailsAnother interesting case comes from removing the inner module: This compile before but now somehow. Also the regressions in and are a similar but newer regression which I've made a new issue for: .
I guess I'll take a look since it's been a week. Thanks for the minimal code case!
Was this not fixed by ?
I don't know. If so then we're all good?
No, I can confirm there's still an ICE.
Is the nonrustdoc example from still ICEing or is it just the rustdoc issue left?
I'll see what happens.
Similarly to the case in this ICE in rustdoc may mean that a bug or error is silently ignored in rustc. So hiding it like does is not a good idea.
Fixed in
Change:
| = note: `#[warn(incomplete_features)]` on by default <del> error[E0741]: the types of const generic parameters must derive `PartialEq` and `Eq` </del> <ins> error[E0741]: `C` must be annotated with `#[derive(PartialEq, Eq)]` to be used as the type of a const parameter </ins> --> $DIR/forbid-non-structural_match-types.rs:11:19 | LL | struct D<const X: C>;

Discussion:
I tried this code: This produces the following error on rustc 1.44.0-nightly: I guess that const generics with a generic type isn't supported/allowed. If that's the case, this should be mentioned in the error message. :
The type needs to derive , not just implement them. This is because only types can be used for const generics at the moment, but we don't expose that to the user. Maybe we could improve the diagnostic here by actually mentioning .
thanks for fixing this so quickly! Is there a chance that this restriction will be lifted, so the above code compiles?
We would like to lift the restriction, but probably not in the first stabilised version of const generics, as it's not easy to get right: we need to be very careful in making sure that we don't accidentally allow unsoundness to sneak in, and there are many subtleties.
Change:
<ins> fn main() { fn x(a: &char) { let &b = a; b.make_ascii_uppercase(); //~^ cannot borrow `b` as mutable, as it is not declared as mutable } } </ins>

Discussion:
No response Applying the suggestion gives No response No response <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
It should suggest instead. Looks odd but it's correct. label -needs-triage A-suggestion-diagnostics D-invalid-suggestion
Hi, I'm interested in this issue and want to try to fix it. claim
Change:
<ins> #![crate_type = "rlib"] #![feature(alloc_error_handler)] #![no_std] #[alloc_error_handler] pub fn error_handler(_: core::alloc::Layout) -> ! { panic!(); } </ins>

Discussion:
Compiling following under some circumstances result in undefined references to : This linking issue occurs only under for some codegen partitioning but not the others. Reproducing it requires controlling the options that influence the number of codegen units. I can reproduce it with either , or combined with . The weak lang items introduce cyclic dependencies between crates. For example, the alloc crate depends on oom lang item which is defined in std. When linking the std comes first, and it may so happen that object file that contains definition is not used and omitted (this suggest why large number of codegen units is necessary to reproduce the issue), and subsequently alloc crate will fail to link. The [linking code][0] tries to account for cyclic dependencies using start-group and end-group, but as far as I can see it based on assumption that weak lang items dependencies are always reversed, which no longer holds true. [0]: