jiebi/CodeConvo huggingface dataset:
Code change:
changes = true; // remove a "[ t]**" block from each line, if possible for line in lines.iter_mut() { <del> if horizontal + 1 < line.len() { *line = &line[horizontal + 1..]; </del> <ins> if let Some(tmp) = line.strip_prefix(&horizontal) { *line = tmp; if kind == CommentKind::Block && (*line == "*" || line.starts_with("* ") || line.starts_with("**")) { *line = &line[1..]; } </ins> } } }

Related discussion:
text: Hi, I've just published a new version of my crate and the generated documentation is including a lot of bullet points that have never been included before. When I generate the docs locally on the 1.8.1 source code using the latest stable version of rust I see the same formatting for the 1.8.0 that generated, so I think this is a bug that's slipped into the nightly version of Stable local docs: ! ! My guess is that it's because I'm using block comments, the unwanted bullet points seem to match up with empty lines in the documentation comment which consist of just a . Thanks
Seems potentially related to , but the latest builds were from a nightly that should have that fixed in; cc you probably have some idea on where the issue is.
This is highly surprising indeed. Can you run with the last nightly locally and tell us if it reproduces the bug please? If so, I'll try to check what's wrong in rustdoc.
I have ran cargo doc on the latest nightly locally (nightly-x86_64-unknown-linux-gnu rustc 1.60.0-nightly ( 2022-01-20)) and it has reproduced the bug - I see the same generated docs as from the build.
It'll be fixed by
Thanks, is there any way I can get to rebuild the docs for the affected versions or will I have to submit a new version of my library to get a fixed build?
Sure. But that for that, please open an issue on repository directly.
Code change:
<ins> // check-pass // edition:2021 #![feature(type_alias_impl_trait)] use std::future::Future; use std::marker::PhantomData; trait Stream { type Item; } struct Empty<T> { _phantom: PhantomData<T>, } impl<T> Stream for Empty<T> { type Item = T; } trait X { type LineStream<'a, Repr>: Stream<Item = Repr> where Self: 'a; type LineStreamFut<'a, Repr>: Future<Output = Self::LineStream<'a, Repr>> where Self: 'a; fn line_stream<'a, Repr>(&'a self) -> Self::LineStreamFut<'a, Repr>; } struct Y; impl X for Y { type LineStream<'a, Repr> = impl Stream<Item = Repr>; type LineStreamFut<'a, Repr> = impl Future<Output = Self::LineStream<'a, Repr>>; fn line_stream<'a, Repr>(&'a self) -> Self::LineStreamFut<'a, Repr> { async { Empty { _phantom: PhantomData } } } } fn main() {} </ins>

Related discussion:
text: <!-- 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. --Playing around with (the not yet stable) and features I stumbled over the below problem, where type parameters to nested TAIT/GAT with lifetime parameters cause a "this type parameter needs to be std::marker::Sized" compiler error. The following code fails to compile with below compiler error (): In contrast, the following code, without lifetime type parameters compiles without any error. <!-- 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. --:
This gives a different error. Minimized:
GATs issue triage: not blocking. Seems like a TAITs bug; not sure there's anything for GATs to change here.
Compiles just fine now.
I guess this issue can just be closed if there's a test already?
I think test needs to be moved to correct place?
Hello, first time contributing to rust. I was trying to resolve this issue and after looking at the test I am a little confused. To me it looks like the test code is failing correctly and I can't understand where the TAIT bug is. has a concrete type whereas the function is generic over . So to me it looks like the raised error is correct. Changing the implementation to makes the code compile. I am sorry if I am missing something here. If the test is correct then would moving the test to resolve this issue? I also don't think relates to this test.
Yeah, I messed up my minimization. The test should just use the original MCVE in the OP. And that is indeed fixed.
For clarity: this can be closed when the current known-bug test is moved to the main directory for GAT tests and changed to use the OP MCVE.
Code change:
/// // See how many bytes are currently buffered /// let bytes_buffered = buf_writer.buffer().len(); /// ``` <del> #[unstable(feature = "bufreader_buffer", issue = "45323")] </del> <ins> #[stable(feature = "bufreader_buffer", since = "1.37.0")] </ins> pub fn buffer(&self) -> &[u8] { &self.buf }

Related discussion:
text: Update: this is the tracking issue for: is both unstable and deprecated, it should be removed. There is currently no way to tell whether there is any data buffered inside a BufReader. This is unfortunate because it means that an application has no way to know whether calls to read() and fillbuffer() will return instantly or trigger a potentially expensive call to the underlying Reader. I propose adding an is_empty() method to BufReader to fill this gap.
now that has been merged, I'm guessing this should get the label?
What's left for this to stabilize? I'm parsing bytes from a to MsgPack using . The function will stop parsing once a valid MsgPack value has been found. But in my application the parsing should fail if the buffer hasn't been consumed completely. Checking would probably be the cleanest way to do so.
the method proposed in may also be useful for that purpose, though that may take even longer to land.
This is the tracking issue for: Looks good to me to stabilize. fcp merge
Team member has proposed to merge this. The next step is review by the rest of the tagged teams: [x] [x] [x] [ ] [x] [x] [ ] No concerns currently listed. Once a majority of reviewers approve (and none object), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See for info about what commands tagged team members can give me.
This seems fine to stabilize, but it seems like it'd be more useful to know how many bytes are buffered, rather than just that there are some number of bytes.
Why not both? Slices have even though it’s somewhat redundant with .
For sure. Would it be reasonable to try to squeeze that into this stabilization?
Sounds ok to me, though we should probably (re)start FCP after the implementation is merged.
Naming wise, I don't think fits since that seems to me like it'd refer to the length of the entire reader rather than just the current buffered data (similarly is a bit confusing). How about and ?
Agreed. Sounds good to me.
Alternatively, we could add to just return the buffer, which is also a thing people want separately from this issue. At that point seems not much worse than so we could have one method instead of three.
Code change:
/// // See how many bytes are currently buffered /// let bytes_buffered = buf_writer.buffer().len(); /// ``` <del> #[unstable(feature = "bufreader_buffer", issue = "45323")] </del> <ins> #[stable(feature = "bufreader_buffer", since = "1.37.0")] </ins> pub fn buffer(&self) -> &[u8] { &self.buf }

Related discussion:
text: adds and deprecates .
:bell: This is now entering its final comment period, as per the . :bell:
With alternative (and IMO better) proposal just introduced, should this still be going into its final comment period?
fcp cancel Let’s start again after has landed.
proposal cancelled.
We should likely also add a method to for consistency?
That can't be done backwards compatibly.
why not? It's just a , right? Just like .
Oh derp I somehow read that as .
Haha, no worries. Is there even a trait?
No there isn't _Off of the topic of me needing more caffeine, it definitely seems reasonable to add to , and fold it into the same feature gate as 's.
It has been a while since landed. Is this ready to stabilize?
is implemented, but discussed above is not. (I’ve updated the issue’s description with the current status.)
Wait, we aren't proposing to stabilize the (already deprecated) is_empty method are we?
No, sorry I didn’t clarify. An API marked both unstable and deprecated is to be removed (after something like a couple release cycles of deprecation period, which we’re at in this case).
I'm excited to see that this is so close to landing. Is this still waiting on an implementation of ? Would it be possible to track that feature separately to unblock this one?
Bump. Is there anything else blocking stabilization?
Is there any particular reason not to add to ? It seems like a useful enough general-purpose API ("get me however many bytes you can easily give me"), and I found myself looking for such a method while working on parser tooling. Individual implementations could make stricter guarantees about the lower bounds, of which "at least the unconsumed fraction of the last " would be a common one.
Yeah, this has been a while. is this ready for a vote to stabilize?
This issue seems to have been stuck in a strange limbo state for quite a while now. Pinging more people the rfcbot mentioned...
Sorry we dropped the ball here. This is now one method on the and structs. fcp merge
Team member has proposed to merge this. The next step is review by the rest of the tagged team members: [ ] [x] [x] [x] [x] [x] [ ] No concerns currently listed.
Code change:
/// // See how many bytes are currently buffered /// let bytes_buffered = buf_writer.buffer().len(); /// ``` <del> #[unstable(feature = "bufreader_buffer", issue = "45323")] </del> <ins> #[stable(feature = "bufreader_buffer", since = "1.37.0")] </ins> pub fn buffer(&self) -> &[u8] { &self.buf }

Related discussion:
text: Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See for info about what commands tagged team members can give me.
There is nothing called in std. Did you mean the trait? A downside is that to add it now we would have to make it a default method, which would (at first) have an inconsistent behavior with for existing impls. We can update impls in std at the same time, but that leaves impls in other crates.
:bell: This is now entering its final comment period, as per the . :bell:
Sorry, yes, I meant . For my use cases, not having a lower bound is fine. Anything that does can use a marker subtrait that encompasses that guarantee. I think the only stipulation should be that it not provide more than , but less is fine. For example, an implementation might copy existing data around on to make a larger contiguous segment, but can't/shouldn't do so in (I think it should be a cheap conversion, wouldn't have been an unreasonable name).
The final comment period, with a disposition to merge, as per the , is now complete. As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed. The RFC will be merged soon.
Code change:
/// `//[foo]`), then the property is ignored unless `cfg` is /// `Some("foo")`. fn load_from(&mut self, testfile: &Path, cfg: Option<&str>, config: &Config) { <del> // In CI, we've sometimes encountered non-determinism related to truncating very long paths. // Set a consistent (short) prefix to avoid issues, but only in CI to avoid regressing the // contributor experience. if CiEnv::is_ci() { self.remap_src_base = config.mode == Mode::Ui && !config.suite.contains("rustdoc"); } </del> let mut has_edition = false; if !testfile.is_dir() { let file = File::open(testfile).unwrap();

Related discussion:
text: I tried this code: and I expected to see this happen: All tests passing. No doc tests running when using 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. --: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
The tests pass for me and they're passing in CI. So I suspect there is something about your system that differs from mine and CI. Can you post the contents of your ?
Also, could you share how these tests are failing? Failing tests usually explain why their stderr differs from expected, or otherwise explain why the test happened to fail.
Hi there, I just did a fresh clone and got the same failures (target x86_64-unknown-linux-gnu). The file has not been changed. The test pass when I used my Mac device. The test each have "The actual stderr differed from the expected stderr." The actual stderr seems to have extra lines " full type name has been written to.." which are not in the expected stderr. Could that be the cause of the failure? If so, what can a fix look like? Full output on terminal:
is your copy of rust cloned into some really deep directory path? like... ? the problem is that your tests are failing because your build is producing type names that hit the length limit and are spilled to disk, and that file limit is dependent (unfortunately) on the path that the rust clone is located at...
we should probably fix this so that UI tests don't spill any long type names to disk by default. We could do this by adding a compiler flag that disables this behavior, and enable that flag by default in the ui testing suite.
this is a great idea — if we do this, we should also remove the code that enables remap-path-prefix in CI.
I can reproduce this locally by cloning under a long path. I would like to work on this. I'll take a look to see if I can identify where we have the logic for spilling the type names to disk, and guard it with a flag. I'll ask questions if I have trouble with that.
Code change:
/// `//[foo]`), then the property is ignored unless `cfg` is /// `Some("foo")`. fn load_from(&mut self, testfile: &Path, cfg: Option<&str>, config: &Config) { <del> // In CI, we've sometimes encountered non-determinism related to truncating very long paths. // Set a consistent (short) prefix to avoid issues, but only in CI to avoid regressing the // contributor experience. if CiEnv::is_ci() { self.remap_src_base = config.mode == Mode::Ui && !config.suite.contains("rustdoc"); } </del> let mut has_edition = false; if !testfile.is_dir() { let file = File::open(testfile).unwrap();

Related discussion:
text: claim
alternatively, we could gate it under the existing flag
I have code that works for this, but there are some tests under that seem to actually test specifically this behaviour of spilling to disk. So I'm thinking, under we skip spilling to disk, unless there is another flag, enabled, in which case we spill long type names to disk so that logic can be tested as well. Thoughts?
Two examples I found where we are testing the long type name spilling behaviour: with
:+1: this seems good. i would bikeshed the name as and uncouple it from (i.e. compiletest would start passing instead of you changing the behavior of ), but i like the idea :)
I have a pull-request for this, but I'm getting an error in the CI pipeline that I haven't dug too deep into, was wondering if there is a simple explanation for this? Thanks
The pull-request is going through well, but I'm now wondering about this part: Do you mean to basically revert this pull-request:
Pull-request to remove remap-path-prefix code for CI builds:
Code change:
use rustc_middle::ty::query::Providers; use rustc_middle::ty::TyCtxt; <del> use rustc_ast::{Attribute, LitKind, NestedMetaItem}; </del> <ins> use rustc_ast::{Attribute, Lit, LitKind, NestedMetaItem}; </ins> use rustc_errors::{pluralize, struct_span_err}; use rustc_hir as hir; use rustc_hir::def_id::LocalDefId;

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
This isn't really a bug, it's just that it has bad diagnostics because it uses , which is a perma-unstable attribute. I would recommend against reporting bugs that need attributes unless they cause unsoundness.
MCVE:
Should I exclude all test programs that have a line starting with ? Thanks.
I don't personally feel comfortable setting a policy that we'll never fix ICEs with attributes, but they are definitely less likely to be bugs than other ICEs. Note that this isn't sufficient to catch programs that have an attribute, you can have arbitrary macros that play with conditional compilation, like . Catching and will probably hit the common cases, though (you may want to also include inner attributes).
Code change:
use rustc_middle::ty::query::Providers; use rustc_middle::ty::TyCtxt; <del> use rustc_ast::{Attribute, LitKind, NestedMetaItem}; </del> <ins> use rustc_ast::{Attribute, Lit, LitKind, NestedMetaItem}; </ins> use rustc_errors::{pluralize, struct_span_err}; use rustc_hir as hir; use rustc_hir::def_id::LocalDefId;

Related discussion:
text: Gives:
cc ICE-ing instead of user error on misuse seems somewhat okay given that it's an internal attribute, IMO.
agreed. We don't protect against mis-use of rustc internal attributes beyond making sure that you can't trivially create buggy code. I don't think we should put any effort into making this nicer to use and instead create the const-generic based replacement.
Code change:
assert_eq!(stripped.as_str(), "!test"); }) } <ins> #[test] fn test_doc_blocks() { create_default_session_globals_then(|| { let stripped = beautify_doc_string(Symbol::intern(" # Returnsn     *n     "), CommentKind::Block); assert_eq!(stripped.as_str(), " # Returnsnn"); let stripped = beautify_doc_string( Symbol::intern("n     * # Returnsn     *n     "), CommentKind::Block, ); assert_eq!(stripped.as_str(), " # Returnsnn"); let stripped = beautify_doc_string(Symbol::intern("n *     an "), CommentKind::Block); assert_eq!(stripped.as_str(), "     an"); }) } </ins>

Related discussion:
text: Hi, I've just published a new version of my crate and the generated documentation is including a lot of bullet points that have never been included before. When I generate the docs locally on the 1.8.1 source code using the latest stable version of rust I see the same formatting for the 1.8.0 that generated, so I think this is a bug that's slipped into the nightly version of Stable local docs: ! ! My guess is that it's because I'm using block comments, the unwanted bullet points seem to match up with empty lines in the documentation comment which consist of just a . Thanks
Seems potentially related to , but the latest builds were from a nightly that should have that fixed in; cc you probably have some idea on where the issue is.
This is highly surprising indeed. Can you run with the last nightly locally and tell us if it reproduces the bug please? If so, I'll try to check what's wrong in rustdoc.
I have ran cargo doc on the latest nightly locally (nightly-x86_64-unknown-linux-gnu rustc 1.60.0-nightly ( 2022-01-20)) and it has reproduced the bug - I see the same generated docs as from the build.
It'll be fixed by
Thanks, is there any way I can get to rebuild the docs for the affected versions or will I have to submit a new version of my library to get a fixed build?
Sure. But that for that, please open an issue on repository directly.
Code change:
/// assert_eq!("grÜße, jÜrgen ❤", s); /// ``` #[stable(feature = "ascii_methods_on_intrinsics", since = "1.23.0")] <del> #[rustc_const_unstable(feature = "const_make_ascii", issue = "130698")] </del> <ins> #[rustc_const_stable(feature = "const_make_ascii", since = "CURRENT_RUSTC_VERSION")] </ins> #[inline] <ins> #[cfg_attr(bootstrap, rustc_allow_const_fn_unstable(const_mut_refs))] </ins> pub const fn make_ascii_lowercase(&mut self) { // SAFETY: changing ASCII letters only does not invalidate UTF-8. let me = unsafe { self.as_bytes_mut() };

Related discussion:
text: Feature gate: This is a tracking issue for marking the and methods in , , , and as "const." [x] Implementation for : [x] Implementation for : [x] Implementation for and : [x] Final comment period (FCP) [x] Stabilization PRNone yet.
fcp merge / have been stable in const since 1.52. / are unblocked now by the stabilization of
Team member has proposed to merge this. The next step is review by the rest of the tagged team members: [x] [x] [x] [ ] [ ] No concerns currently listed. Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See for info about what commands tagged team members can give me.
Can the methods be included in this? Similarly const stable / since 1.52.
Yes, that sounds like a good idea. I'll try adding another PR later.
:bell: This is now entering its final comment period, as per the . :bell:
stabilises this.
The final comment period, with a disposition to merge, as per the , is now complete. As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed. This will be merged soon.
Code change:
.with_indent_lines(true) .with_ansi(true) .with_targets(true) <del> .with_thread_ids(true) .with_thread_names(true) </del> .with_wraparound(10) .with_verbose_exit(true) .with_verbose_entry(true) .with_indent_amount(2); <ins> #[cfg(parallel_compiler)] let layer = layer.with_thread_ids(true).with_thread_names(true); </ins> use tracing_subscriber::layer::SubscriberExt; let subscriber = tracing_subscriber::Registry::default().with(filter).with(layer);

Related discussion:
text: For example: There are two issues here: actually helpful? All the code runs in the same thread with the same name, so it doesn't add any more info 's no space between the output and the header, so it's hard to read the logs. cc
I believe the crate, which is using, provides methods for and when constructing its layer, so it should be possible to turn this off. I believe the missing space is probably a bug in that crate, so I'd . It's possible this was the intended formatting, you'd probably need to ask to be sure.
Thanks, I'll do that :)