jiebi/CodeConvo huggingface dataset:
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. // ignore-tidy-linelength pub mod a { pub struct Foo { a: uint } } pub mod b { use a::Foo; impl Foo { //~ERROR inherent implementations are only allowed on types defined in the current module fn bar(&self) { } } } pub fn main() { } </ins>

Discussion:
The code <pretrait T {} impl&lt;U: T&gt; Vec&lt;U&gt; {} fn main() { let r = Vec::fromslice(&[1u]); } </prefails with 4:36 error: unresolved name . fn main() { let r = Vec::from_slice(&[1u]); } </preRemoving the <codeimpl</codeline causes the code to compile fine. Thx Ms2ger for finding such a small example case.
I think this is related to anonymous modules appearing, resolves to a module due to the impl. If you change to this you get another interesting error:
Note that a workaround is to wrap in parens, as Then you get the correct error message about trying to on a type outside of its crate.
I've spent some time investigating this bug and I think that the cleanest thing to do is to (closed B-RFC right now, does anyone have a link to a relevant RFC?) and require to occur only in the same module as, and after, the definition of . This check would be done before creating the anonymous trait module with name . Otherwise in the case of where a definition of is not visible, is not resolved until typeck (at which point the compiler will complain if is defined outside the current crate, or not at all), but if there are resolve errors like the current bug, these will be exposed to the user first and halt compilation. The current behaviour upon encountering where has not been defined in the current module is to create a module (which shadows any other modules exposed by statements) and try to resolve any symbols into this module. This means that the current support for outside of the module is defined in is <ialready</ibroken. Consider for example will error out with "unresolved name ". I'm sure I could come up with other examples of currently broken behaviour like this.
the closing of that bug predates our RFC process, so there would not be a link to an RFC.
Interestingly, this breaks in the opposite direction if you qualify the :
My suggestion is that should be disallowed. I will submit an RFC with these changes.
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. // ignore-tidy-linelength pub mod a { pub struct Foo { a: uint } } pub mod b { use a::Foo; impl Foo { //~ERROR inherent implementations are only allowed on types defined in the current module fn bar(&self) { } } } pub fn main() { } </ins>

Discussion:
Could this be fixed by "::unwrap" in the file (src/test/compile-fail/trait-or-new-type-) // error-pattern: found value name used as a type impl<TOption<T::unwrap { pub fn foo(&self) { } fn main() { } !
I don't understand your question, and that's not valid syntax. You can only create an impl for a type in the same module.
definitely I'm confused :-P. Im trying to determine how to fix this issue.Has been a while I didnt work with C like language(last 5 years have been working with C# and Java) ;-) If I create my own file (as you did writing the ) and implement the same code, I get the issue. Rust is a compiler, so Im assuming that a compiler file should be fixed in order to avoid the user implement namespace overlapping imports. Is my assumption correct about this problem?
Yes, your assumption is correct. The goal is to provide an error message that makes sense when a program tries to create an impl for a type that is not in scope (ie. does not exist).
The code I provided is a Rust compiler file (which i changed), not a new one. Im trying to understand where in the code can I implement this fix
Find the place that generates the error message, and follow the code backwards until it's clear where you could modify it to produce a better error message for this case.
Someone gave me a good tip on how to debug Rust I will try this. The terminal is quite archaic ;-P
I think point was essentially "grep for the error message, and look at the code there", using a full debugger to find out where it is is probably still quite hard at the moment. In any case, running turns up . So it looks like one could just expand the pattern to cover more cases.
I used Eclipse as explained by Michael and did a search and found that file. Now correct me if I'm wrong but the it seems that there is no "match a_def {" (startting at line 444) for the impl type. I'm going to attempt to add a case and test
in there is an enumeration, I dont see one for 'impl' (such as DefTrait for example) line 226. Isn't suppose to be one?

No, because the name we are creating an impl for is not itself an impl; the compiler seems to think that it is a module instead. Figuring out why this is the case would be a good start.
seems like astriranna solved the issue by adding: ast::DefMod(_) =
I just tested but this does not work for 'impl' (still get the same error message)
Yes, that is not a solution, just a slightly clearer (but still incorrect) error message.
Change:
<ins> // build-pass #![feature(type_alias_impl_trait)] use std::marker::PhantomData; /* copied Index and TryFrom for convinience (and simplicity) */ trait MyIndex<T> { type O; fn my_index(self) -> Self::O; } trait MyFrom<T>: Sized { type Error; fn my_from(value: T) -> Result<Self, Self::Error>; } /* MCVE starts here */ trait F {} impl F for () {} type DummyT<T> = impl F; fn _dummy_t<T>() -> DummyT<T> {} struct Phantom1<T>(PhantomData<T>); struct Phantom2<T>(PhantomData<T>); struct Scope<T>(Phantom2<DummyT<T>>); impl<T> Scope<T> { fn new() -> Self { unimplemented!() } } impl<T> MyFrom<Phantom2<T>> for Phantom1<T> { type Error = (); fn my_from(_: Phantom2<T>) -> Result<Self, Self::Error> { unimplemented!() } } impl<T: MyFrom<Phantom2<DummyT<U>>>, U> MyIndex<Phantom1<T>> for Scope<U> { type O = T; fn my_index(self) -> Self::O { MyFrom::my_from(self.0).ok().unwrap() } } fn main() { let _pos: Phantom1<DummyT<()>> = Scope::new().my_index(); } </ins>

Discussion:
I'm seeing an internal compiler error on the following input (found by ): Note that a similar issue () was recently closed. The fix for that ( it seems) apparently does not prevent this crash. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
It seems the ICE has been fixed in latest nightly.
Bisected, I think it has been fixed by . Adding regression test is reasonable so marked as E-needstest.

When the associated constant of an impl trait is referenced it creates an ICE: This panics on stable and nightly. Tested on , macOS and in Docker: : rustc 1.38.0 ( 2019-09-23) binary: rustc commit-hash: commit-date: 2019-09-23 host: x86_64-unknown-linux-gnu release: 1.38.0 LLVM version: 9.0 The panic originates from the same assertion as in : <details<summaryBacktrace:</summary</details
cc
triage: P-medium. Removing nomination label.
The ICE seems to disappear on latest nightly, could someone confirm it?
Fixed by , but I believe it could do with a compile test
Change:
assert-size: (".item-info .stab", {"width": 289}) assert-position: (".item-info .stab", {"x": 245}) <ins> // We check that the display of the feature elements is not broken. It serves as regression // test for <https://github.com/rust-lang/rust/issues/118615>. set-window-size: (850, 800) store-position: ( "//*[@class='stab portability']//code[text()='Win32_System']", {"x": first_line_x, "y": first_line_y}, ) store-position: ( "//*[@class='stab portability']//code[text()='Win32_System_Diagnostics']", {"x": second_line_x, "y": second_line_y}, ) assert: |first_line_x| != |second_line_x| && |first_line_x| == 516 && |second_line_x| == 272 assert: |first_line_y| != |second_line_y| && |first_line_y| == 688 && |second_line_y| == 711 </ins> // Now we ensure that they're not rendered on the same line. <ins> set-window-size: (1100, 800) </ins> go-to: "file://" + |DOC_PATH| + "/lib2/trait.Trait.html" // We first ensure that there are two item info on the trait. assert-count: ("#main-content > .item-info .stab", 2)

Discussion:
! by
I'll try to change the display because it's really not great.
I wonder whether the formatting is the issue rather than the algorithm used to discover the required features. The formatting goes awry in the example above due to the large number of (redundant) features: That's technically correct, but not entirely helpful to a developer either. ' has the following entries in its table: To use , the only feature a client needs to enable is . The remaining features are automatically enabled recursively via the It would seem reasonable to prune the feature list by eliminating those features that are implicitly enabled. Doing this solves two issues: It makes the formatting a non-issue (here). It declutters the documentation, showing only information that clients can act upon. I'm not aware of a way to cancel automatic enablement of dependent features, so dropping this information from the documentation should be inconsequential in practice. If the formatting is being reworked nonetheless, here's what I'd like to see: Enclose the feature names in ASCII double quotes () for convenient copy-pasting. The crate to prevent them from being converted to smart quotes. Make the list comma-separated (again, for convenient copy-pasting). I understand that (as used currently) carries semantic information that needs to be reflected elsewhere. If is being used, it can remain as-is. We commonly don't need to copy-paste disjunct features.
Change:
$RUSTC src/lib.rs -Z treat-err-as-bug=1 1>$TMPDIR/rust-test-default-set.log 2>&1 default_set=$(cat $TMPDIR/rustc-ice-*.txt | wc -l) content=$(cat $TMPDIR/rustc-ice-*.txt) <ins> # Ensure that the ICE dump path doesn't contain `:` because they cause problems on Windows windows_safe=$(echo rustc-ice-*.txt | grep ':') if [ ! -z "$windows_safe" ]; then exit 1 fi </ins> rm $TMPDIR/rustc-ice-*.txt RUST_BACKTRACE=short $RUSTC src/lib.rs -Z treat-err-as-bug=1 1>$TMPDIR/rust-test-short.log 2>&1 short=$(cat $TMPDIR/rustc-ice-*.txt | wc -l)

Discussion:
While investigating the ICE in , I saw that every attempt at writing the ICE details to a file (first implemented in ) would fail on my Windows machine with error messages of this kind: The timestamp format used for the file name separates time components with colons, and Windows is generally finicky about having colons in file names since it is already employed as the drive unit delimiter. Could there be a change in the file name format for better compatibility, at least when running rustc on a Windows host? : </p</details
cc
Yes, we can change the format.
Change:
<ins> error[E0425]: cannot find function `size_of` in this scope --> $DIR/filter-intrinsics.rs:3:13 | LL |     let _ = size_of::<usize>(); |             ^^^^^^^ not found in this scope | help: consider importing this function | LL | use std::mem::size_of; | error[E0425]: cannot find function `fabsf64` in this scope --> $DIR/filter-intrinsics.rs:8:13 | LL |     let _ = fabsf64(1.0); |             ^^^^^^^ not found in this scope | help: consider importing this function | LL | use std::intrinsics::fabsf64; | error: aborting due to 2 previous errors For more information about this error, try `rustc --explain E0425`. </ins>

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. 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: Ideally the output should look like: In cases where intrinsics have been stabilised in | it would be useful to suggest these to users first. Especially as using intrinsics generates another error that tells you to prefer stabilized functions in . This would hopefully make handling this error easier for new rust users coming from languages like C/C++ and looking for the equivalent of <!-- 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. --The output is the same on stable, beta and nightly
I'd be satisfied if we filtered out intrinsics altogether except for when the feature was enabled.
I also get quite annoyed when stable rustc recommends I use unstable features (maybe that should be fixed in an RFC)
Checking the DefId of each suggested path to see if they are annotated with should be doable.
This seems to be harder than I initially thought... so since we emit this "consider importing" suggestion in , we do not have access to it seems. And I have no idea how to extract the attributes from each without ... :thinking:
We might want to consider adding yet another dumping ground field in the itself or in ... But at that point it seems like too much mem consumption for little gain. The other option is to delay the emitting of these errors until later, but that also seems... like a lot of additional complexity :-/
For now, I guess it wouldn't hurt just to filter suggesting paths that are literally (and ) instead of going thru all of the work of adding more info to the . I can put up a PR that does that later.
Change:
"serde_json", "tracing", "tracing-subscriber", <ins> "unified-diff", </ins> "walkdir", "winapi 0.3.9", ]

Discussion:
When running on Linux and a failure happens, a really nice diff of the output vs rustdoc-nightly is produced which very clearly shows the issue. This does not work on Windows for multiple reasons. One the call to fails: Second, the output from rustdoc-nightly seems to exactly match that from the local compiler making it not possible to do manual diffs.
How do you diff directories recursively on Windows? On Linux I would be very surprised for not to be installed. Oh I just thought of something - do you have a rustup overide that defaults to your local toolchain? Right now compiletest assumes the default is nightly, I've been meaning to change it.
No, I only set overrides on specific projects (and rust-lang/rust is not one of them). My default is the stable compiler.
Git for Windows provides : Are you building Rust using Git Bash prompt?
I don't think it'd be a good idea to require testing rustdoc in the Git for Windows bash shell. I'd like for this to work in and PowerShell if possible.
Change:
<ins> struct S {} trait T<'a> { type A; } impl T<'_> for S { type A = u32; } fn foo(x: impl Fn(<S as T<'_>>::A) -> <S as T<'_>>::A) {} //~^ ERROR binding for associated type `Output` references an anonymous lifetime //~^^ NOTE lifetimes appearing in an associated type are not considered constrained fn main() {} </ins>

Discussion:
The following code causes an error () Errors:
Reduced:
seems like this bug dates at least to when was stabilized in 1.26.0
bug dates back to at least nightly-2017-10-15 and perhaps earlier. It seems reasonable right now to assume its been present ever since was introduced.
I'm going to have to do some background reading to remember what we are supposed to do in a case like this. If you remove the occurrences of you get the same ICE behavior, and that behavior dates all the way back to rust 1.10.0:
triage: P-medium. Removing nomination. Assigning to self.
I just ran into this on 1.41.1. Attempted to minimize what I was doing and ended up basically identical to Centril's above.
If it helps, this slightly modified snippet produces no ICE but a very odd error: In that code is , so it seems like something isn't being fully expanded somewhere?
Seems related to note that in needs to be generic to compile, but the output type can be changed to
Change:
CastKind::Pointer(PointerCast::ArrayToPointer) => { let ty_from = op.ty(body, tcx); <del> let opt_ty_elem = match ty_from.kind() { ty::RawPtr(ty::TypeAndMut { mutbl: hir::Mutability::Not, ty: array_ty, }) => match array_ty.kind() { ty::Array(ty_elem, _) => Some(ty_elem), _ => None, }, </del> <ins> let opt_ty_elem_mut = match ty_from.kind() { ty::RawPtr(ty::TypeAndMut { mutbl: array_mut, ty: array_ty }) => { match array_ty.kind() { ty::Array(ty_elem, _) => Some((ty_elem, *array_mut)), _ => None, } } </ins> _ => None, }; <del> let ty_elem = match opt_ty_elem { Some(ty_elem) => ty_elem, </del> <ins> let (ty_elem, ty_mut) = match opt_ty_elem_mut { Some(ty_elem_mut) => ty_elem_mut, </ins> None => { span_mirbug!( self,

Discussion:
cc is this a coercion that's expected to work?
triage: I-nominated
The first cast is from to , the second is from to . I'm not actually sure if this is meant to work, I guess it should. The intention here is to give a way to treat arrays like C-arrays and get a pointer to the start of the array. It seems that if the array is mutable, then the pointer should be too. I recommend this is P-low - it is backwards compatible, rare, and just a bug by omission, really. The fix should be pretty easy though.
Ah I wasn't sure if this was intended, if it's actually intended then I don't mind removing the nomination as well!
I'm not sure how intended this is, but it doesn't seem too harmful. ;)
P-low, (perhaps "just a bug", perhaps a minor feature.)
Triage: no change
This still happens today (with ), but the error message is slightly different: is another -related issue.
Change:
<ins> enum VecOrMap{ vec: Vec<usize>, //~^ ERROR expected one of `(`, `,`, `=`, `{`, or `}`, found `:` //~| HELP: enum variants can be `Variant`, `Variant = <integer>`, `Variant(Type, ..., TypeN)` or `Variant { fields: Types }` //~| ERROR expected item, found `:` map: HashMap<String,usize> } fn main() {} </ins>

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. 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. --Although I know Enums take to form of: I sometimes find myself accidentally defining them as I would a Struct (): The current output is: This always takes more than a few seconds to parse and then realize my mistake. Is it possible to change this to something like: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Do you have any suggestion for how the compiler should distinguish between "trying to write an enum with struct syntax" and "trying to write a struct but used the enum keyword"?
Linking to the topic on internals where some other folks have left suggestions (). Although none of those directly address your question. My gut reaction is to assume that if the "enum" keyword is used that truly was the intention of the developer, but if it wasn't, hopefully some help message like the : Would provide enough information to trigger an "Oh wait did I really want to use an enum here?"
claim
Change:
// ignore-wasm32-bare no libc to test ffi with // ignore-sgx no libc <ins> // Ensure no false positive on "unused extern crate" lint #![deny(unused_extern_crates)] </ins> #![feature(rustc_private)] extern crate libc;

Discussion:
When compiling this code with , I get an incorrect warning: The is used; removing it breaks the program. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Have you checked this on nightly? This looks like a duplicate of and it was fixed a couple of days ago.
Yes, this is with
Note that I need to add . No warning is shown without that flag.
I can reproduce on playground with as well:
I cannot reproduce the warning any more, it seems to be fixed. However, I am not sure if there is a testcase for that.
label: +E-needs-test Test could be to (which is the example above). The in can probably also be removed
claim
Unassigning because they told me that they don't have the time to do this.
claim
Change:
<del> Subproject commit 54bbbd13ac532deed80416295a224ce12547a40c </del> <ins> Subproject commit e09dce0f43993faf03cc46ac365b6a46287f90e7 </ins>

Discussion:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool miri has failing tests. A follow-up PR to the repository is needed to fix the fallout. cc do you think you would have time to do the follow-up work? If so, that would be great! <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
We still need to land the Miri update in the rustc repo (I'll take care of that)
Change:
config.ninja_in_file = true; config.llvm_static_stdcpp = false; config.backtrace = true; <del> config.rust_optimize = true; </del> <ins> config.rust_optimize = RustOptimize::Bool(true); </ins> config.rust_optimize_tests = true; config.submodules = None; config.docs = true;

Discussion:
It would be nice if we could speed up stage1 library builds by building it with less opts and no debuginfo. had the idea to control this with something like <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
i'm going to use as a separate more broad issue for - i'll repurpose this to just be for (which is a lot simpler to add)
mentoring instructions: add this option to the struct, then around , set
Can we confirm before we land this support that this is actually a significant win in practice? I recall historically having issues with optimize = false equivalents where the net effect is broken and slower tests - I would prefer to avoid landing support we don't want to actually support :)
this is especially useful in combination with - optimizing only rustc and not std should be a speedup even if we include the time taken for tests.
claim
Maybe we should just generalize the config value to a number/boolean, instead of adding a new attribute?