jiebi/CodeConvo huggingface dataset:
Code change:
With following doctest, where the cfg attribute spans multiple lines, the final program is invalid: the wrapping method doesn't take into account the dangling line that closes the attribute. rust /// # #![cfgattr(not(dox), feature(cfgtargetfeature, targetfeature, /// # stdsimd))] /// /// fn foo() { /// let mut dst = [0]; /// addquickly(&[1], &[2], &mut dst); /// asserteq!(dst[0], 3); /// } ///
cc
cc
I don't see a message associated with the stack trace, is that missing?
The problem lies in how rustdoc parses doctests. It scans lines for crate-level attributes and statements, but it doesn't do anything more intelligent than checking the beginning of each line: We recently changed the parsing for and detection to use the libsyntax parser, but this initial scan is still a string-based search. The way to fix the test in the OP is to actually remove the part of it - rustdoc doesn't pass on any information into doctest compilation, so those features are going to be enabled regardless.
This is the associated message:

Related discussion:
text: // shunted into "everything else" match state { PartitionState::Attrs => { <del> state = if trimline.starts_with("#![") || trimline.chars().all(|c| c.is_whitespace()) </del> <ins> state = if trimline.starts_with("#![") { if !check_if_attr_is_complete(line, edition) { mod_attr_pending = line.to_owned(); } else { mod_attr_pending.clear(); } PartitionState::Attrs } else if trimline.chars().all(|c| c.is_whitespace()) </ins> || (trimline.starts_with("//") && !trimline.starts_with("///")) { PartitionState::Attrs
Code change:
With following doctest, where the cfg attribute spans multiple lines, the final program is invalid: the wrapping method doesn't take into account the dangling line that closes the attribute. rust /// # #![cfgattr(not(dox), feature(cfgtargetfeature, targetfeature, /// # stdsimd))] /// /// fn foo() { /// let mut dst = [0]; /// addquickly(&[1], &[2], &mut dst); /// asserteq!(dst[0], 3); /// } ///
cc
cc
I don't see a message associated with the stack trace, is that missing?
The problem lies in how rustdoc parses doctests. It scans lines for crate-level attributes and statements, but it doesn't do anything more intelligent than checking the beginning of each line: We recently changed the parsing for and detection to use the libsyntax parser, but this initial scan is still a string-based search. The way to fix the test in the OP is to actually remove the part of it - rustdoc doesn't pass on any information into doctest compilation, so those features are going to be enabled regardless.
This is the associated message:

Related discussion:
text: { PartitionState::Crates } else { <del> PartitionState::Other </del> <ins> // First we check if the previous attribute was "complete"... if !mod_attr_pending.is_empty() { // If not, then we append the new line into the pending attribute to check // if this time it's complete... mod_attr_pending.push_str(line); if !trimline.is_empty() && check_if_attr_is_complete(line, edition) { // If it's complete, then we can clear the pending content. mod_attr_pending.clear(); } // In any case, this is considered as `PartitionState::Attrs` so it's // prepended before rustdoc's inserts. PartitionState::Attrs } else { PartitionState::Other } </ins> }; } PartitionState::Crates => {
Code change:
With following doctest, where the cfg attribute spans multiple lines, the final program is invalid: the wrapping method doesn't take into account the dangling line that closes the attribute. rust /// # #![cfgattr(not(dox), feature(cfgtargetfeature, targetfeature, /// # stdsimd))] /// /// fn foo() { /// let mut dst = [0]; /// addquickly(&[1], &[2], &mut dst); /// asserteq!(dst[0], 3); /// } ///
cc
cc
I don't see a message associated with the stack trace, is that missing?
The problem lies in how rustdoc parses doctests. It scans lines for crate-level attributes and statements, but it doesn't do anything more intelligent than checking the beginning of each line: We recently changed the parsing for and detection to use the libsyntax parser, but this initial scan is still a string-based search. The way to fix the test in the OP is to actually remove the part of it - rustdoc doesn't pass on any information into doctest compilation, so those features are going to be enabled regardless.
This is the associated message:

Related discussion:
text: <ins> // compile-flags:--test // normalize-stdout-test: "src/test/rustdoc-ui" -> "$$DIR" // normalize-stdout-test "finished in d+.d+s" -> "finished in $$TIME" // check-pass /// ``` /// # #![cfg_attr(not(dox), deny(missing_abi, /// # non_ascii_idents))] /// /// pub struct Bar; /// ``` pub struct Bar; </ins>
Code change:
With following doctest, where the cfg attribute spans multiple lines, the final program is invalid: the wrapping method doesn't take into account the dangling line that closes the attribute. rust /// # #![cfgattr(not(dox), feature(cfgtargetfeature, targetfeature, /// # stdsimd))] /// /// fn foo() { /// let mut dst = [0]; /// addquickly(&[1], &[2], &mut dst); /// asserteq!(dst[0], 3); /// } ///
cc
cc
I don't see a message associated with the stack trace, is that missing?
The problem lies in how rustdoc parses doctests. It scans lines for crate-level attributes and statements, but it doesn't do anything more intelligent than checking the beginning of each line: We recently changed the parsing for and detection to use the libsyntax parser, but this initial scan is still a string-based search. The way to fix the test in the OP is to actually remove the part of it - rustdoc doesn't pass on any information into doctest compilation, so those features are going to be enabled regardless.
This is the associated message:

Related discussion:
text: <ins> running 1 test test $DIR/doc-comment-multi-line-cfg-attr.rs - Bar (line 6) ... ok test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in $TIME </ins>
Code change:
This is intended to be a tracking issue to incorporate into the current beta branch for the Rust 2018 release, as we'll be relying on that in documentation that we're writing.
The Cargo backport is happening here - , and after that needs a PR to the beta branch in this repository
This is now submitted as
Done!

Related discussion:
text: <del> Subproject commit 5d967343acae16fd7b53a61e6cd4e93a1ac6f199 </del> <ins> Subproject commit 569507ef2beefcce4b666af41e09276f06445e96 </ins>
Code change:
Given the following source: The span conversion calculation in the error reporting will give the wrong offset when reporting the resolution failure, leading to a confusing report: Strangely enough, putting either the leading or the closing on its own line will cause the report to change to something that looks correct, if a little too broad: I believe the code at fault is this section here: Because it assumes that every doc comment will have a padding of 3 characters (the or ), it includes that in its calculation of each line's offset. However, for block-style comments, this assumption is false.
I'm working on this.
You can also reproduce this with unsugared docs:

Related discussion:
text: /// kept separate because of issue #42760. #[derive(Clone, RustcEncodable, RustcDecodable, PartialEq, Eq, Debug, Hash)] pub enum DocFragment { <del> // FIXME #44229 (misdreavus): sugared and raw doc comments can be brought back together once // hoedown is completely removed from rustdoc. </del> /// A doc fragment created from a `///` or `//!` doc comment. SugaredDoc(usize, syntax_pos::Span, String), /// A doc fragment created from a "raw" `#[doc=""]` attribute.
Code change:
Given the following source: The span conversion calculation in the error reporting will give the wrong offset when reporting the resolution failure, leading to a confusing report: Strangely enough, putting either the leading or the closing on its own line will cause the report to change to something that looks correct, if a little too broad: I believe the code at fault is this section here: Because it assumes that every doc comment will have a padding of 3 characters (the or ), it includes that in its calculation of each line's offset. However, for block-style comments, this assumption is false.
I'm working on this.
You can also reproduce this with unsugared docs:

Related discussion:
text: start.to(end) } <ins> /// Reports a resolution failure diagnostic. /// /// Ideally we can report the diagnostic with the actual span in the source where the link failure /// occurred. However, there's a mismatch between the span in the source code and the span in the /// markdown, so we have to do a bit of work to figure out the correspondence. /// /// It's not too hard to find the span for sugared doc comments (`///` and `/**`), because the /// source will match the markdown exactly, excluding the comment markers. However, it's much more /// difficult to calculate the spans for unsugared docs, because we have to deal with escaping and /// other source features. So, we attempt to find the exact source span of the resolution failure /// in sugared docs, but use the span of the documentation attributes themselves for unsugared /// docs. Because this span might be overly large, we display the markdown line containing the /// failure as a note. </ins> fn resolution_failure( cx: &DocContext, attrs: &Attributes,
Code change:
Given the following source: The span conversion calculation in the error reporting will give the wrong offset when reporting the resolution failure, leading to a confusing report: Strangely enough, putting either the leading or the closing on its own line will cause the report to change to something that looks correct, if a little too broad: I believe the code at fault is this section here: Because it assumes that every doc comment will have a padding of 3 characters (the or ), it includes that in its calculation of each line's offset. However, for block-style comments, this assumption is false.
I'm working on this.
You can also reproduce this with unsugared docs:

Related discussion:
text: before=link_range.start - last_new_line_offset, found=link_range.len(), )); <ins> diag </ins> } <del> diag </del> } else { cx.tcx.struct_span_lint_node(lint::builtin::INTRA_DOC_LINK_RESOLUTION_FAILURE, NodeId::from_u32(0),
Code change:
Given the following source: The span conversion calculation in the error reporting will give the wrong offset when reporting the resolution failure, leading to a confusing report: Strangely enough, putting either the leading or the closing on its own line will cause the report to change to something that looks correct, if a little too broad: I believe the code at fault is this section here: Because it assumes that every doc comment will have a padding of 3 characters (the or ), it includes that in its calculation of each line's offset. However, for block-style comments, this assumption is false.
I'm working on this.
You can also reproduce this with unsugared docs:

Related discussion:
text: <ins> intra-links-warning-crlf.rs eol=crlf </ins>
Code change:
Given the following source: The span conversion calculation in the error reporting will give the wrong offset when reporting the resolution failure, leading to a confusing report: Strangely enough, putting either the leading or the closing on its own line will cause the report to change to something that looks correct, if a little too broad: I believe the code at fault is this section here: Because it assumes that every doc comment will have a padding of 3 characters (the or ), it includes that in its calculation of each line's offset. However, for block-style comments, this assumption is false.
I'm working on this.
You can also reproduce this with unsugared docs:

Related discussion:
text: <ins> // ignore-tidy-cr // compile-pass // This file checks the spans of intra-link warnings in a file with CRLF line endings. The // .gitattributes file in this directory should enforce it. /// [error] pub struct A; /// /// docs [error1] /// docs [error2] /// pub struct B; /** * This is a multi-line comment. * * It also has an [error]. */ pub struct C; </ins>
Code change:
Given the following source: The span conversion calculation in the error reporting will give the wrong offset when reporting the resolution failure, leading to a confusing report: Strangely enough, putting either the leading or the closing on its own line will cause the report to change to something that looks correct, if a little too broad: I believe the code at fault is this section here: Because it assumes that every doc comment will have a padding of 3 characters (the or ), it includes that in its calculation of each line's offset. However, for block-style comments, this assumption is false.
I'm working on this.
You can also reproduce this with unsugared docs:

Related discussion:
text: <ins> warning: `[error]` cannot be resolved, ignoring it... --> $DIR/intra-links-warning-crlf.rs:8:6 | LL | /// [error] |      ^^^^^ cannot be resolved, ignoring | = note: #[warn(intra_doc_link_resolution_failure)] on by default = help: to escape `[` and `]` characters, just add '/' before them like `/[` or `/]` warning: `[error1]` cannot be resolved, ignoring it... --> $DIR/intra-links-warning-crlf.rs:12:11 | LL | /// docs [error1] |           ^^^^^^ cannot be resolved, ignoring | = help: to escape `[` and `]` characters, just add '/' before them like `/[` or `/]` warning: `[error2]` cannot be resolved, ignoring it... --> $DIR/intra-links-warning-crlf.rs:14:11 | LL | /// docs [error2] |           ^^^^^^ cannot be resolved, ignoring | = help: to escape `[` and `]` characters, just add '/' before them like `/[` or `/]` warning: `[error]` cannot be resolved, ignoring it... --> $DIR/intra-links-warning-crlf.rs:21:20 | LL |  * It also has an [error]. |                    ^^^^^ cannot be resolved, ignoring | = help: to escape `[` and `]` characters, just add '/' before them like `/[` or `/]` </ins>
Code change:
Given the following source: The span conversion calculation in the error reporting will give the wrong offset when reporting the resolution failure, leading to a confusing report: Strangely enough, putting either the leading or the closing on its own line will cause the report to change to something that looks correct, if a little too broad: I believe the code at fault is this section here: Because it assumes that every doc comment will have a padding of 3 characters (the or ), it includes that in its calculation of each line's offset. However, for block-style comments, this assumption is false.
I'm working on this.
You can also reproduce this with unsugared docs:

Related discussion:
text: } } f!("Foonbar [BarF] barnbaz"); <ins> /** # for example, * * time to introduce a link [error]*/ pub struct A; /** * # for example, * * time to introduce a link [error] */ pub struct B; #[doc = "single line [error]"] pub struct C; #[doc = "single line with "escaping" [error]"] pub struct D; /// Item docs. #[doc="Hello there!"] /// [error] pub struct E; /// /// docs [error1] /// docs [error2] /// pub struct F; </ins>
Code change:
Given the following source: The span conversion calculation in the error reporting will give the wrong offset when reporting the resolution failure, leading to a confusing report: Strangely enough, putting either the leading or the closing on its own line will cause the report to change to something that looks correct, if a little too broad: I believe the code at fault is this section here: Because it assumes that every doc comment will have a padding of 3 characters (the or ), it includes that in its calculation of each line's offset. However, for block-style comments, this assumption is false.
I'm working on this.
You can also reproduce this with unsugared docs:

Related discussion:
text: | = help: to escape `[` and `]` characters, just add '/' before them like `/[` or `/]` <ins> warning: `[error]` cannot be resolved, ignoring it... --> $DIR/intra-links-warning.rs:61:30 | LL |  * time to introduce a link [error]*/ |                              ^^^^^ cannot be resolved, ignoring | = help: to escape `[` and `]` characters, just add '/' before them like `/[` or `/]` warning: `[error]` cannot be resolved, ignoring it... --> $DIR/intra-links-warning.rs:67:30 | LL |  * time to introduce a link [error] |                              ^^^^^ cannot be resolved, ignoring | = help: to escape `[` and `]` characters, just add '/' before them like `/[` or `/]` warning: `[error]` cannot be resolved, ignoring it... --> $DIR/intra-links-warning.rs:71:1 | LL | #[doc = "single line [error]"] | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | = note: the link appears in this line: single line [error] ^^^^^ = help: to escape `[` and `]` characters, just add '/' before them like `/[` or `/]` warning: `[error]` cannot be resolved, ignoring it... --> $DIR/intra-links-warning.rs:74:1 | LL | #[doc = "single line with /"escaping/" [error]"] | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | = note: the link appears in this line: single line with "escaping" [error] ^^^^^ = help: to escape `[` and `]` characters, just add '/' before them like `/[` or `/]` warning: `[error]` cannot be resolved, ignoring it... --> $DIR/intra-links-warning.rs:77:1 | LL | / /// Item docs. LL | | #[doc="Hello there!"] LL | | /// [error] | |___________^ | = note: the link appears in this line: [error] ^^^^^ = help: to escape `[` and `]` characters, just add '/' before them like `/[` or `/]` warning: `[error1]` cannot be resolved, ignoring it... --> $DIR/intra-links-warning.rs:83:11 | LL | /// docs [error1] |           ^^^^^^ cannot be resolved, ignoring | = help: to escape `[` and `]` characters, just add '/' before them like `/[` or `/]` warning: `[error2]` cannot be resolved, ignoring it... --> $DIR/intra-links-warning.rs:85:11 | LL | /// docs [error2] |           ^^^^^^ cannot be resolved, ignoring | = help: to escape `[` and `]` characters, just add '/' before them like `/[` or `/]` </ins> warning: `[BarA]` cannot be resolved, ignoring it... --> $DIR/intra-links-warning.rs:24:10 |
Code change:
Given the following source: The span conversion calculation in the error reporting will give the wrong offset when reporting the resolution failure, leading to a confusing report: Strangely enough, putting either the leading or the closing on its own line will cause the report to change to something that looks correct, if a little too broad: I believe the code at fault is this section here: Because it assumes that every doc comment will have a padding of 3 characters (the or ), it includes that in its calculation of each line's offset. However, for block-style comments, this assumption is false.
I'm working on this.
You can also reproduce this with unsugared docs:

Related discussion:
text: = help: to escape `[` and `]` characters, just add '/' before them like `/[` or `/]` warning: `[BarB]` cannot be resolved, ignoring it... <del> --> $DIR/intra-links-warning.rs:28:1 </del> <ins> --> $DIR/intra-links-warning.rs:30:9 </ins> | <del> LL | / /** LL | |  * Foo LL | |  * bar [BarB] bar LL | |  * baz LL | |  */ | |___^ </del> <ins> LL |  * bar [BarB] bar |         ^^^^ cannot be resolved, ignoring </ins> | <del> = note: the link appears in this line: bar [BarB] bar ^^^^ </del> = help: to escape `[` and `]` characters, just add '/' before them like `/[` or `/]` warning: `[BarC]` cannot be resolved, ignoring it... <del> --> $DIR/intra-links-warning.rs:35:1 </del> <ins> --> $DIR/intra-links-warning.rs:37:6 </ins> | <del> LL | / /** Foo LL | | LL | | bar [BarC] bar LL | | baz ...  | LL | | LL | | */ | |__^ </del> <ins> LL | bar [BarC] bar |      ^^^^ cannot be resolved, ignoring </ins> | <del> = note: the link appears in this line: bar [BarC] bar ^^^^ </del> = help: to escape `[` and `]` characters, just add '/' before them like `/[` or `/]` warning: `[BarD]` cannot be resolved, ignoring it...
Code change:
Sorry for the cryptic title, didn't knew exactly what to put there. On musl targets (well and (hf)) for some reason pipe2 is not used (even on kernels that support it). Pipe2 is important to protect against race condition when multiple threads run external commands. The following is an example that due to this bug will deadlock on the musl targets listed above (and probably all linux musl ones). Running with strace proves that pipe2 is not used, and that instead the fallback is: vs the target: Versions affected: 1.30.1 1.31.0 - Current stable rustc 1.32.0-nightly ( 2018-12-07) Later Edit: Just to be clear, if I compile a C file with the same musl toolchain that rust uses pipe2 works, so it's not a bug in Musl (or doesn't look like one to me).
cc
Did some investigation regarding this bug: The culprit seems to be: More specifically the following comment: “It assumes that //! we've been dynamically linked to the library the symbol comes from, but that //! is currently always the case for things like libpthread/libc.” Well this is not the case for musl target binaries. pipe2 is one of the symbols rust uses this mechanism to check for existence.(for fair reasons, the symbol is not there on old kernels). But on any musl target this symbol does exist because musl is emulating it in it’s standard library in case the systemcall is missing. A solution would thus be to assume this symbol always exists on musl targets (and it’s probably the same for the other ones) and make the weak! macro return the symbol directly for such targets. I could do it myself if this sounds resonable.
Thanks for the report Your investigation sounds right to me and I agree that we can probably just assume these symbols always exist on the musl target (as we're mostly pulling in the libc anyway). Should be fine to update the standard library to assume so!
Is this kind of what you had in mind? I wanna know if I should go like this, or I understood you wrong.

Related discussion:
text: #![feature(cfg_target_vendor)] #![feature(char_error_internals)] #![feature(compiler_builtins_lib)] <ins> #![feature(concat_idents)] </ins> #![feature(const_int_ops)] #![feature(const_ip)] #![feature(const_raw_ptr_deref)]