jiebi/CodeConvo huggingface dataset:
Change:
if !cx.renderinfo.borrow().access_levels.is_public(did) { return; } <ins> if let Some(stab) = tcx.lookup_stability(did) { if stab.level.is_unstable() && stab.feature == sym::rustc_private { return; } } </ins> } }

Discussion:
Missing Implementors for [][1] trait. Current output: ! While rustdoc displays [][2] trait implementors. Expected: Display Implementors for Join trait: : 1.47.0-nightly ( 2020-08-15) [1]: [2]: modify labels: T-rustdoc
This is a regression from stable-to-nightly: and beta one has Implementors section. cc
It has made it way to beta. Pattern trait is also affected: modify labels: I-prioritize
(Btw I think you can use as a shorthand)
The Borrow trait still has , I am not sure if this bug affect crates in ecosystem.
So I think this bug shouldn't affect stable traits, just most unstable traits I saw are affected.
There is high change that causing the regression, but I cannot prove that.
This is more likely to be than the refactor I think.
Yeah, I suspect that given it might make sense to revert anyway, since it doesn't actually accomplish the goal. Or someone more experienced with rustdoc may be able to suggest/implement a better patch.
New discovery: So far only trait exported to std affected. For example with Join trait, in alloc it is normal:
Oh right, I have MCVE, it needs two dummy crates. <details<summarydummy crate "unstabled"</summary</detailsCrate to run : modify labels: -E-needs-mcve
searched nightlies: from nightly-2020-06-04 to nightly-2020-07-17 regressed nightly: nightly-2020-07-17 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.5.2</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
That rollup includes both and ; of the two I think is the more likely culprit.
Marking as P-high .

appears on the current nightly's, even though it's not part of the (public) standard libraries. This appears to be , so maybe related to , cc Noticed by (assuming they use the same handle here and discord, if not, sorry :flushed:)
Relevant PRs (backtrace isn't really to blame here): ,
Maybe this should also skip the impl if there is no 'stability' attribute? ,
This is the default for everything not in the standard library. So it seems like the standard library needs special casing here. Maybe as simple as ?
Doesn't gimli get everything marked as unstable behind the rustc_private feature gate through a rustc flag?
MCVE: It doesn't require any external deps, just dummy crates included. The outermost crate is a fake std, realcore is fake core, gimli is fake gimli.
Change:
<ins> // only-x86_64 #[cfg(target_arch = "x86")] use std::arch::x86::*; #[cfg(target_arch = "x86_64")] use std::arch::x86_64::*; unsafe fn pclmul(a: __m128i, b: __m128i) -> __m128i { let imm8 = 3; _mm_clmulepi64_si128(a, b, imm8) //~ ERROR argument 3 is required to be a constant } fn main() {} </ins>

Discussion:
Expected the following code to compile But getting Repro:
Also happens on beta, not on stable
Stable says:
For reference, the function signature as defined is exactly the same.
The actual ICE occurs first in nightly-2019-03-03 (...). But interesting enough, stable (as jonas pointed out) procuces an error, saying, that the third argument must be a constant. Since nightly-2019-02-16 (...) this does not emit an error anymore, but also does not ICE.
I guess for the "does not emit an error anymore" can say something about it. should be responsible for it.
triage: P-high
Note that because of the on the definition, you can't wrap it (without matching on and having 256 separate calls). I don't think this is intentional, but I'm not sure why it would happen, maybe arguments are treated incorrectly in the qualifier. cc
So I agree that this code can't compile, that's the expected behavior; if you want to wrap it, you have to use a macro - Rust functions aren't able to abstract over this type of hardware operations yet. The ICE is a regression over the error message that was being produced before. We should definitely add an ui test for that.
triage, assigning to self to fix the stable-to-beta regression.
The behavior here varies with edition as well as channel. edition 2018 ------------------ ------------------------ stable expected error beta unexpected compile-pass nightly-2019-04-05 ICE I think the most immediate thing to address is the unexpected compile-pass that has leaked into beta.
The easiest thing might be to revert
I have an actual fix in (also easier to backport than a revert)
Okay then I'm reassigning to
Change:
let discr_size = machine::llsize_of_alloc(ccx, ll_inttype(ccx, discr)); let (field_size, field_align) = union_size_and_align(fields); <del> // field_align < 1<<32, discr_size <= 8, field_size < MAX_OBJ_SIZE <= 1<<61 </del> <ins> // field_align < 1<<32, discr_size <= 8, field_size < OBJ_SIZE_BOUND <= 1<<61 </ins> // so the sum is less than 1<<62 (and can't overflow). let total_size = roundup(discr_size, field_align) + field_size; <del> if total_size >= ccx.max_obj_size() { </del> <ins> if total_size >= ccx.obj_size_bound() { </ins> ccx.report_overbig_object(scapegoat); } }

Discussion:
LLVM does not support objects larger than bytes, because it represents sizes as counts of bits. Currently, to be safe, I'm blocking compile-time objects bigger than 2 GiB (in case LLVM uses an int count of bytes somewhere). It would be nice to find out how much can we increase this, especially on 64-bit targets.
bounds object size by 2 GiB on 32-bit architectures and 128 TiB () on 64-bit architectures.
Change:
/// /// [`Ok`]: ../../std/result/enum.Result.html#variant.Ok /// [`Err`]: ../../std/result/enum.Result.html#variant.Err <del> /// [`into_inner`]: ../../std/sync/struct.Mutex.html#method.into_inner </del> <ins> /// [`into_inner`]: ../../std/sync/struct.PoisonError.html#method.into_inner </ins> #[stable(feature = "rust1", since = "1.0.0")] pub type LockResult<Guard> = Result<Guard, PoisonError<Guard>>;

Discussion:
someone in IRC mentioned should actually point to . i would fix it myself, i don't really understand what the sentence means that uses that link (but i'm also pretty tired).
It doesn't seem logical to me: this is returned from a method, so it's normal that we're talking about the method, no?
So, is how you get a , but that sentence is trying to point to .
Then we just rephrase it in order to make it sound more logical. :)
Change:
))], )) } <del> Ok(s) => cx.expr_call_global( </del> <ins> Some(value) => cx.expr_call_global( </ins> sp, cx.std_path(&[sym::option, sym::Option, sym::Some]), <del> vec![cx.expr_str(sp, Symbol::intern(&s))], </del> <ins> vec![cx.expr_str(sp, value)], </ins> ), }; MacEager::expr(e)

Discussion:
This is still in 's build script: But the use site has been moved here: This means that won't be rebuilt when that env var changes. For the record, I haven't seen a bug from this, was just curious where may be used and spotted the mismatch. cc
Found another one: is used in but it's still mentioned by . cc Could we automate ensuring this? e.g. by searching for in tidy.
Yeah, we can try I guess. Not sure :) Maybe the right solution is that Cargo would, other than some whitelist, remove unknown variables from rustc's environment -- and the whitelist can be expanded via the build script env-tracking.
hmm I wonder if abusing the file format (from ) or encoding this extra info in a comment, would be a good idea.
You mean such that if you use we automatically tell Cargo to rebuild on changes? (That's ). But yeah, I think that would be good. Ideally this would be "well-integrated" vs. the current state of everyone having to remember to do it.

(As discussed with on IRC.) Rustc should have an option to obtain a list, as part of building, of every environment variable that was requested via the or macros (tagged accordingly with "required" or "optional"), as well as providing a way to instrument intrinsics like called by scripts. This will make it more feasible to detect (and lint about) the usage of environment variables only set by newer build bits (e.g. Cargo) without an appropriate versioned dependency; for instance, it'd be possible to say "you use the environment variable without a dependency on a version of Cargo that supplies . This would also help people doing reproducible builds to see what environment variables might affect a build. This will never be perfect; it can't capture variables read from native code or from code that goes out of its way to bypass the normal mechanism (e.g. calling .) However, this would still catch many common cases.
Just following up to say that this is an accurate reflection of what we discussed. As said, it's part of a larger goal to detect usage of newer Cargo features on older versions of Cargo and let the user know which version of Cargo they need to upgrade to. For keys in , it's enough to simply keep a list of when a particular key was (since Cargo is the one parsing ). But if Cargo adds an environment variable, we need some compiler help to detect that the environment variable was used from Rust code.
I believe this may be a dupe of
They're related, though I think seems more narrow in scope.
Change:
module_trait_cache: RefCell::new(FxHashMap::default()), cache: Cache::default(), }; <ins> // Small hack to force the Sized trait to be present. // // Note that in case of `#![no_core]`, the trait is not available. if let Some(sized_trait_did) = ctxt.tcx.lang_items().sized_trait() { let mut sized_trait = build_external_trait(&mut ctxt, sized_trait_did); sized_trait.is_auto = true; ctxt.external_traits.borrow_mut().insert(sized_trait_did, sized_trait); } </ins> debug!("crate: {:?}", tcx.hir().krate()); let mut krate = tcx.sess.time("clean_crate", || clean::krate(&mut ctxt));

Discussion:
For example  should have a bound, but we're a little too aggressive about pruning out the bounds. For comparison  does indeed have the bound. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
This also applies to bounds on traits.
This prompted a question on IRC about whether requires , because the bound is not visible in the libstd documentation. It is visible in the libcore docs though.
Triage: This still happens
This actually ended up biting me today, is there a plan to handle this? I could help implement if I get pointers
did not fix this - it now shows , which is nice, but it doesn't show bounds on traits. For traits it does matter because the default is .
I would start by finding out why this is different between local crates and cross-crate re-exports. I expect is behaving differently from .
Ah, I also hit this today when looking at . Kudos to whoever can figure this one out :)
claim
Change:
Component::UnresolvedInferenceVariable(_) => None, <del> Component::Projection(_) | Component::EscapingProjection(_) => { // We can probably do more here. This // corresponds to a case like `<T as // Foo<'a>>::U: 'b`. </del> <ins> Component::Projection(projection) => { // We might end up here if we have `Foo<<Bar as Baz>::Assoc>: 'a`. // With this, we can deduce that `<Bar as Baz>::Assoc: 'a`. let ty = tcx.mk_projection(projection.item_def_id, projection.substs); Some(ty::PredicateKind::TypeOutlives(ty::OutlivesPredicate( ty, r_min, ))) } Component::EscapingProjection(_) => { // We might be able to do more here, but we don't // want to deal with escaping vars right now. </ins> None } })

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. --Within an , a GAT bound of does not compile, asking me to add an explicit bound. This code results in two errors: I believe that the error is a bug, as since is known in this to be , must outlive and the suggested bound should thus already be implied by . Applying the suggested fix removes this error, but obviously cannot compile (as the GAT impl now has a stricter than in the declaration). The first error seems incorrect too, as there is no visible difference between the highlighted lines other than : Adding the type bound on the declaration avoids these errors, but is less generic. <!-- 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 have also encountered this bug on . </details
label +F-genericassociatedtypes +T-compiler
It's both rude and unconstructive to suggest that issues are not tracked. First and foremost, this is an unstable feature. Second, this issue was filed 15 days ago, right in the middle of holidays. Third, its labeled appropriately, and I'll either triage or fix it when I can. I'm going to delete the above comment since it's not constructive at all.
I forgot what I said before, but if I said something bad, I'm really sorry for that
Change:
<del> Subproject commit d404cba4e39df595710869988ded7cbe1104b52f </del> <ins> Subproject commit febc39711a7c91560eb0f0980916ae23c343b99d </ins>

Discussion:
The tests have regressed on Fedora since upgrading to Rust 1.73.0, and I can also reproduce this on toolchains. I expected to see this happen: all tests pass Instead, this happened: it passes in debug mode, but fails multiple tests in . For example: It most recently worked on: 1.72.1 : It's no better on or . As noted above, it also fails on Fedora rawhide's Rust 1.73.0 with LLVM 17. However, it passes on Fedora 38 with Rust 1.73.0 and LLVM 16, so it definitely seems like a codegen regression in 17. modify labels: +A-LLVM +T-compiler +regression-from-stable-to-stable -regression-untriaged
Doesn't happen when calling with a zero argument instead, so probably something gets miscompiled when atms() is inlined into at() and specialized for 0.
opt-bisect points towards a backend issue: IR for the function looks like this:
The issue is already introduced during the SDAG layer by a custom combine: This is interchanging to , which is obviously incorrect and should be instead.
That case is new in 17, , so it would seem to be a true regression, not just something that we were lucky to miss before due to other perturbations.
Indeed, all tests pass with: This also passes all , including that original . I haven't tried to add or update a specific test for this problem yet.
Upstream issue:
WG-prioritization assigning priority (). label -I-prioritize +P-high
Change:
- [Targets](targets/index.md) - [Built-in Targets](targets/built-in.md) - [Custom Targets](targets/custom.md) <ins> - [Known Issues](targets/known-issues.md) </ins> - [Profile-guided Optimization](profile-guided-optimization.md) - [Linker-plugin based LTO](linker-plugin-lto.md) - [Contributing to `rustc`](contributing.md)

Discussion:
When discussing in the compiler team triage meeting, it became clear that target-features ought to be considered generally unsafe. We should document this fact in the and in the . Ideally, we'd also start listing out known gotchas. For example, in noted that: and had a . <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Compiler triage meeting: Marking as P-medium
claim
The reference section about mentions this: The link to the section of the reference mentions this as well: So maybe the could point people to the reference?
That is one way in which targetfeature is unsafe, but it's not the one which was the subject of so just pointing at the reference as it is is insufficient. Plus, it's also more about than (where the compiler will hit you in the face with ). So the rustc book is a better place for it than the reference IMO.
I think that for users to better properly understand the UB involved, it might be more educational to say that stamps on all functions, but with the subtle difference that it doesn't make them , so no unsafe-check happens when this triggers UB. The reference does not document all current perils of using . In particular, it does not document that these can change the function call ABI, and that rustc neither checks that nor handles it correctly - we just currently assume people don't do that. Independently of whether we document that in the rustc book as well or not, that bit should also probably be documented in the reference, because it is easy to trigger this. On stable Rust, I think one can indeed only trigger this via and the reference should say so, but on nightly one can definitely trigger this with bare within a single Rust crate.
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 struct Foo; mod bar { use Foo; impl Foo { //~ERROR inherent implementations are only allowed on types defined in the current module fn baz(&self) {} } } 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 struct Foo; mod bar { use Foo; impl Foo { //~ERROR inherent implementations are only allowed on types defined in the current module fn baz(&self) {} } } 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:
fn print_else(&mut self, els: Option<&hir::Expr<'_>>) { match els { <del> Some(_else) => { match _else.kind { </del> <ins> Some(else_) => { match else_.kind { </ins> // "another else-if" hir::ExprKind::If(ref i, ref then, ref e) => { self.cbox(INDENT_UNIT - 1);

Discussion:
I got this error on my code even though it did not have any in it. Also, it seems to only happen on crates. Just a is enough to reproduce it. rust playground: The bug also happens on and versions of the compiler. : <!-- 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 --<!-- TRIAGEBOTEND --
Oh, I think it's worth noting that if the code is refatored as: The bug ceases to happen.
I think duplicated of ?
this one doesn't need nightly to trigger
The code in works for me
right, because it's a different problem and only triggers with .
The issue seems to be that the gets desugared to a , which is currently unexpected in an branch. claim