jiebi/CodeConvo huggingface dataset:
Change:
let mut callsites = VecDeque::new(); <del> let mut param_env = self.tcx.param_env(self.source.def_id()); let substs = &InternalSubsts::identity_for_item(self.tcx, self.source.def_id()); // For monomorphic functions, we can use `Reveal::All` to resolve specialized instances. if !substs.needs_subst() { param_env = param_env.with_reveal_all(); } </del> <ins> let param_env = self.tcx.param_env(self.source.def_id()).with_reveal_all(); </ins> // Only do inlining into fn bodies. let id = self.tcx.hir().as_local_hir_id(self.source.def_id()).unwrap();

Discussion:
The assembly generated in debug builds (-C opt-level=0) worsened for this code that uses an associated constant from a trait.This seems to be caused by the fact that the function is generic,even though the associated constant doesn't depend on the generic parameters of the function. The code: The entirety of the generated assembly for stable 1.41.0 in a debug build: The assembly generated for the same functions by rustc 1.42.0-beta.2 (2020-02-04 ) in a debug build:
out of curiosity, what prompted you to investigate this specific code sequence? (I'm trying to evaluate the severity of this code-quality regression, and it might help for me to get some idea of how wide-spread the problem might be. There are obviously a couple different features interacting in the example you have provided...)
triage: leaving unprioritized. Nominating for discussion at today's T-compiler triage meeting.
I was experimenting to figure out the best design for a feature I want to add to eventually,being efficient in debug builds is a plus(but not a hard requirement for me). The reason I reported this is that if it optimizes fine in non-generic functions,it should also do the same optimization in generic functions(so long as the constant doesn't depend on generic parameters).
How does LLVM even generate such a code sequence? Well...: Okay so I guess LLVM doesn't even simplify the CFG when optimizations are off? <hr/Anyway, the MIR differs. This is a constant folding regression. cc
I'm guessing this is caused by We're in a generic context and resolve has to be conservative so it doesn't accidentally try to inline a default value if it could get a different value in an impl. In this situation that can't happen, but I don't know how to coax resolve to know this.
The fix was already implemented though! already returns in the problematic cases. Users of don't need to special-case anything anymore. Nor do we ever need to use just because something might be polymorphic, because the fix is in already, as it has been in for associated types. I left comments here:
T-compiler triage: P-medium. Leaving nomination tag on until we actually assign this to someone.
Change:
use crate::sys::cvt; use crate::sys::fd; use crate::sys_common::mutex::{StaticMutex, StaticMutexGuard}; <del> use crate::sys_common::rwlock::{RWLockReadGuard, StaticRWLock}; </del> use crate::vec; use libc::{c_char, c_int, c_void};

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:
You’ll note three things: we need to add our own `extern crate` line, so that we can add the `#[macro_use]` attribute. Second, we’ll need to add our own <del> `main()` as well. Finally, a judicious use of `#` to comment out those two things, so they don’t show up in the output. </del> <ins> `main()` as well (for reasons discussed above). Finally, a judicious use of `#` to comment out those two things, so they don’t show up in the output. </ins> Another case where the use of `#` is handy is when you want to ignore error handling. Lets say you want the following,

Discussion:
When a doctest like this is written: /// /// running the tests will produce an error like: since the test code is wrapped inside a for execution. This is imho not clear in this algorithm description
This seems like a bug somewhere in rustc/cargo, rather than a problem with the docs, because rust /// works fine, but (as was mentioned here) rust /// does not. This seems like wrong behaviour. Also, the suggested rust /// does not work either, I don't know if there is an RFC or issue open about attempting to resolve the names suggested under ... and only showing them if they exist. EDIT: as mentioned below, this is not a bug with rustc or cargo, it's just that there is no way to refer to the current function scope in a use statement if you import a crate into it.
it's not wrong but it is very misleading. The key is that if does not appear in the doc test, then rustdoc encloses the entire test in a main function. This, coupled with the fact that does not really work inside a function, produces the bad situation in which we find ourselves.
Right, it's the 'entire' part that's confusing. I myself find it to be so and I wrote the sentence!
It would be nice if rustdoc used similar heuristics to playbot, where stuff like extern crates and crate attributes get hoisted out of the generated main function.
Why is extern crate even allowed inside of functions? That seems like a horrible misfeature.
It's similar to anything else that brings a name into scope, you can do it in whatever scope you'd like.
I guess the "real" problem is that has no way to refer to a function/expression scope. doesn't work, making the "did you mean" note less than helpful.
Change:
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ error: cannot specialize on trait `Clone` <del> --> $DIR/specialization_trait.rs:21:1 </del> <ins> --> $DIR/specialization_trait.rs:21:9 </ins> | LL | impl<T: Clone> SpecMarker for [T] { <del> | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ </del> <ins> |         ^^^^^ </ins> error: aborting due to 3 previous errors

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: <!-- Please provide a link to -- The current output is: <!-- The following is not always necessary. --Ideally the output should not reference the debug format of an internal type <!-- If the problem is not self-explanatory, please provide a rationale for the change. --<!-- 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. -- modify labels +F-specialization +A-specialization +requires-nightly
Change:
let output = Command::new(pager) // disable paging; we want this to be non-interactive .env("PAGER", "") <del> .stdin(diff_pid.stdout.unwrap()) </del> <ins> .stdin(File::open(&diff_filename).unwrap()) </ins> // Capture output and print it explicitly so it will in turn be // captured by libtest. .output() .unwrap(); assert!(output.status.success()); <del> output </del> <ins> println!("{}", String::from_utf8_lossy(&output.stdout)); eprintln!("{}", String::from_utf8_lossy(&output.stderr)); </ins> } else { <del> eprintln!("warning: no pager configured, falling back to `diff --color`"); </del> <ins> use colored::Colorize; eprintln!("warning: no pager configured, falling back to unified diff"); </ins> eprintln!( "help: try configuring a git pager (e.g. `delta`) with `git config --global core.pager delta`" ); <del> let output = diff.arg("--color").output().unwrap(); assert!(output.status.success() || output.status.code() == Some(1)); output </del> <ins> let mut out = io::stdout(); let mut diff = BufReader::new(File::open(&diff_filename).unwrap()); let mut line = Vec::new(); loop { line.truncate(0); match diff.read_until(b'n', &mut line) { Ok(0) => break, Ok(_) => {} Err(e) => eprintln!("ERROR: {:?}", e), } match String::from_utf8(line.clone()) { Ok(line) => { if line.starts_with("+") { write!(&mut out, "{}", line.green()).unwrap(); } else if line.starts_with("-") { write!(&mut out, "{}", line.red()).unwrap(); } else if line.starts_with("@") { write!(&mut out, "{}", line.blue()).unwrap(); } else { out.write_all(line.as_bytes()).unwrap(); } } Err(_) => { write!(&mut out, "{}", String::from_utf8_lossy(&line).reversed()).unwrap(); } } } </ins> }; <del> println!("{}", String::from_utf8_lossy(&output.stdout)); eprintln!("{}", String::from_utf8_lossy(&output.stderr)); </del> } fn run_rustdoc_json_test(&self) {

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:
return Err(err); } <del> let sm = self.sess.source_map(); </del> if self.prev_token.span == DUMMY_SP { // Account for macro context where the previous span might not be // available to avoid incorrect output (#54841).

Discussion:
: The current output is: We should detect cases where a semicolon would be appropriate (probe that the current token and maybe limited lookahead confirm that what comes next could be a valid statement on its own) and suggest a semicolon. . We might want to silence one or the other depending on whether the current token might be starting a statement or an item ( vs , etc.). <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Sorry, I don't have much time these days. release-assignment
Just a guess: could this be addressed with another block, as in
I think we would need to answer this question: why is the logic here not handling the cases we want to handle?
This seems to be on track given the clue "probe that the current token and maybe limited lookahead confirm that what comes next could be a valid statement on its own"...
claim
release-assignment
That is a great question: as the code is written it looks like it should work. I don't know why it isn't triggering :( It might be that isn't being called in these case. It might be a good idea to uplift most of this method into
I'd like to give this a try. claim
Change:
<ins> mod foo { pub struct Pub { private: () } pub enum Enum { Variant { x: (), y: () }, Other } fn correct() { Pub {}; //~^ ERROR missing field `private` in initializer of `Pub` Enum::Variant { x: () }; //~^ ERROR missing field `y` in initializer of `Enum` } } fn correct() { foo::Pub {}; //~^ ERROR cannot construct `Pub` with struct literal syntax due to inaccessible fields } fn wrong() { foo::Enum::Variant { x: () }; //~^ ERROR missing field `y` in initializer of `Enum` foo::Enum::Variant { }; //~^ ERROR missing fields `x`, `y` in initializer of `Enum` } fn main() {} </ins>

Discussion:
Test example (): Only in the top level should say "cannot construct ... due to inaccessible fields", the other 3 errors should be "missing field ... in initializer", but it seems like it's treating the field as private (even though it inherits from the ). The "cannot construct ... due to inaccessible fields" error seems to be new in 1.48, as part of , and unmodified since. It's using which seems correct, but it's possible fields are incapable of giving the right result, if they don't track the 's own privacy (and they only know they inherit it, whatever it is). cc
I would also suspect
I ran into this too, but I couldn't make a repro. Thanks eddyb!
P-high: I've run into this a bunch of times and I imagine others have too. It's really annoying and confusing, likely even more so for newcomers!
searched nightlies: from nightly-2020-08-01 to nightly-2020-10-15 regressed nightly: nightly-2020-09-11 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.0</summaryHost triple: x86_64-apple-darwin Reproduce with: </details
Seems very likely that this is due to , as eddyb said. EDIT: Though, as jyn514 suggested, the underlying bug could be , which was then surfaced in .
Update: I've been reading the source code and print-debugging and I think the issue was not introduced in either of those two PRs, but rather that they surfaced a pre-existing issue.
Well, it took a while, but I think I fixed it!
Does this necessitate a 1.48.1 release or shall I wait for 1.49?
it will be in 1.50 unless backported:
Ok. Thank you for the quick reply.
Change:
} } <ins> #[cfg(not(test))] impl<T, I: Int> Add<I, *T> for *T { /// Add an integer value to a pointer to get an offset pointer. /// Is calculated according to the size of the type pointed to. #[inline] pub fn add(&self, rhs: &I) -> *T { self.offset(rhs.to_int() as uint) } } #[cfg(not(test))] impl<T, I: Int> Sub<I, *T> for *T { /// Subtract an integer value from a pointer to get an offset pointer. /// Is calculated according to the size of the type pointed to. #[inline] pub fn sub(&self, rhs: &I) -> *T { self.offset(-rhs.to_int() as uint) } } #[cfg(not(test))] impl<T, I: Int> Add<I, *mut T> for *mut T { /// Add an integer value to a pointer to get an offset pointer. /// Is calculated according to the size of the type pointed to. #[inline] pub fn add(&self, rhs: &I) -> *mut T { self.offset(rhs.to_int() as uint) } } #[cfg(not(test))] impl<T, I: Int> Sub<I, *mut T> for *mut T { /// Subtract an integer value from a pointer to get an offset pointer. /// Is calculated according to the size of the type pointed to. #[inline] pub fn sub(&self, rhs: &I) -> *mut T { self.offset(-rhs.to_int() as uint) } } </ins> #[cfg(test)] pub mod ptr_tests { use super::*;

Discussion:
This seems like an obvious use case for operator overloading. Probably export them from core by default.
What operators did you have in mind? Things like for ?
yes, and
Not going to work right now, because operators can't be unsafe. Not sure how to change that either. Going to close for now.
At least for , the operator could be "safe" with an unsafe block inside of it. You aren't going to have problems if you do pointer arithmetic until you dereference it, which would be unsafe anyway. In other words, if is safe (which is is), then it seems like pointer arithmetic is also safe.
Yeah, that's true. We consider arithmetic safe, but indexing and dereferencing unsafe. Just having would be convenient.
I'm going to try on work on this. I'll add overloaded and . I'll use as dbaupp suggested on IRC so that it will work with any primitive integer type.
Looks like and for unsafe pointers, can this be closed?
Change:
<ins> // check-fail #![feature(generic_const_exprs, transmutability)] #![allow(incomplete_features)] mod assert { use std::mem::{Assume, BikeshedIntrinsicFrom}; pub fn is_transmutable< Src, Dst, Context, const ASSUME_ALIGNMENT: bool, const ASSUME_LIFETIMES: bool, const ASSUME_SAFETY: bool, const ASSUME_VALIDITY: bool, >() where Dst: BikeshedIntrinsicFrom< Src, Context, { from_options(ASSUME_ALIGNMENT, ASSUME_LIFETIMES, ASSUME_SAFETY, ASSUME_VALIDITY) } >, {} // This should not cause an ICE const fn from_options( , //~ ERROR expected parameter name, found `,` , //~ ERROR expected parameter name, found `,` , //~ ERROR expected parameter name, found `,` , //~ ERROR expected parameter name, found `,` ) -> Assume {} //~ ERROR mismatched types } fn main() { struct Context; #[repr(C)] struct Src; #[repr(C)] struct Dst; assert::is_transmutable::<Src, Dst, Context, false, false, { true }, false>(); } </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<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
It's coming from calling at this line: I can take a look at it later, doesn't seem to be related to recent changes. Nice find. We're mistakenly assuming that the const has always already been evaluated by the time is called. claim
This one also seems to be regressing in :thinking: cc
Change:
}) .collect::<Vec<_>>() }) <del> .chain([Cfg::Cfg(sym::test, None)].into_iter()) </del> <ins> .chain( [Cfg::Cfg(sym::test, None), Cfg::Cfg(sym::doc, None), Cfg::Cfg(sym::doctest, None)] .into_iter(), ) </ins> .collect(); self.cx.cache.exact_paths = self.exact_paths;

Discussion:
Context: CC
Thanks for opening this issue! Someone from the rustdoc team will try to get back to it whenever possible.
It doesn't look too difficult. I'm going to try to make a PR for it myself, and I'll update here with or without progress.
Even better! :smile: I'll assign you to the issue in the meantime then.
Change:
} } <ins> pub fn with_capacity(nodes: usize, edges: usize) -> Graph<N, E> { Graph { nodes: SnapshotVec::with_capacity(nodes), edges: SnapshotVec::with_capacity(edges), } } </ins> // # Simple accessors #[inline]

Discussion:
This is an 8% regression with incremental enabled, 1% without it.
Interestingly if you you'll see: An 8% regression due to A 4% improvement due to A 7% improvement due to A 7% regression due to May be worth looking into as well?
Specifically before/after , -- I've only included the peak snapshot in the output there.
Looks like basically all of the memory , aka we have a bigger dep graph. Turns out adding more queries makes a bigger dep graph :)
I cashed in some easy savings in , but it doesn't actually fix the "regression", but we likely shouldn't call it a regression as it also fixed a number of would-be bugs!
Looks like we've and this particular peak may also , so closing.
Change:
} } <del> /// Moves all the elements of `other` into `Self`, leaving `other` empty. </del> <ins> /// Moves all the elements of `other` into `self`, leaving `other` empty. </ins> /// /// # Panics ///

Discussion:
See the documentation for here and for here: In both cases, the documentation refers to the object the method is called for, not the type, so it should be using the lower case . (And maybe should be in backticks here?) <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
label +A-docs +T-libs +E-easy
claim
Change:
/// ); /// ``` #[unstable(feature = "build_hasher_simple_hash_one", issue = "86161")] <del> fn hash_one<T: Hash>(&self, x: T) -> u64 { </del> <ins> fn hash_one<T: Hash>(&self, x: T) -> u64 where Self: Sized, { </ins> let mut hasher = self.build_hasher(); x.hash(&mut hasher); hasher.finish()

Discussion:
From 1.55 crater run , : a generic method to the trait, making it no longer object safe. This only caused one crate in crater to fail, and the source for that crate seems to have been removed from github. Still, I don't think this is technically allowed breakage. modify labels: +regression-from-stable-to-beta -regression-untriaged +T-libs +I-nominated cc
I think this just needs a on that method, no? Probably was just overlooked during review.
Change:
<ins> error[E0308]: mismatched types --> $DIR/issue-79518-default_trait_method_normalization.rs:16:32 | LL |         Self::AssocInstance == [(); std::mem::size_of::<Self::Assoc>()]; |                                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ expected associated type, found array `[(); _]` | = note: expected associated type `<Self as Foo>::Assoc` found array `[(); _]` = help: consider constraining the associated type `<Self as Foo>::Assoc` to `[(); _]` or calling a method that returns `<Self as Foo>::Assoc` = note: for more information, visit https://doc.rust-lang.org/book/ch19-03-advanced-traits.html error: aborting due to previous error For more information about this error, try `rustc --explain E0308`. </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<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
It doesn't fixed in rustc 1.52.0-nightly ( 2021-02-14) link to playground : <details<summary<strongBacktrace</strong</summary<p</p</details
i dont think the fix was merged by then. it works in 1.52.0-nightly 2021-02-16 :)

<!-- 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</detailsI think I'm an ICE magnet; this is my fourth one.
I'd like to note that it only ICEs with the wrong return type. The following does not ICE