Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fixes #19607 #21576

Merged
merged 1 commit into from
Jun 16, 2023
Merged

fixes #19607 #21576

merged 1 commit into from
Jun 16, 2023

Conversation

Araq
Copy link
Member

@Araq Araq commented Mar 28, 2023

No description provided.

@Araq Araq closed this Jun 16, 2023
@Araq Araq reopened this Jun 16, 2023
@Araq
Copy link
Member Author

Araq commented Jun 16, 2023

@ringabout Do you think the CI is "conceptually" green for this one?

@ringabout
Copy link
Member

I think it's fine.

@Araq Araq merged commit 0750210 into devel Jun 16, 2023
@Araq Araq deleted the araq-fixes-19607 branch June 16, 2023 10:06
@github-actions
Copy link
Contributor

Thanks for your hard work on this PR!
The lines below are statistics of the Nim compiler built from 0750210

Hint: mm: orc; opt: speed; options: -d:release
167905 lines; 8.584s; 611.016MiB peakmem

@a-mr
Copy link
Contributor

a-mr commented Jul 1, 2023

@Araq ,

Is the idea of this PR to leave documentation empty in the case of a parsing failure?

Also when I run nim doc on e.g.

const
  PixelformatUncompressedGrayAlpha* = 2 ## 8*2 bpp (2 channels)

it does save .html file but reports an error twice

(2, 7) Error: '*' expected
(2, 7) Error: '*' expected

and exits with error code 1.
Is this behavior intended?

@Araq
Copy link
Member Author

Araq commented Jul 1, 2023

No, it's not and I suppose my patch is not good enough. It did fix the crash though. :-)

a-mr added a commit to a-mr/Nim that referenced this pull request Jul 7, 2023
Follow-up to nim-lang#21576 (for solving nim-lang#19607).

1) errors in Markdown mode for `.nim` doc comments are reported with
   red color but allow to generate `.html` with the comment represented by
   literate block (monospaced text). We suppose that it's what people want
   for (supposedly) small doc comments. And this behavior is also a bit
   more Markdown-ish in the sense that Markdown generally does not have
   the concept of parsing error.
   - However, for standalone `.md` it's **not** applied because for large
     files the consequences are way bigger.

(In {.doctype: rst.} mode the behavior is the same as before -- report
the error and stop.)
In future, when our parser can handle Markdown without errors according to
the spec, this code will most probably be not needed.
Araq pushed a commit that referenced this pull request Jul 7, 2023
Follow-up to #21576 (for solving #19607).

1) errors in Markdown mode for `.nim` doc comments are reported with
   red color but allow to generate `.html` with the comment represented by
   literate block (monospaced text). We suppose that it's what people want
   for (supposedly) small doc comments. And this behavior is also a bit
   more Markdown-ish in the sense that Markdown generally does not have
   the concept of parsing error.
   - However, for standalone `.md` it's **not** applied because for large
     files the consequences are way bigger.

(In {.doctype: rst.} mode the behavior is the same as before -- report
the error and stop.)
In future, when our parser can handle Markdown without errors according to
the spec, this code will most probably be not needed.
bung87 pushed a commit to bung87/Nim that referenced this pull request Jul 29, 2023
bung87 pushed a commit to bung87/Nim that referenced this pull request Jul 29, 2023
)

Follow-up to nim-lang#21576 (for solving nim-lang#19607).

1) errors in Markdown mode for `.nim` doc comments are reported with
   red color but allow to generate `.html` with the comment represented by
   literate block (monospaced text). We suppose that it's what people want
   for (supposedly) small doc comments. And this behavior is also a bit
   more Markdown-ish in the sense that Markdown generally does not have
   the concept of parsing error.
   - However, for standalone `.md` it's **not** applied because for large
     files the consequences are way bigger.

(In {.doctype: rst.} mode the behavior is the same as before -- report
the error and stop.)
In future, when our parser can handle Markdown without errors according to
the spec, this code will most probably be not needed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants