jiebi/CodeConvo huggingface dataset:
Change:
fn boo(&self) -> <Self as Foo>::A; } <del> struct Bar; </del> <ins> pub struct Bar; </ins> impl Foo for char { type A = Bar;

Discussion:
AFAIK, you can't put private types in "public" items (public as in marked with ). is not explicitly marked with , but for all intent and purposes all the methods in a trait are public if the trait is public. So, I think the should be rejected by the privacy checker. (Or, I could be wrong and this is "correct" behavior - and this wouldn't be the first time that the privacy/module system allows things that I find ) cc
I agree, I think this may have just been accidentally overlooked when implementing associated types.
On Sat, Feb 28, 2015 at 10:59:14PM -0800, Alex Crichton wrote: Yes, that. There was language in the RFC describing trait item signatures and how they should be treated, and I think we just failed to extend that to associated types. Definitely a bug.
triage: P-backcompat-lang (1.0 beta)
Note also that is still open.
Change:
... LL |         _ => { empty!() } |                ^^^^^^^^ expected expression <ins> | = note: the macro call doesn't expand to an expression, but it can expand to a statement help: add `;` to interpret the expansion as a statement | LL |         _ => { empty!(); } |                        ^ </ins> error: aborting due to previous error

Discussion:
This is a regression from stable to beta and nightly. This code is wrong (missing semicolons): Stable prints: Beta and nightly both print: Notice that not only is all the useful information gone, but the compiler aborts after the first error instead of finding the rest. It does not matter whether is on or off. cc
cc me
So this fell through the cracks, and was a stable to nightly/beta regression. It still is a regression, in a way, but only of diagnostics. Could you take a look?
Nominating for prioritization.
So this part of the (previous) stable message: feels like a bug to me anyhow. This part: is sort of good. It'd be nice to preserve a backtrace, at least. And ideally we'd suggest adding a .
Given how much time has past, we're going to call this P-medium for now. However, will try to write up some mentoring instructions (or maybe fix it). He has a plan. =) triage: P-medium
I think the best path forward here is to try parsing an expression macro expansion as a statement before emitting an error. If the macro expansion parses as a statement successfully, we can emit a more helpful error suggesting that the user add a semicolon to the macro invocation.
I'm interested in this but I need informations to understand what to do :)
Current output:
Diagnostics meeting triage: lowering priority as the current error is pretty good, even if not ideal yet.
Current output: (Notice that we recover -- it's not a fatal error now.)
Change:
} fn name_key(name: &str) -> (&str, u64, usize) { <ins> let end = name.bytes() .rposition(|b| b.is_ascii_digit()).map_or(name.len(), |i| i + 1); </ins> // find number at end <del> let split = name.bytes().rposition(|b| b < b'0' || b'9' < b).map_or(0, |s| s + 1); </del> <ins> let split = name[0..end].bytes() .rposition(|b| !b.is_ascii_digit()).map_or(0, |i| i + 1); </ins> // count leading zeroes let after_zeroes = <del> name[split..].bytes().position(|b| b != b'0').map_or(name.len(), |extra| split + extra); </del> <ins> name[split..end].bytes().position(|b| b != b'0').map_or(name.len(), |extra| split + extra); </ins> // sort leading zeroes last let num_zeroes = after_zeroes - split; <del> match name[split..].parse() { </del> <ins> match name[split..end].parse() { </ins> Ok(n) => (&name[..split], n, num_zeroes), Err(_) => (name, 0, num_zeroes), }

Discussion:
impl<'a, TIntoIterator for &'a mut [T; 12] impl<'a, TIntoIterator for &'a [T; 25] impl<'a, TIntoIterator for &'a mut [T; 21] impl<'a, TIntoIterator for &'a [T; 2] ... this ordering doesn't make any sense and makes the docs harder to navigate.
It has been fixed on nightly. The fix will come to stable eventually.
Change:
or_patterns, other, out, <ins> overflow_checks, </ins> overlapping_marker_traits, owned_box, packed,

Discussion:
An enhancement request discussed here: (That thread also contains a hacky solution by Yandros). I propose to add a config like this: #[cfg(overflow_checks)] I would like to use it to enable/disable lines of code that perform safe unsafe "as" casts replacing them with casts when I compile with debug builds or with release builds compiled with "-C overflow-checks".
modify labels: C-enhancement
label A-attributes T-compiler
I’d also be interested in this.
Tracking issue:
Change:
Some(ref filters) => filters, }; let node_id = source.item_id(); <del> let node_path = tcx.item_path_str(tcx.hir.local_def_id(node_id)); </del> <ins> let node_path = item_path::with_forced_impl_filename_line(|| { // see notes on #41697 below tcx.item_path_str(tcx.hir.local_def_id(node_id)) }); </ins> filters.split("&") .any(|filter| { filter == "all" ||

Discussion:
running yields Happening on . Did not happen on the latest nightly available through rustup on 27.04.2017.
Last working nightly: First broken nightly: .
maybe it was ? cc
could be. let me try it on my big MIR refactoring branch =)
I confirm that the error occurs at but not at So it looks to me like is indeed the culprit.
Yes. I can reproduce. Will investigate.
I see the problem. PR coming soon.
Fix at
I'm still seeing this issue, on the latest nightly and on master.
can you give more details of how you are reproducing the problem? (I a test for the precise scenario reported, so I'm reasonably sure it's not that case anymore.)
Hmm, perhaps my regression test wasn't sufficient. I see I used ; I remember that the test did fail, but I guess that it passing doesn't prove all issues are resolved. =)
The earliest commit where I can reproduce this problem is
Change:
pub mod intrinsics; #[path = "unstable/extfmt.rs"] pub mod extfmt; <ins> #[path = "unstable/lang.rs"] #[cfg(notest)] pub mod lang; </ins> extern mod rustrt { pub unsafe fn rust_create_little_lock() -> rust_little_lock;

Discussion:
This is a public module of things that are exported by core but should not be considered part of the stable library interface. Some don't like the name, and indeed it's name is the opposite of it's form. What should it be renamed to?
Internal, implspecific, dontusethis, unstable, changeable, corehacks?
back?
I like "unstable"; can imagine the future bug report about it changing unexpectedly...
'unstable' sounds good to me to.
Change:
fn insert(&mut self, tcx: TyCtxt<'_>, fi: &hir::ForeignItem<'_>) -> Option<HirId> { let hid = fi.hir_id; <del> let name = &tcx.codegen_fn_attrs(tcx.hir().local_def_id(hid)).link_name.unwrap_or(fi.ident.name); if self.seen_decls.contains_key(name) { </del> <ins> let local_did = tcx.hir().local_def_id(fi.hir_id); let did = local_did.to_def_id(); let instance = Instance::new(did, ty::List::identity_for_item(tcx, did)); let name = tcx.symbol_name(instance).name; if let Some(&hir_id) = self.seen_decls.get(name) { </ins> // Avoid updating the map with the new entry when we do find a collision. We want to // make sure we're always pointing to the first definition as the previous declaration. // This lets us avoid emitting "knock-on" diagnostics. <del> Some(*self.seen_decls.get(name).unwrap()) </del> <ins> Some(hir_id) </ins> } else { <del> self.seen_decls.insert(*name, hid) </del> <ins> self.seen_decls.insert(name.to_owned(), hid) </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. --Rustc 1.48.0 gives an incorrect warning about an external symbol being redeclared with a different signature, when the external symbols are in different namespaces. I tried this code: I expected to see this happen: Compile without warnings Instead, this happened: <!-- 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 same behavior exists on nightly as well: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summaryBacktrace</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
cc
cc would you be willing to help take a look at this? (it looks like you this way-back-when in ) On wasm targets there's which is why this should work but not actually generate a warning. Do you know if it's possible to call that logic perhaps? (would be able to consolidate "what's the name of this symbol" logic too!)
Sure thing! I'm currently in the process of moving, but will be able to get onto this on the weekend :) claim
No worries, and thanks! If you run out of time/steam I'm happy to look into this as well
Change:
<ins> #[prelude_import] use ::std::prelude::rust_2015::*; #[macro_use] extern crate std; // Test to print lifetimes on HIR pretty-printing. // pretty-compare-only // pretty-mode:hir // pp-exact:issue-85089.pp trait A<'x> { } trait B<'x> { } struct Foo<'b> { bar: &'b dyn for<'a> A<'a>, } impl <'a> B<'a> for dyn for<'b> A<'b> { } impl <'a> A<'a> for Foo<'a> { } </ins>

Discussion:
(From the Playground.) Note that the uses of , , and don't include their lifetimes. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Change:
"prim" | "primitive" => Primitive, _ => return Err((format!("unknown disambiguator `{}`", prefix), 0..idx)), }; <del> Ok(Some((d, &rest[1..]))) </del> <ins> Ok(Some((d, &rest[1..], &rest[1..]))) </ins> } else { let suffixes = [ ("!()", DefKind::Macro(MacroKind::Bang)), <ins> ("!{}", DefKind::Macro(MacroKind::Bang)), ("![]", DefKind::Macro(MacroKind::Bang)), </ins> ("()", DefKind::Fn), ("!", DefKind::Macro(MacroKind::Bang)), ]; for (suffix, kind) in suffixes { <del> if let Some(link) = link.strip_suffix(suffix) { </del> <ins> if let Some(path_str) = link.strip_suffix(suffix) { </ins> // Avoid turning `!` or `()` into an empty string <del> if !link.is_empty() { return Ok(Some((Kind(kind), link))); </del> <ins> if !path_str.is_empty() { return Ok(Some((Kind(kind), path_str, link))); </ins> } } }

Discussion:
Consider this code: I'm not sure if this is a deliberate decision or not. If it is, what's the rationale for not accepting and ? cc
It isn't valid markdown syntax.
Well, might be. But [] definitely is not.
seems to work fine (it renders as and the link is correct). But maybe you're saying that we shouldn't accept because it wouldn't be valid markdown? Is it worth implementing?
hmm, it might be valid in that position, but it's not valid as a link reference: But I guess there's no reason for rustdoc to explicitly reject it. I would be ok with it, may have opinions.
I'm okay with it. I'm mostly wary about characters that are common in URLs, curly braces are not.
Oh, the reason why works is because the rules for inline links are more relaxed: vs So instead do you think rustdoc should parse ?

Consider this code: In the generated docs, the link on the page appears as , with the correct link, but without the parentheses.
Sorry, I stole this from you :smile:
That's okay! Thanks for fixing this :)
Change:
// Similar to when forking, we want to ensure that access to // the environment is synchronized, so make sure to grab the // environment lock before we try to exec. <del> let _lock = sys::os::env_read_lock(); </del> <ins> let _lock = sys::os::env_lock(); </ins> let Err(e) = self.do_exec(theirs, envp.as_ref()); e

Discussion:
For example: i686-gnu, i686-gnu, i686-gnu-nopt, i686-gnu-nopt, i686-gnu, i686-gnu-nopt, i686-gnu, i686-gnu-nopt i686-gnu, i686-gnu, i686-gnu, x8664-gnu-distcheck, i686-gnu-nopt, x8664-gnu-tools, i686-gnu, i686-gnu-nopt, i686-gnu-nopt,
Posted a fix at .
Change:
{ cmd.arg("-C").arg("panic=abort"); } <ins> // `-Ztls-model=initial-exec` must not be applied to proc-macros, see // issue https://github.com/rust-lang/rust/issues/100530 if env::var("RUSTC_TLS_MODEL_INITIAL_EXEC").is_ok() && arg("--crate-type") != Some("proc-macro") && !matches!(crate_name, Some("proc_macro2" | "quote" | "syn" | "synstructure")) { cmd.arg("-Ztls-model=initial-exec"); } </ins> } else { // FIXME(rust-lang/cargo#5754) we shouldn't be using special env vars // here, but rather Cargo should know what flags to pass rustc itself.

Discussion:
On , with a provided component: errors with: I'll try and see if I can reproduce it with to test suggestion:
Couldn't reproduce it with an , tried with also Does it have to be cross compiled from a different host?
Not sure what is necessary to reproduce it. In any case if you open a PR with the likely fix, I can run a try build on CI which you can then locally install to see if it fixes the issue.
Change:
/// /// ## On `packed` structs /// <del> /// It is currently impossible to create raw pointers to unaligned fields /// of a packed struct. /// </del> /// Attempting to create a raw pointer to an `unaligned` struct field with /// an expression such as `&packed.unaligned as *const FieldType` creates an /// intermediate unaligned reference before converting that to a raw pointer.

Discussion:
Rust 1.51 was released yesterday and included the  macro. Its documentation talks about its usage in creating pointers to unaligned fields without the need for an intermediate reference: Despite that, the documentation of [] states the following: The documentation of [] should be updated to reflect the new changes in the language. : and modify labels: T-doc claim []: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
Change:
use rustc_trait_selection::traits::{self, ObligationCauseCode, SelectionContext}; use std::iter; <ins> use std::mem; </ins> use std::ops::ControlFlow; use std::slice; impl<'a, 'tcx> FnCtxt<'a, 'tcx> { <del> pub(in super::super) fn check_casts(&self) { let mut deferred_cast_checks = self.deferred_cast_checks.borrow_mut(); </del> <ins> pub(in super::super) fn check_casts(&mut self) { // don't hold the borrow to deferred_cast_checks while checking to avoid borrow checker errors // when writing to `self.param_env`. let mut deferred_cast_checks = mem::take(&mut *self.deferred_cast_checks.borrow_mut()); </ins> debug!("FnCtxt::check_casts: {} deferred checks", deferred_cast_checks.len()); for cast in deferred_cast_checks.drain(..) { <ins> let prev_env = self.param_env; self.param_env = self.param_env.with_constness(cast.constness); </ins> cast.check(self); <ins> self.param_env = prev_env; </ins> } <ins> *self.deferred_cast_checks.borrow_mut() = deferred_cast_checks; </ins> } pub(in super::super) fn check_transmutes(&self) {

Discussion:
Compiles in stable rust (1.64) as well as in beta. But in nightly, we get this compilation error: playground link: 64, and beta current nightly
searched nightlies: from nightly-2022-08-01 to nightly-2022-10-24 regressed nightly: nightly-2022-09-23 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.4</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
Seems like closures pick the constness of their parent when they should always be notconst
Change:
where E: PathError, { <del> #[cfg(windows)] </del> if !self.sync_only { // A possible future enhancement after more detailed profiling would // be to create the file sync so errors are reported eagerly. let sender = self.errors.clone().expect("can't write after closing"); <del> rayon::spawn(move || { </del> <ins> self.pool.execute(move || { </ins> fs::write(&path, contents).unwrap_or_else(|e| { sender.send(format!(""{}": {}", path.display(), e)).unwrap_or_else(|_| { panic!("failed to send error on "{}"", path.display())

Discussion:
As discovered by in rust-lang/cargo, a Cargo test is intermittently failing on Windows because a source file generated by Rustdoc is not being written before the process exits. The suspected issue is that Rustdoc spawns asynchronous writes here: However, Rustdoc never checks that the writes are completed. We should add a mechanism that prevents the process from exiting before these write tasks are completed. One possible solution: Add a field to . Increment at the start of , and decrement at the end of the spawned Rayon task. Add a method that spin-loops until is zero. (Alternatively: use a condition variable, and have notify the condvar when is decremented.) Either call explicitly in the end of the Rustdoc process, or add it as a implementation to . cc
Change:
<ins> // ignore-tidy-linelength #![deny(intra_doc_link_resolution_failure)] pub fn foo() { } pub mod foo {} // @has intra_doc_link_mod_ambiguity/struct.A.html '//a/@href' '../intra_doc_link_mod_ambiguity/foo/index.html' /// Module is [`module@foo`] pub struct A; // @has intra_doc_link_mod_ambiguity/struct.B.html '//a/@href' '../intra_doc_link_mod_ambiguity/fn.foo.html' /// Function is [`fn@foo`] pub struct B; </ins>

Discussion:
Starting with an ambiguous rustdoc correctly reports the ambiguity and suggests the possible resolutions: In this case I want to link to the module so let's update accepts this without warnings but the generated html file contains: I would expect [module to link to the module x, not the function x. Mentioning tracking issue:
Workaround: leverage rustc's name resolution instead of rustdoc's.
This is coming directly from , so I'm not sure how to fix it. Maybe has ideas? The issue is that currently we can only select between types, values, and macros, and modules count as all three so there's not a way to say 'only give me modules'.
I think eventually we should switch rustdoc to using . That would also But I have no idea how hard that would be.
Yeah I don't know either. I'm not sure how that overlap works in resolve. might? We could tweak the resolve resolution functions to force looking for modules.
I don't know much about name resolution, you want Only thing I know is that it should be possible to get a and then use whichever namespace you want from there at your discretion.
the problem is that modules seem to be special and exist in all namespaces but also overlap. Do you have an idea of how that works?
"Modules count as all three" sounds wrong? Modules live in the type namespace last I checked.
Oh! Maybe we should just switch modules to being a type then, I was under the impression they lvied in all namespaces
And yeah, seems like types cannot overlap with modules.
Wait I'm confused - I thought functions are in the type namespace? Are they values instead?
Functions are values
Change:
<ins> error[E0790]: cannot call associated function on trait without specifying the corresponding `impl` type --> $DIR/infer-var-for-self-param.rs:5:14 | LL |     let _ = (Default::default(),); |              ^^^^^^^^^^^^^^^^ cannot call associated function of trait | help: use a fully-qualified path to a specific available implementation | LL |     let _ = (</* self type */ as Default>::default(),); |              +++++++++++++++++++        + error: aborting due to previous error For more information about this error, try `rustc --explain E0790`. </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. --<!-- 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
cc
Thanks for the ping. It seems to be that here it's not always the parent which has , sometimes its on the as-is. I'm not entirely sure when we need the (IIRC it doesn't work for my test case if I don't add ).
Now if I stick to only using and not its parent, the line ICEs on my PR's test case because it can't find the param index for the . cc sorry for the ping, but do you know if here is special somehow? The debug path for my PR's test case seems to have another layer compared to this issue's ICE example, namely . I think this is why getting for my PR test case's parent worked but not for this ICE?
going to look into this, I think using is correct and the bug is somewhere else :sweat_smile:
Change:
<ins> // Copyright 2016 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. #![feature(rustc_attrs)] #![allow(dead_code)] mod foo { pub use self::bar::T; mod bar { pub trait T { fn f(&self) {} } impl T for () {} } } fn g() { use foo::T; ().f(); // Check that this does not trigger a privacy error } #[rustc_error] fn main() {} //~ ERROR compilation successful </ins>

Discussion:
This was working previously before . If this is an intended change, we should probably give the error where the re-export is defined and not on use of the trait.
I've noticed this too while compiling nphysics, I've narrowed it to The error is I'm using .
I'm facing the same problem for quite some time now (currently rustc 1.0.0-nightly ( 2015-01-20 23:03:09 +0000)). Is this a bug or is it intended behavior?
is this expected?
Just ran into this bug in my code, would love to see a fix for this!
Im also still running into this from time to time (rustc 1.3.0). I'd love to see it fixed or clarified whether this is intended or a bug.
I also have this with rustc nightly (from PPA: "~~wily")
I think this is a bug, actually. do you agree?
yes I realize I'm responding to a comment from Jan 28 :) a bit late, I know
this was "fixed" by but reverted by due to a regression. Personally, I think that the correct fix for the regression should be to make a privacy error, but as far as I can tell, it's not easy to implement this currently, and it's likely to cause further regressions. Trait privacy is hard :(
better late than never :heart:
yeah this looks like a bug to me, and I think is right in that is probably the right fix if we deal with , which I think is the cause of some other visibility/privacy bug around here...
This can be simplified even further to: Also an additional note, this only affects usage in the same crate. Other crates are able to use the re-exports fine.
Still a bug in 1.6 :cry:
+1
still a bug in cargo 0.8.0-nightly ( 2016-01-17)
For those who may fall on this issue, it can be bypassed by using the UFCS syntax: . For example becomes
Change:
<ins> // Test that we emit an error if we cannot properly infer a constant. // revisions: full min #![cfg_attr(full, feature(const_generics))] #![cfg_attr(full, allow(incomplete_features))] #![cfg_attr(min, feature(min_const_generics))] fn foo<const N: usize, const M: usize>() -> [u8; N] { todo!() } fn main() { // FIXME(const_generics): Currently this only suggests one const parameter, // but instead it should suggest to provide all parameters. let _: [u8; 17] = foo(); //~^ ERROR type annotations needed } </ins>

Discussion:
At the moment, we simply emit errors like: It would be good to suggest to the user how to fix this, like with uninferred type arguments.
cc
Stu over has picked this issue up.