jiebi/CodeConvo huggingface dataset:
Code change:
<ins> #![crate_name = "foo"] // @has 'foo/trait.Unsafe.html' // @has - '//*[@class="object-safety-info"]' 'This trait is not object safe.' // @has - '//*[@id="object-safety"]' 'Object Safety' pub trait Unsafe { fn foo() -> Self; } // @has 'foo/trait.Unsafe2.html' // @has - '//*[@class="object-safety-info"]' 'This trait is not object safe.' // @has - '//*[@id="object-safety"]' 'Object Safety' pub trait Unsafe2<T> { fn foo(i: T); } // @has 'foo/trait.Safe.html' // @!has - '//*[@class="object-safety-info"]' '' // @!has - '//*[@id="object-safety"]' '' pub trait Safe { fn foo(&self); } // @has 'foo/struct.Foo.html' // @!has - '//*[@class="object-safety-info"]' '' // @!has - '//*[@id="object-safety"]' '' pub struct Foo; </ins>

Related discussion:
text: My reasoning here is that conceptually, is somewhat like an implementor of the trait.
I don't think this is necessarily true, you can have a that doesn't implement . But putting the text under "implementors" seems as good a place as any
Just out of curiosity, how can I have a that doesn’t implement ?
I don't think that's actually true, I misremembered.
We have one on: Would anyone else like to weigh in? Good enough to proceed with implementation?
Any update on this? :)
I'm not sure if it's already been suggested, but what about only showing a note if the trait is not object-safe?
I like suggestion to only show when a trait is not object safe, since that's the more unusual condition. If we do that, it doesn't fit logically under "Implementors" anymore. If we proceed with only marking non-object-safe traits, here are a couple of ideas: Add a section after the top-doc, but before "Implementors", called "Object Safety", and put the text there. Add information to the documentation of any method that causes the trait to be not object-safe.
I think it’s still fine to mention under “Implementors” like “This trait is not object safe: doesn’t implement ”, but I also like the idea of the new section. I see this issue doesn’t have an assignee currently, can I claim this?
You can but since we didn't reach a consensus, any PR would hang around until we reach one.
Code change:
config.as_ref().cloned().unwrap_or_else(|| PathBuf::from(default)) } <del> fn prepare_dir(mut path: PathBuf) -> String { </del> <ins> fn prepare_dir(destdir_env: &Option<PathBuf>, mut path: PathBuf) -> String { </ins> // The DESTDIR environment variable is a standard way to install software in a subdirectory // while keeping the original directory structure, even if the prefix or other directories // contain absolute paths. // // More information on the environment variable is available here: // https://www.gnu.org/prep/standards/html_node/DESTDIR.html <del> if let Some(destdir) = env::var_os("DESTDIR").map(PathBuf::from) { // Sanity check for the user write access on DESTDIR assert!(is_dir_writable_for_user(&destdir), "User doesn't have write access on DESTDIR."); </del> <ins> if let Some(destdir) = destdir_env { </ins> let without_destdir = path.clone(); <del> path = destdir; </del> <ins> path = destdir.clone(); </ins> // Custom .join() which ignores disk roots. for part in without_destdir.components() { if let Component::Normal(s) = part {

Related discussion:
text: It is cc
for backport, the PR's responsible team (T-bootstrap) also needs to label it beta-accepted. Once it has both labels, the release team will handle the actual backport.
Code change:
<ins> trait Hello { fn example(val: ()); } struct Test1(i32); impl Hello for Test1 { fn example(&self, input: &i32) { //~^ ERROR `&self` declaration in the impl, but not in the trait *input = self.0; //~^ ERROR cannot assign to `*input`, which is behind a `&` reference } } fn main() {} </ins>

Related discussion:
text: <!-- [31mICE[0m: Rustc '' 'thread 'rustc' panicked at 'index out of bounds: the len is 1 but the index is 1'', 'thread 'rustc' panicked at 'index out of bounds: the len is 1 but the index is 1'' 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: [mirborrowck] borrow-checking [analysis] running analysis passes on this crate --
cc
label +D-diagnostic-infra -needs-triage
Code change:
<ins> error[E0308]: mismatched types --> $DIR/issue-46112.rs:19:21 | 19 | fn main() { test(Ok(())); } |                     ^^ |                     | |                     expected enum `std::option::Option`, found () |                     help: try using a variant of the expected type: `Some(())` | = note: expected type `std::option::Option<()>` found type `()` error: aborting due to previous error </ins>

Related discussion:
text: On nightly rustc (cargo) I get misleading expected type errors. If a crate has the same(?) type it is displayed instead of the std type. I tried this code: I expected to see this happen: (stable rust) Instead, this happened: (nightly) :
Confirming - broken on nightly (1.23), good on beta.
bisected across nightlys: bug was injected between and
Skimming output from , there are a number of different potential culprits. Rather than guess and "point fingers" right now, I'll just continue bisecting within that commit range.
This is recent enough that we should be able to run bisect-rust on it (cc
it is cc .
I'm a little surprised that this would be caused by that PR. I can push a revert but would like to first test locally to make sure that revert that PR will fix this.
I have misread 's statement. Your PR is not at fault, sorry. I'm doing another search further back to find the causing PR.
I tried it locally in the meantime and I can confirm it is not :)
Okay so the bug dates as far back as from September 2nd which is as close to the limit as I dare to go. So to the people in control, please, prolong the limit :).
suggests that the bug was introduced much more recently (11-08 to 11-09). Maybe the bisection script was wrong?
I should probably have read the original issue more closely :). sorry for pinging you! It seems to be cc
In particular, I have bisected it down to the commit: I have been trying to further dissect that commit to figure out why it causes the change we observe here. My current hypothesis (that I have not yet managed to confirm) is that it has to do with how we seed the hashmap's hashers with randomized state. (This commit changes our behavior in certain scenarios.) If this hypothesis is actually true, though, then I would think that this represents either a bug in hashmap itself, or a bug in how the compiler is using the hashmap...
Hmm. Its something more subtle than a hashmap-related bug.
Code change:
<ins> error[E0308]: mismatched types --> $DIR/issue-46112.rs:19:21 | 19 | fn main() { test(Ok(())); } |                     ^^ |                     | |                     expected enum `std::option::Option`, found () |                     help: try using a variant of the expected type: `Some(())` | = note: expected type `std::option::Option<()>` found type `()` error: aborting due to previous error </ins>

Related discussion:
text: In particular, I can reproduce the old behavior on master by just linking in the old crate into (in addtion to linking in the one from ; doing this requires changing the name of the old ), without making any actual calls into the old crate. That, to me, seems very strange. I'm now trying to reduce down the size of the crate that I am linking in (while still causing this delta in behavior).
triage: P-high
I still get a non std types in erros when the path has the same length. That would be okay if it is somehow deterministic, but I get different type errors within the same file for the same types.
is that a regression from the stable channel? While I absolutely agree that a deterministic result would be better (and better stilll, a deterministic result that favored minimal-length paths rooted at ), I want to triage this appropriately.
Hmm I guess since is the person who filed the original ticket then it is reasonable to infer that they are indeed seeing the described regression compared to the stable channel.
gives me: seems to work now: Maybe this was some sort of partial compile cache issue? I haven't found a way to reproduce these mixed errors yet.
This looks like a duplicate of . That issue has some repro cases that affect the 1.22.1 stable compiler but not 1.21.0.
When I bisected the nightlies by hand on I ended up with a range (...) that does not include the commit identified here. Is it possible that the nondeterministic nature of the bug is also messing with our attempts to bisect? I wonder whether merely linking affects in the same way as it affected this issue.
Any evidence of this problem existing with the newest nightly?
All the cases I tried seem to have been fixed by and . Nicely done! I reported one follow-up in .
Code change:
options: TargetOptions { // Info about features at https://wiki.debian.org/ArmHardFloatPort <del> features: "+v7,+vfp3,+d16,+thumb2".to_string(), </del> <ins> features: "+v7,+vfp3,+d16,+thumb2,-neon".to_string(), </ins> cpu: "generic".to_string(), max_atomic_width: 64, .. base

Related discussion:
text: I was just investigating a that Fedora's rust binaries for armv7hl use NEON, but they should not per , supposedly fixed in . (Fedora's build is 1.11, but I applied that patch.) I can see the exact same issue in the latest official , whose version file says . In particular, they flagged that as a problem. I'm no ARM expert, but from it appears the registers are NEON-only. I believe those instructions using are also a problem, because with VFP3-D16 we should only have to .
Hm looks like it's definitely still there:
( TIL of ! :open_mouth: )
Just to confirm: No . This doesn't explicitly mention vs. though. I ran on all binaries in . I see no mention of NEON registers. I see uses of -, but no higher, so I think is OK too. I'll know better if someone with a limited armv7 actually tries to run this, but LGTM!
Thanks for the confirmation
Code change:
OverloadedOperator, ClosureInvocation, ForLoop, <ins> MatchDiscriminant </ins> } #[deriving(PartialEq,Show)]

Related discussion:
text: Sorry for not providing smaller case but I hope this is better than nothing: Both versions works (compile and start), but runtime behavior changes. The code that follows the above part: will match no matter what really is, if the value is partially moved (so mouse events are updating my game). If I use the version with , the code works as intended and game is updated only on keyboard presses.
Minimal: This shouldn't compile at all.
Nominating.
Looks like a regression. 0.10 rejects this code.
Code change:
key!(limit_rdylib_exports, bool); key!(override_export_symbols, opt_list); key!(merge_functions, MergeFunctions)?; <del> key!(mcount = "target_mcount"); </del> <ins> key!(mcount = "target-mcount"); </ins> key!(llvm_abiname); key!(relax_elf_relocations, bool); key!(llvm_args, list);

Related discussion:
text: Hello everyone, this is my first Issue on the Rust project, let me know if I'm doing anthing wrong ! I am in the process of building a library/runtime for the Wii fully written in Rust. To acheive this goal, I need to cross-compile my library to a custom target I named . The json file contains and along other lines to define the architecture. Normally, the build completes without an issue. On the latest nighlty, the compiler fails and return: Of course, is set to in the file, so this shouldn't happen. It most recently worked on: : It fails on this nightly, currently latest at the time of writing: : I can provide any file or other precision if necessary ! Thanks for reading my report !
I was also having the some issue and tracked it to this: That commit broke the equivalence between "target_endian" and "target-endian" by adding a case to the macro without the replace line for it.
cc
I'll fix this today.
Fixed in
I hope this gets merged asap :-)
(Reopening because isn't merged yet.)
Code change:
id: fld.new_id(a.id), } } //used in noop_fold_expr, and possibly elsewhere in the future fn fold_mac_(m: &mac, fld: @ast_fold) -> mac { spanned { <del> node: match m.node { mac_invoc_tt(*) => copy m.node }, span: fld.new_span(m.span), </del> <ins> node: match m.node { mac_invoc_tt(p,ref tts) => mac_invoc_tt(fld.fold_path(p), fold_tts(*tts,fld)) }, span: fld.new_span(m.span) } } fn fold_tts(tts : &[token_tree], fld: @ast_fold) -> ~[token_tree] { do tts.map |tt| { match *tt { tt_tok(span, ref tok) => tt_tok(span,maybe_fold_ident(tok,fld)), tt_delim(ref tts) => tt_delim(fold_tts(*tts,fld)), tt_seq(span, ref pattern, ref sep, is_optional) => tt_seq(span, fold_tts(*pattern,fld), sep.map(|tok|maybe_fold_ident(tok,fld)), is_optional), tt_nonterminal(sp,ref ident) => tt_nonterminal(sp,fld.fold_ident(*ident)) } } } // apply ident folder if it's an ident, otherwise leave it alone fn maybe_fold_ident(t : &token::Token, fld: @ast_fold) -> token::Token { match *t { token::IDENT(id,followed_by_colons) => token::IDENT(fld.fold_ident(id),followed_by_colons), _ => copy *t </ins> } }

Related discussion:
text: See the case in .
Not critical for 0.6; de-milestoning
-- does it make sense for the AST fold to visit macros? Or is the current code correct?
From my perspective: yes, definitely. In particular, I'm going to want ident-folds to hit the idents inside of macro invocations. Could it break code to add this traversal? Well, the only place you're going to see unexpanded macro invocations is prior to expansion, and the only thing inside of macro invocations is tokens, so it seems very unlikely. To summarize: yes, this fold should visit macro invocations.
In that case, nominating for milestone 5, production-ready
accepted for production-ready milestone
I've implemented this in a local branch, I expect to push it soon (next two days)
done, now. FIXME removed downstream.
Code change:
self.fields.infcx.tcx } <ins> fn relate_item_args( &mut self, item_def_id: rustc_hir::def_id::DefId, a_arg: ty::GenericArgsRef<'tcx>, b_arg: ty::GenericArgsRef<'tcx>, ) -> RelateResult<'tcx, ty::GenericArgsRef<'tcx>> { if self.ambient_variance == ty::Variance::Invariant { // Avoid fetching the variance if we are in an invariant // context; no need, and it can induce dependency cycles // (e.g., #41849). relate_args_invariantly(self, a_arg, b_arg) } else { let tcx = self.tcx(); let opt_variances = tcx.variances_of(item_def_id); relate_args_with_variances(self, item_def_id, opt_variances, a_arg, b_arg, false) } } </ins> fn relate_with_variance<T: Relate<'tcx>>( &mut self, variance: ty::Variance,

Related discussion:
text: <!-- 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
related. label F-inherentassociatedtypes
It caused by a cycle query:
There's a related bug to this (I believe by involving some traits with associated types) that I would like to report, though I was able to raise mine on Stable (1.70.0) without using the feature flag. Should I make a separate bug report or attach it here?
Code change:
self.fields.infcx.tcx } <ins> fn relate_item_args( &mut self, item_def_id: rustc_hir::def_id::DefId, a_arg: ty::GenericArgsRef<'tcx>, b_arg: ty::GenericArgsRef<'tcx>, ) -> RelateResult<'tcx, ty::GenericArgsRef<'tcx>> { if self.ambient_variance == ty::Variance::Invariant { // Avoid fetching the variance if we are in an invariant // context; no need, and it can induce dependency cycles // (e.g., #41849). relate_args_invariantly(self, a_arg, b_arg) } else { let tcx = self.tcx(); let opt_variances = tcx.variances_of(item_def_id); relate_args_with_variances(self, item_def_id, opt_variances, a_arg, b_arg, false) } } </ins> fn relate_with_variance<T: Relate<'tcx>>( &mut self, variance: ty::Variance,

Related discussion:
text: Regression in nightly-2023-02-21 found 9 bors merge commits in the specified range commit[0] 2023-02-19: Auto merge of - cjgillot:codegen-overflow-check, r=tmiasko commit[1] 2023-02-19: Auto merge of - clubby789:builtin-derived-attr, r=jackh726 commit[2] 2023-02-20: Auto merge of - fmease:iat-type-directed-probing, r=jackh726 commit[3] 2023-02-20: Auto merge of - tmiasko:read-buf, r=the8472 commit[4] 2023-02-20: Auto merge of - camelid:rustdoc-all-only-stable, r=GuillaumeGomez commit[5] 2023-02-20: Auto merge of - b-naber:proj-relate-variance, r=lcnr commit[6] 2023-02-20: Auto merge of - megakorre:issue_105700, r=petrochenkov commit[7] 2023-02-20: Auto merge of - matthiaskrgr:rollup-4tdvnx6, r=matthiaskrgr commit[8] 2023-02-20: Auto merge of - lnicola:rust-analyzer-2023-02-20, r=lnicola ERROR: no CI builds available between and within last 167 days I guess ?
Seems this has been fixed on the latest nightly, marked as E-needs-test. labels: +E-needs-test
this regressed again in
Code change:
.map(|did| tcx.provided_trait_methods(did).map(|meth| meth.name).collect()) .unwrap_or_default() } <ins> pub(crate) fn is_negative_trait_impl(&self) -> bool { matches!(self.polarity, ty::ImplPolarity::Negative) } </ins> } #[derive(Clone, Debug)]

Related discussion:
text: <p align="center"<img width="400" src=""</pI would prefer if only the negative impl signature were rendered here (and any doc comment on the negative impl). Not even a collapsed-by-default accordion to show the trait's contents. The reader can click the trait's name to see what is in it if they need. Having associated items of a negative impl rendered is inconvenient because something like <kbdCTRL+F</kbdfor "fn position" will land the reader deep in the middle of the big impl showing them APIs that their type does not have. Example of this occurring in standard library documentation:  Mentioning tracking issue.
Code change:
use rustc_errors::{Applicability, DiagnosticBuilder}; <ins> use rustc_infer::infer::TyCtxtInferExt; </ins> use rustc_middle::mir::*; use rustc_middle::ty; use rustc_span::source_map::DesugaringKind;

Related discussion:
text: <!-- 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. --Haven't minimized the code yet, but the exact code is up here: It's a kind of search algorithm. I think the problematic code is the function in . Will report back if I figure out anything more. <!-- 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 just switched to the stable toolchain, and the compilar gave me two errors: Apparently these were not caught by the nightly compiler.
This is probably a duplicate of You're using the nightly compiler though, so working as intended
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-medium
Code change:
use rustc_errors::{Applicability, DiagnosticBuilder}; <ins> use rustc_infer::infer::TyCtxtInferExt; </ins> use rustc_middle::mir::*; use rustc_middle::ty; use rustc_span::source_map::DesugaringKind;

Related discussion:
text: <!-- 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. --Compiles with replaced for <!-- 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 --
I got the same issue on the latest nightly and on , without using rustc-private The commented out block was used originally and triggers the ICE as well.
searched nightlies: from nightly-2021-07-29 to nightly-2021-08-02 regressed nightly: nightly-2021-07-31 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.0</summaryHost triple: x8664-pc-windows-msvc Reproduce with: </detailsI think this might have been introduced by , in particular this piece of code:
If that's indeed caused by then we should let its author know:
Just checked and thankfully .
claim
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-high
Code change:
#[test] fn wtf8buf_show() { <del> let mut string = Wtf8Buf::from_str("aé 💩"); </del> <ins> let mut string = Wtf8Buf::from_str("até 💩r"); </ins> string.push(CodePoint::from_u32(0xD800).unwrap()); <del> assert_eq!(format!("{:?}", string), r#""aé 💩u{D800}""#); </del> <ins> assert_eq!(format!("{:?}", string), r#""atu{e9} u{1f4a9}ru{D800}""#); </ins> } #[test]

Related discussion:
text: Formatting a string containing special characters with usually prints them escaped i.e.. This snippet runs as expected in the . However on Windows, using both and , the is printed unescaped : From what I can gather,  only concerns itself with faulty surrogates and completely ignores special characters.
Code change:
getSearchInput().focus(); } <del> // Removes the focus from the search bar </del> <ins> // Removes the focus from the search bar. </ins> function defocusSearchBar() { getSearchInput().blur(); }

Related discussion:
text: mdbook v4.6+ has a feature that pressing ESC removes query components from URLs (for example ). The feature was implemented in rust-lang/mdBook. It would be nice if rustdoc offers the same kind of that feature. This is, for example, an URL that contains query components in rustdoc: When users share URLs to an API, they don't have to remove the query manually.
could you share some thoughts about this feature request? If possible, could you mentor contributors how to implement this ?
I think it's a good idea. Gonna take a look at how to do it.
Can we reopen this issue ? I think only removes the query component when we remove keywords in search bar. This issue is about adding a keyboard shortcut.
Oh I see, my bad. Reopening!
Code change:
self.warn_dead_code(impl_item.id, impl_item.span, impl_item.name, <del> "associated const"); </del> <ins> "associated const", "used"); </ins> } self.visit_nested_body(body_id) } hir::ImplItemKind::Method(_, body_id) => { if !self.symbol_is_live(impl_item.id, None) { let span = self.tcx.sess.codemap().def_span(impl_item.span); <del> self.warn_dead_code(impl_item.id, span, impl_item.name, "method"); </del> <ins> self.warn_dead_code(impl_item.id, span, impl_item.name, "method", "used"); </ins> } self.visit_nested_body(body_id) }

Related discussion:
text: I was changing some code from integer constants to a proper enum and was greeted by the following warning: The warning sounded weird to me because I was pattern-matching on that damn variant in various places of the code; but I was pointed out to the fact that I wasn't actually creating that value. Maybe the warning should be rewritten to explicitly mention value creation? Cc
cc that looks like your thing
duplicate of
Yup! Closing in favor of that.