Skip to content

Upgrade hoedown to 3.0.4 #27945

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

Merged
merged 1 commit into from Aug 25, 2015
Merged

Upgrade hoedown to 3.0.4 #27945

merged 1 commit into from Aug 25, 2015

Conversation

ghost
Copy link

@ghost ghost commented Aug 22, 2015

Some hoedown FFI changes:

  • HOEDOWN_EXT_NO_INTRA_EMPHASIS constant changed.
  • Updated/tidied up all callback function signatures.
  • All opaque data access has an additional layer of indirection for some reason (hoedown_renderer_data).

This also fixes #27862.

@rust-highfive
Copy link
Contributor

r? @brson

(rust_highfive has picked a reviewer for you, use r? to override)

@@ -68,49 +67,60 @@ const HOEDOWN_EXTENSIONS: libc::c_uint =
type hoedown_document = libc::c_void; // this is opaque to us
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

while you're here, this should probably be an empty enum

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Isn't c_void basically an empty enum? I mean I guess it's represented in hardware by a u8, but what does the difference make?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i believe that c_void is inhabitable; that is, you can create one

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The actual representation or whether this can be constructed isn't so much the problem here, but rather *mut hoedown_document and *mut c_void are the same types. In Rust it's more idiomatic to have those be separate types (to get at least some level of type safety). Creating an empty enum (enum hoedown_document {}) should serve this purpose

@ghost
Copy link
Author

ghost commented Aug 24, 2015

Changed hoedown_document to be an empty enum and squashed commits.

Adding any kind of type safety to the other void pointers is non-trivial because they point to different types in different passes. A lot of this module is very unsafe/hacky but hopefully we can replace it all with a pure rust Markdown parser at some point anyway!

@alexcrichton
Copy link
Member

@bors: r+ efc98fa

Thanks!

bors added a commit that referenced this pull request Aug 25, 2015
Some hoedown FFI changes:
- `HOEDOWN_EXT_NO_INTRA_EMPHASIS` constant changed.
- Updated/tidied up all callback function signatures.
- All opaque data access has an additional layer of indirection for some reason (`hoedown_renderer_data`).

This also fixes #27862.
@bors
Copy link
Collaborator

bors commented Aug 25, 2015

⌛ Testing commit efc98fa with merge fd7344c...

@bors bors merged commit efc98fa into rust-lang:master Aug 25, 2015
@ghost ghost deleted the upgrade-hoedown branch August 25, 2015 06:43
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.

Pipe character in rustdoc markdown tables can not be escaped
7 participants