jiebi/CodeConvo huggingface dataset:
Change:
self.other_attrs .lists(sym::doc) .filter(|a| a.has_name(sym::alias)) <del> .filter_map(|a| a.value_str().map(|s| s.to_string().replace(""", ""))) </del> <ins> .filter_map(|a| a.value_str().map(|s| s.to_string())) </ins> .filter(|v| !v.is_empty()) .collect::<FxHashSet<_>>() }

Discussion:
From this comment: Still remaining the .
Actually, the character has a meaning in the search (for "exact" search). But instead of just removing it, maybe we should instead emit an error when we encounter it. What do you think ?
That doesn't work for though, maybe it should? It would make sense to restrict allowed characters because even whitespace is allowed at the moment which seems questionable.
It sounds like we need to make sure this lands before we branch beta or so?
Let's forbid , whitespaces and tabs in the the doc alias then.
Can we avoid ad-hoc rules and say something like "must be a rust identifier"?
Even better! Great suggestion !
Just thought about it, but it cannot be the case : we allow things like "*" or "+" (for the traits for example), so it cannot be ident only. I'll stick to the listed characters above.
The documentation () has no mention of that -- can you elaborate?
Doc aliases can be something else than a rust identifier. For example, you can look for or in the std docs, and you'll see aliases results.
Ah, I see what you mean. Okay, then I agree that we need more than just Rust identifiers, and it might be reasonable to just allow as you suggest -- everything except whitespace and quotes. I'm a bit worried that'll hurt us in terms of how expansive it is but it's probably fine.
I don't expect attributes to be used widely, so we should be fine. ;)
Is there more justification for removing whitespace support other than calling the characters questionable? If I have a struct or a function that implements an algorithm, I would like to alias the item to the plaintext name of the algorithm, for example .
I just had in mind "idents", so no whitespace in them. However I don't see any reason to not allow specfically. I'll send a PR tomorrow.
rustdoc only being ident-centric is .
path-centric would be more accurate. ;)
Change:
use rustc_middle::mir; <del> use rustc_middle::ty::layout::HasTyCtxt; use rustc_middle::ty::InstanceDef; </del> use rustc_middle::ty::{self, Ty}; use std::borrow::Borrow; use std::collections::hash_map::Entry;

Discussion:
Since , memoization of argumentless functions is restricted to intrinsics, because other functions could perform heap allocations and thus memoization would be incorrect. I doubt we have any argumentless intrinsic that is expensive enough that memoization is worth it, so I propose we remove the leftovers of that infrastructure. Cc <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I want to work on this but i never contributed to rust-lang before so i need some guidance.
Great! So... step 0 is to write as a comment here, this will make sure the issue is assigned to you and noone else tries to tackle it at the same time. The main change is to remove this function: entirely without a replacement. You'll then have to adjust the call site to act as if the function returned . This may allow some small cleanups at the call site; I expect nothing major to happen there. I do not think there will be further test changes due to this, so, should run through without any failures. If it doesn't, still open a PR and let us know of your findings.
claim
Change:
<ins> // We used to ICE here while trying to synthesize auto trait impls. // issue: 107715 //@ check-pass pub const N: usize = 1; pub struct MapType<K: Supertrait<V>, V> { _array: K::Array, } pub trait Subtrait: Supertrait<[u8; N]> {} pub trait Supertrait<V> { type Array: AnotherTrait<V>; } pub trait AnotherTrait<V> { const LENGTH: usize; } pub struct Container<S: Subtrait> { _x: MapType<S, [u8; N]>, } </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. --This is the least I've managed to reduce the code: <!-- 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. --: With nightly version the compiler asks me to change the as follows: and now the error no longer occurs. After running the command, I get the following: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<pOutput seems the same </p</details
Related if not duplicate of one of: , , . label -needs-triage T-rustdoc A-auto-traits A-synthetic-impls
I can't seem to reproduce the ICE with and
Me neither, seems to have been fixed. Potentially by err's “ PR” or by one of the PRs that made rustdoc execute more of rustc's stages. Fixed: ICE → errors (unsatisfied bounds).

<!-- 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
label A-synthetic-impls A-auto-traits T-compiler The bug originates in which lives in , so having both team labels is valid.
Bisection seems to point to nightly-2022-10-24, one of these:
Out of those, looks the most likely (from ).
I can no longer reproduce this. Fixed: ICE → errors. Probably fixed by one of those PRs that made rustdoc run more of rustc's passes.

Minimal example What I expected: works. What happens: (check & build work) No response No response
Thanks for the report! I have transferred this to rust-lang/rust as that is where rustdoc issues are tracked.
Seems to be a compiler bug. Adding the relevant tag.
Although the MCVE looks a bit esoteric, it actually comes from using  in an fairly straightforward way. I wouldn't be surprised if others have/will run into this.
Ran on this and found it regressed in The PR () states it's a revert of a previous commit. So maybe it was broken before the commit that needed reverting.
label A-auto-traits A-synthetic-impls
I can no longer reproduce this issue.
Change:
DocFragmentKind::RawDoc }; <del> let frag = DocFragment { span: attr.span, doc: value, kind, parent_module, need_backline: false, indent: 0, }; if let Some(prev) = doc_strings.last_mut() { prev.need_backline = true; } </del> <ins> let frag = DocFragment { span: attr.span, doc: value, kind, parent_module, indent: 0 }; </ins> doc_strings.push(frag);

Discussion:
I expected this change to work: But it causes to panic: <details<summaryBacktrace</summary</detailsI don't have time to look into it right now, but I wouldn't expect it to be too hard to fix and it would reduce the memory usage of rustdoc by quite a lot. I'd suggest starting by adding a bunch of assertions that the old and new behavior of is the same and investigating the assertion failures. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Since would unconditionally add a final newline, shouldn't the note say that (instead of "this can") and the 'pop's be unconditional? Across the entire codebase, there's just one other invocation of 'adddocfragment' (currently line 1087 ); it seems that that doesn't need a newline popped. Instead, I think the last function you modified () should only have a newline popped for the last , as would only be false for the last , as far as I can tell. I made a commit to that effect in the PR above, though I have to resolve the merge conflict somehow.
feel free to try that out and see if it works :) like I said, I don't have time to work on it right now.
Change:
<del> // run-rustfix </del> #![allow(unused_imports)] pub mod x {

Discussion:
Was reported here : but still occurring. <!-- 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
Simpler repro: ()
I assume this repros for any non-ascii character, right? I tried with ü, ß, and , and I was able to repro.
Correct :) é was just the character my big fingers typed when I found that bug!
Assigning and removing as .20.E2.80.A6) in the prioritization working group.
This is a regression since modify labels: +regression-from-stable-to-stable
Change:
}; report_in_external_macro } <ins> declare_lint! { /// The `invalid_macro_export_arguments` lint detects cases where `#[macro_export]` is being used with invalid arguments. /// /// ### Example /// /// ```rust,compile_fail /// #![deny(invalid_macro_export_arguments)] /// /// #[macro_export(invalid_parameter)] /// macro_rules! myMacro { ///    () => { ///         // [...] ///    } /// } /// /// #[macro_export(too, many, items)] /// ``` /// /// {{produces}} /// /// ### Explanation /// /// The only valid argument is `#[macro_export(local_inner_macros)]` or no argument (`#[macro_export]`). /// You can't have multiple arguments in a `#[macro_export(..)]`, or mention arguments other than `local_inner_macros`. /// pub INVALID_MACRO_EXPORT_ARGUMENTS, Warn, ""invalid_parameter" isn't a valid argument for `#[macro_export]`", } </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. --I tried this code: I expected to see this happen: it shouldn't compile Instead, this happened: it compiles <!-- 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<summaryBacktrace</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
For anyone who would like to work on this, the following code needs to be adjusted to check if the meta-item list is empty or if it only contains the identifier (i.e. only allowing the attribute to be or : Due to backward compatibility concerns, probably only a future-incompat warning should be issued if the verification fails. label T-compiler A-attributes
claim
First rust-lang/rust contribution I hope this goes well
Change:
// - it lets us thread the write pointer through its innards and get it back in the end let sink = InPlaceDrop { inner: dst_buf, dst: dst_buf }; let sink = <del> self.try_fold::<_, _, Result<_, !>>(sink, write_in_place_with_drop(end)).unwrap(); </del> <ins> self.try_fold::<_, _, Result<_, !>>(sink, write_in_place_with_drop(end)).into_ok(); </ins> // iteration succeeded, don't drop head unsafe { ManuallyDrop::new(sink).dst.sub_ptr(dst_buf) } }

Discussion:
I tried this code: I expected to see this happen: Both and should get optimized to just return the input unchanged. Instead, this happened: unwrapcopy get's optimized as espected: unwrapclone fails to get optimized and compiles into a loop: Originally I thought that behavior was caused by the underlying type not implementing Copy but Drop seems to be the actual culprit. <!-- 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. --: </p</details
This reminds me of the do-nothing-loop from . That's not quite true, e.g. this also optimizes even though is not : So it's likely due to and the compiler fails to see that the drop can't happen.
Change:
} else { String::new() }; <ins> let doc_value = myitem.doc_value().unwrap_or(""); </ins> try!(write!(w, " <tr class='{stab} module-item'> <td><a class='{class}' href='{href}'

Discussion:
There are times it's nice to be able to include a link in the description of a given item. At present, however, if you try to include a reference link, it fails. Rust: HTML for the item description: However, if you change the first line of the Rust to be an inline reference, the problem goes away. Rust: Generated HTML: It appears (I haven't had a chance to check the implementation yet) that rustdoc is only parsing the first Markdown block element, rather than only keeping the first block element. This probably slightly improves performance, but it produces unexpected results.
Change:
<ins> -include ../tools.mk all: echo 'fn main(){}' | $(RUSTC) -Z no-link - $(RUSTC) -Z link-only $(TMPDIR)/rust_out.rlink $(call RUN,rust_out) </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. --I tried this command: I expected to see this happen: An file is generated. 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. --: Originally posted by in cc (original implementer of
PR changed the encode/decode method of . When was implemented, the encode/decode of was purposely crafted to avoid calling the encode/decode method of . The most straightforward fix is to implement / for to allow it be serialized outside of metadata. After that, may be now it is the time to re-think the way we store data in the file. What do you think ?
I think should completely be avoided in the input of the linker function. One of the uses if in it's field. This field doesn't seem to be used by the linking code.
Good suggestion, let me look into it.
are you still working on this?
Thank you for reminding and apologize for the delay. I did create a prototype but haven't got a chance polish it yet. I'll create the PR this week.
Sorry again about the delay. I've created PR , which fixes this issue.
Change:
} fn visit_terminator_kind(&mut self, kind: &mut TerminatorKind<'tcx>, loc: Location) { <del> self.super_terminator_kind(kind, loc); </del> <ins> // Don't try to modify the implicit `_0` access on return (`return` terminators are // replaced down below anyways). if !matches!(kind, TerminatorKind::Return) { self.super_terminator_kind(kind, loc); } </ins> match *kind { TerminatorKind::GeneratorDrop | TerminatorKind::Yield { .. } => bug!(),

Discussion:
The terminator conceptually moves out of the return place , but this is not currently reflected by the visitor infrastructure. This can lead to incorrect dataflow solutions for . For example, reports that is dead before a , which is wrong (it must always be live there). These don't currently cause any harm, since use of is fairly limited, but they are an issue for destination propagation / NRVO, which can propagate to arbitrary places in the function and needs to have correct information to do so soundly. The simple fix of calling from within has the problem that the receives a , but the local reads from can not be changed. This can be caught with an assertion, but maybe there is a better solution for this? cc
I think any alternative will be more complex than that simple assertion. Conceptually the should contain a which is always , but then we'd need to have assertions keeping that in place, so you don't gain anything. I don't think we can generalize returning to allow using different places than , which is the only way we'd get around having to assert something somewhere.
Change:
LL |         type Assoc = m::Pub3; |         ^^^^^^^^^^ <ins> warning: trait `aliases_pub::PrivTr` is more private than the item `aliases_pub::f3` --> $DIR/private-in-public.rs:106:5 | LL |     pub fn f3(arg: <Priv as PrivTr>::Assoc) {} |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ function `aliases_pub::f3` is reachable at visibility `pub(crate)` | note: but trait `aliases_pub::PrivTr` is only usable at visibility `pub(self)` --> $DIR/private-in-public.rs:100:5 | LL |     trait PrivTr { |     ^^^^^^^^^^^^ </ins> warning: type `aliases_pub::Priv` is more private than the item `aliases_pub::f3` --> $DIR/private-in-public.rs:106:5 |

Discussion:
This is a pretty common use case, so this bug has probably already been registered, but I couldn't find anything while searching around, so I'm reporting this here just in case. I ran this code: When running this code, I expect to simply get a not yet implemented error on the function. Instead, I get this: : returns an , and is not a trait method–it's just a regular method. Therefore, AFAIK, this should compile. Notably, making either or as makes it compile fine.
Regression in . cc
oli's on leave so cc-ing PR 's reviewer
WG-prioritization assigning priority (). label -I-prioritize +P-high
Change:
let temps = mir.temp_decls.iter() .map(|decl| bcx.monomorphize(&decl.ty)) .enumerate() <del> .map(|(i, mty)| if lvalue_temps.contains(&i) { </del> <ins> .map(|(i, mty)| if lvalue_temps.contains(i) { </ins> TempRef::Lvalue(LvalueRef::alloca(bcx, mty, &format!("temp{:?}", i)))

Discussion:
In MIR we want values to be SSA, however ensuring that constraint in trans (i.e. in TempRef) is wrong, I think. Namely, for code like this: we will generate following MIR (graphviz version, because easier to visualise): ! which will result in Note how we assign twice, but the two branches are fully disjoint, and thus, for the purposes of data-flow is still SSA, but for the purposes of translator is assigned multiple times. If we want s to stay across translation of the whole function, we will need something like a in the MIR. cc
Another option would be to convert these temporaries into lvalues (i.e. variables). Could it be that the unfinished is supposed to do just that?
I am confused. We do not require temps to be SSA, either in Mir or trans... But in trans we optimize in those cases where we can (I.e., where temps are SSA). Right?
suggests they are SSA with borrowing and mutation possible. Might be me misinterpreting what SSA means, but what I mean is that these are not supposed to be assigned more than once, for some definitions of once.
I see. Yes, ok, I agree that comment was in error. I think though that you probably ought to update it in :) I would still expect temps to be "DSA" -- which afaik I just made up -- that is, no two writes can reach one another without exiting the "live scope" of the temporary, but I don't know that it's an important property. FWIW I think SSA usually implies that values are "pure values", i.e., you can't take their address and mutate them. But I know what you mean in any case.
er, ought to have updated it
I’ll keep updating the comment in mind in whatever PR that comes next.
Change:
<ins> // check-pass // issue: 113415 // Makes sure that coherence doesn't call any of the `predicate_may_hold`-esque fns, // since they are using a different infcx which doesn't preserve the intercrate flag. #![feature(specialization)] //~^ WARN the feature `specialization` is incomplete trait Assoc { type Output; } default impl<T> Assoc for T { type Output = bool; } impl Assoc for u8 {} trait Foo {} impl Foo for u32 {} impl Foo for <u8 as Assoc>::Output {} fn main() {} </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 you this assertion
Regression in nightly-2023-07-06 Regression in
so this was clearly buggy before and I expect it to be an issue limited to specialization. Going to not look into this further myself for now.
Change:
<ins> fn main() { let a: i8 = loop { 1 //~ ERROR mismatched types }; let b: i8 = loop { break 1; }; } fn foo() -> i8 { let a: i8 = loop { 1 //~ ERROR mismatched types }; let b: i8 = loop { break 1; }; loop { 1 //~ ERROR mismatched types } loop { return 1; } loop { 1 //~ ERROR mismatched types } } </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. 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: The current output is: Ideally the output should look like: <!-- If the problem is not self-explanatory, please provide a rationale for the change. --It may not be immediately clear to a user why implicit-return/break style works for expressions, but not for . Adding a hint to explicitly break with would be helpful. <!-- 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. --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
label +A-suggestion-diagnostics
claim
Change:
<ins> #![feature(const_closures, const_trait_impl, effects)] #![allow(incomplete_features)] trait Foo { fn foo(&self); } impl Foo for () { fn foo(&self) {} } fn main() { (const || { (()).foo() })(); //~^ ERROR: cannot call non-const fn } </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
Fixed on the latest nightly, marking as E-needs-test (or, feel free to close if we have a sufficient regression test) labels: +E-needs-test
Change:
span: Option<Span>, layout: Option<TyAndLayout<'tcx>>, ) -> InterpResult<'tcx, OpTy<'tcx, M::Provenance>> { <del> // FIXME(const_prop): normalization needed b/c const prop lint in // `mir_drops_elaborated_and_const_checked`, which happens before // optimized MIR. Only after optimizing the MIR can we guarantee // that the `RevealAll` pass has happened and that the body's consts // are normalized, so any call to resolve before that needs to be // manually normalized. let val = self.tcx.normalize_erasing_regions(self.param_env, *val); match val { </del> <ins> match *val { </ins> mir::ConstantKind::Ty(ct) => { let ty = ct.ty(); let valtree = self.eval_ty_constant(ct, span)?;

Discussion:
https://crater-
searched nightlies: from nightly-2023-01-24 to nightly-2023-03-30 regressed nightly: nightly-2023-02-05 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.5</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </detailsThis looks related to , but wasn't fixed by
Let's notify the people involved in that bisection, it's cc author and reviewer A minimization would be helpful.
probably just allowed another existing bug to show up, like the other projection issues. I've reduced the regression to this it still depends on , if anyone has the time to also remove that.
WG-prioritization assigning priority (). label -I-prioritize +P-medium
This seems to have disappeared in nightly. Bisect points to Maybe fixed by
Wasn't that PR already present in your previous bisection up to nightly-2023-03-30 ?
Ah, looks like the is fixed in , but not the .
label -E-needs-mcve +S-has-mcve