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 impl B { //~ERROR inherent implementations are not allowed for types not defined in the current module. } 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 impl B { //~ERROR inherent implementations are not allowed for types not defined in the current module. } 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:
use super::method::MethodCallee; use super::FnCtxt; <ins> use rustc_ast as ast; </ins> use rustc_errors::{self, struct_span_err, Applicability, DiagnosticBuilder}; use rustc_hir as hir; use rustc_infer::infer::type_variable::{TypeVariableOrigin, TypeVariableOriginKind};

Discussion:
Code: Playground: Error message: Somehow, in one case this in the expression is unsigned, but in the other case it is signed and everything is fine. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
For the compiler has to suggest to replace it with . The compiler should also suggest to replace with , to remove some hard "as" casts from the code.
claim
I think this is more appropriate as a clippy lint, opened
Change:
use codemap::*; use super::*; <del> fn is_freeze<T: Freeze>() {} // Assert that the AST remains Freeze (#10693). #[test] fn ast_is_freeze() { is_freeze::<Item>(); } </del> // are ASTs encodable? #[test] fn check_asts_encodable() {

Discussion:
To the extent possible, we should try to have all interior mutability be done via , , , or (not yet landed) . If one of these patterns doesn't suffice, it'd be nice to know why!
Nominating for P-Low
Tagging as E-Mentor; I can mentor.
Related to Other types that use interior mutability I can think of off the top of my head: -
I'm definitely interested. Though---having never been a part of a project like this before---not quite sure how the mentoring works just yet :P
This is the part: .
I don't understand the reasoning behind doing this for . Using a marker type makes the intent clearer, and will perform better with optimizations disabled. The type is also supposed to be when is and this will make it always non-. The type should also be .
Marker types do not seem clearer to me than , quite the opposite, but of course thi is a matter of opinion. At first I thought you were on to something regarding , but then I realize that I was mistaken. In particular, we need to settle on precisely what makes something not : must the interior mutability be something interior, something that you own, or just something you can reach? But this question is orthogonal to whether we use markers or . If I understand it, the use of would look something like this: In this case, whether or not is will hinge directly on what we decide about owning vs mutability. At present, the definition is based on reachability. But this definition may be stronger than what we need. I guess it depends on just what is to be used for. So after considering this some more, I still think that using is the right call for is the right call, but the real discussion is what precisely ought to mean, which is most properly discussed I think under . make sense?
I don't think we have a way of enforcing deep immutability. There are many existing types doing internal writes due to I/O. I don't know of a purpose for beyond the high-level semantic meaning (perceived inherited mutability) and type-based alias analysis (which is not deep) so that's the lens I'm viewing it through.
Every type using memory allocation needs to become non- if means deep immutability. The function is mutating memory via the pointer.

So it's not just a problem with I/O.
I don't believe that is an accurate summray of what was proposed, but it is a moot point, as in the latest plan there is no Freeze.
Is there a change to coming? is already using .
I think and I decided that is already using the right primitives and it was just that wasn't.
Though I didn't dig too deeply, maybe can confirm. But it looked to me like it was using the proper abstraction (is there more than one?)
Indeed, is correctly implemented as-is it appears.
I'm running into tests not compiling because something doesn't implement Freeze. Should I wait for to land before I continue?
I actually did not realized that is already on this issue. I'll let you handle this one :D
Assigning P-low as suggested.
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 (tx, rx) = channel(); spawn(proc() { loop { let tx = tx; //~^ ERROR: use of moved value: `tx` tx.send(1); } }); } </ins>

Discussion:
compiles . Runs . Connection refused and segfault.
This is a bug in the treatment of captured variables. The line in question is: This is moving into the loop repeatedly when you should only be allowed to do it once. I think I've seen this bug before, but just in case, cc
thanks I've seen some reports of bugs like this before -- it's clear that we need to revisit the code used to check "once fns" -- it was as a temporary start towards support (under a -Z flag) and then pressed into full service, clearly not quite ready for prime time.
Nominating.
updated title to reflect the real issue at hand.
cc
Assigning 1.0, max(P-backcompat-lang, P-high). Gotta fix. edit: The use of above is sort of a joke: take the max of the two P-tag inputs. (Also, I originally wrote P-backcompat-libs, but I'm pretty sure that was a typo.)
Change:
pub struct Const<'tcx> { pub ty: Ty<'tcx>, <del> // FIXME(eddyb) Replace this with a miri value. </del> pub val: ConstVal<'tcx>, }

Discussion:
After , when a trait bound fails and the trait was implemented by fixed-size arrays, the compiler will display an error like: Which is pretty unhelpful. A solution would be to evaluate these and/or to show evaluated bounds preferably.
I can't reproduce triggering an error with these messages, do you have an example? I need it for a regression test, the fix was indeed as simple
It only appears if you explicitly disambiguate the trait, like . .
are you displaying these as ? I feel that'd be a reasonable output for this.
that would be a better fallback than , but I'm currently trying to get at the actual value (though that triggers cycle errors atm when building libcore's array impls ^^)
That's better in some ways, but kinda implies that
Change:
<ins> // compile-flags: -C panic=abort #![no_std] #![no_main] #[panic_handler] fn panic(_: &core::panic::PanicInfo) -> ! { loop {} } </ins>

Discussion:
It seems like fails is there is a dependency that has a and a binary that defines it as well, even if the dependency is never imported. I ran into this issue when I had 1 nostd bin per crate, where one binary had a custom panic_impl and another used that from a dependency. Minimal reproduction: The following works: But this fails (also when specifying target) : label +T-rustdoc
Possibly similar cause:
Seems like this happens even with so not really a good workaround, yuck...
I can't reproduce the bug locally. Do you still have the issue?
Interesting - it looks like it was broken on but working on my current . Probably not worth bisecting, but maybe a regression test would be good if there isn't one?
Agreed, wanna add one? Otherwise I plan to do it in the next hours.
I'm not too familiar with the test patterns for rustdoc, so I'll just leave it to you if you don't mind
No problem!
Change:
touch "$TOOLSTATE_FILE" <ins> # Try to test all the tools and store the build/test success in the TOOLSTATE_FILE </ins> set +e python2.7 "$X_PY" test --no-fail-fast  src/doc/book 

Discussion:
I think this is the fourth beta I'm having to re-figure-out how all this works and figure out how to ignore their failures on beta. can we just exclude these tools from toolstate until this is figured out?
I'm slightly confused, why would these tools need to be disabled/their submodule update if they were building on master? Isn't the beta just the current master branch + some tweaks for --version output and no unstable features? The release in March actually prevented the merge of any PRs on master that would break a tool. So I thought the idea was to fix all tools in that week. Or is this about beta backports breaking tools?
I don't think we've had a beta yet whether either clippy or miri were passing tests and fails the build if any tool fails to build on beta. We also do not want to release either of these tools to stable/beta yet.
neither of these tools has a step, so there's no danger in that (the last beta) didn't have clippy issues. Since we have grace period of a week, I can easily get in a working clippy within that week (which then won't be broken until the beta). My issue is mainly that I don't really know when it begins ;) Maybe we can ping the tool authors once a day that their tool needs to be fixed for the upcoming beta?
My point with this issue is that we shouldn't automate ourselves into a hole where tools we do not want to ship block releases. That should not require authors to fix tools, we should simply ignore failures or have an easy way of disabling them. Right now producing a beta is pain as you have to resend it to bors multiple times after re-learning that these are blocking the release. We do not ship miri/clippy but a successful clippy compilation affects how rls is compiled, which should not be happening on beta/stable.
The code that influences rls is explicitly skipped on beta/stable, so the rls is completely free of clippy on beta/stable for miri I agree, but for clippy, aren't we trying to move to a model where we actually dist it on stable, so I'd call having it ready for stable some form of proof of concept for the distributing part.
Ok sure yes rls is protected but I feel like this is missing my point. Miri isn't ready. Clippy isn't ready. They're blocking beta releases. That shouldn't happen.
Change:
#[stable(feature = "chunks_exact", since = "1.31.0")] #[inline] pub fn chunks_exact(&self, chunk_size: usize) -> ChunksExact<'_, T> { <del> assert!(chunk_size != 0); </del> <ins> assert_ne!(chunk_size, 0); </ins> let rem = self.len() % chunk_size; let len = self.len() - rem; let (fst, snd) = self.split_at(len);

Discussion:
In the stdlib I'd like an iterator like chunksexact that yields fixed-sized arrays, using a const usize argument (mostly useful for short arrays). .chunksexactct::<3() .map( a + b + c) Those arrays could allow better optimizations and also better pattern matching. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
This also applies to the method on slices.
We should actually be able to implement this and test it out unstably now.
Im willing to give this a shot in the weekend and next week!
assign
So, a simple PoC fails to compile horribly <details<summary<strongBacktrace</strong</summary<p</p</details
Notice that a freestanding function does work:
The more I go into this, the more obstacles I stumble upon. Below a list of all ICE's I encountered:
Keep going on, those bugs/limitations are worth fixing anyway :)
to_array() could be a new function related to take(), it collects the first N items of an iterator into an array of length given as const generic argument (it panics if the iterator isn't long enough). Usable like this (using iterate() from itertools):
EDIT: This is already PR'd:
We need a good built-in static_assert that works with constant generics too :)
Change:
<ins> // ignore-tidy-linelength </ins> pub mod module { pub mod sub_module { pub mod sub_sub_module {

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. --Repro: text /// aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa /// rust /// bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb /// Rustdoc output: ! It seems that only code block with language are affected. cc
A quick test showed that the bug was introduced in (i.e.: works fine)
label +regression-from-stable-to-nightly
Thanks, I'll fix it in the next hours.
In case you want to take a look to the fix, it's .
Change:
text-overflow: ellipsis; margin: 0; } <del> .docblock-short code { </del> <ins> /* Wrap non-pre code blocks (`text`) but not (```text```). */ .docblock > :not(pre) > code, .docblock-short > :not(pre) > code { </ins> white-space: pre-wrap; }

Discussion:
When documenting the handling of whitespace in the crate, I noticed that whitespace is collapsed in inline code. That is, is rendered the same as Test it with It worked on Rust 1.50: ! It stopped working on Rust 1.51. I tracked down the change to , which removed from the CSS. The page now looks like this: !
Note that a fix here could potentially create a regression for ascii art on mobile. Need to double check the vec page.
Assigning and removing as in the prioritization working group. label: +P-high -I-prioritize
Change:
[ad]: https://github.com/rust-lang/rust/pull/27382 [win]: https://github.com/rust-lang/rust/pull/25350 <del> Version 1.1.0 (June 2015) </del> <ins> Version 1.1.0 (2015-06-25) </ins> ========================= * ~850 changes, numerous bugfixes

Discussion:
Pages like Wikipedia/Wikidata need to prove that a given information is correct. The announcement blog posts seem to be the only obvious place to look up the the exact release dates. Blog post URLs are not necessarily stable over time. It would be simpler to just refer to
They already contain the month and the year, is the day that important? (that said, I don't see the harm, I was just like "I thought we did this already")
That probably depends on the context. Most software on Wikidata has the complete date defined along the versions. Does it hurt? If the days where given, what could be reasons to remove them? I would add the days in a PR myself, just wanted to make sure there is no opposition. I suggest we use ISO-format. The dates are currently defined in Wikdata as
Change:
#[inline] #[stable(feature = "atomic_access", since = "1.15.0")] pub fn into_inner(self) -> bool { <del> unsafe { self.v.into_inner() != 0 } </del> <ins> self.v.into_inner() != 0 </ins> } /// Loads a value from the bool.

Discussion:
It's been unsafe since 2014 when it was called . Nobody thought about it, I guess, but it shouldn't be unsafe.
For reference the PR which it is
Someone thought about it enough to : Has something changed to make this consideration unnecessary or do you have an explanation of why the reasoning is faulty?
Because the function takes so by definition it must be the owner of the value so there can be no other viewers, either from this thread or another thread.
Although this isn't backwards-compatible there is some prior art of going unsafe -safe: (although, that was pre-1.0)
That's weird, it seems like you ought to be able to assign a safe fn to an unsafe fn pointer. , Nicole Mazzuca wrote:
We removed the subtyping relation at some point; it does seem like a coercion would be (probably) ok, but that would still not be (strictly) backwards compatible.
(I tend to agree that could be safe, though, and I highly doubt any existing crates would actually break due to this change.)
We could always do a crater run just to be absolutely sure nobody is turning into a function pointer.
HI ! Any news on this one ?
No change that I know of.
FWIW the relevant coercion was in
This change is breaking my crate. If I add the then it will work for older compilers. If I remove the then it will work for newer compilers. Is there a conditional compilation attribute for compiler version? I can't find one.
Use
Yeah, that's what I'm doing for now. It seems kind of lame, though. But it does work.
Change:
/// Returns true if the type is represented as a pair of immediates. pub fn type_is_imm_pair<'a, 'tcx>(ccx: &CrateContext<'a, 'tcx>, ty: Ty<'tcx>) -> bool { <del> let tcx = ccx.tcx(); let layout = tcx.normalizing_infer_ctxt(Reveal::All).enter(|infcx| { match ty.layout(&infcx) { Ok(layout) => layout, Err(err) => { bug!("type_is_imm_pair: layout for `{:?}` failed: {}", ty, err); } } }); match *layout { </del> <ins> match *ccx.layout_of(ty) { </ins> Layout::FatPointer { .. } => true, Layout::Univariant { ref variant, .. } => { // There must be only 2 fields.

Discussion:
On stable, beta, and nightly, the follow code prints followed by : CC
This is probably for drop flags, in which case it should get fixed by
Reduced:
where would there be a drop flag here?
My point isn't that there is, but that the code assumes all trait objects have drop flags. I could be wrong though, it might be a bug in the alignment logic.
Not fixed by , will have to investigate further.
Uhhhh, the computation starts with: Which is completely wrong, because you want no trailing padding, i.e. should be . EDIT: getting a field pointer might also be broken, needs looking into. EDIT2: to handle the "minimum size" needed to compute the field offset, so that works.
Change:
<del> //@ known-bug: #124347 trait Trait: ToReuse { reuse Trait::lolno { &self.0 }; } </del>

Discussion:
<!-- [31mICE[0m: Rustc '' 'thread 'rustc' panicked at 'no entry found for key'', 'thread 'rustc' panicked at 'no entry found for key'' File: --auto-reduced (treereduce-rust): original: Version information ` Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details<!-- query stack: [hircrate] getting the crate HIR [hirattrs] getting HIR owner attributes in `` [entry_fn] looking up the entry function of a crate [analysis] running analysis passes on this crate --
cc