Skip to content

Export uv functions from rustrt, remove wrappers #5429

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

Closed
brson opened this issue Mar 18, 2013 · 8 comments
Closed

Export uv functions from rustrt, remove wrappers #5429

brson opened this issue Mar 18, 2013 · 8 comments
Labels
A-runtime Area: std's runtime and "pre-main" init for handling backtraces, unwinds, stack overflows E-easy Call for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue.

Comments

@brson
Copy link
Contributor

brson commented Mar 18, 2013

There is some linkage issue causing the uv API to not be exported from rustrt, and as a result we've accumulated a bunch of functions prefixed with rust_uv that do nothing but wrap them. Figure out how to make the uv API public and delete all these functions.

@jjjjw
Copy link
Contributor

jjjjw commented Mar 30, 2013

So is uv going to be in core then? #4956

@brson
Copy link
Contributor Author

brson commented Mar 30, 2013

The long-term plan is for uv to be in its own crate and imported as the default I/O implementation, not in core.

@luqmana
Copy link
Member

luqmana commented Mar 31, 2013

Adding uv_* to rt/rustrt.def.in should reexport all the libuv symbols.

@brson
Copy link
Contributor Author

brson commented May 6, 2013

Adding uv_* did not work on windows: http://buildbot.rust-lang.org/builders/auto-win/builds/1050

brson added a commit to brson/rust that referenced this issue May 8, 2013
This removes almost all of the simple wrappers from rust_uv.cpp.
For some reason uv_getaddrinfo and uv_freeaddrinfo still can't be removed.
@brson
Copy link
Contributor Author

brson commented May 8, 2013

uv_.* parses but linking on windows results in undefined references.

@msullivan
Copy link
Contributor

Do we have any idea what the root cause is here?

@brson
Copy link
Contributor Author

brson commented Oct 10, 2013

I don't know why this is on a milestone. Removing.

@alexcrichton
Copy link
Member

I did this awhile back, libuv is statically linked, exporting all those functions, and I removed all wrappers that weren't just there to access fields of structs we don't know the layout of in rust.

oli-obk pushed a commit to oli-obk/rust that referenced this issue May 2, 2020
…ip1995

Use assoc int and float consts instead of module level ones

changelog: Recommend primitive type associated constants instead of module level constants

In Rust 1.43 integer and float primitive types will have a number of new associated constants. For example `MAX`, `MIN` and a number of constants related to the machine representation of floats. rust-lang#68952

These new constants are preferred over the module level constants in `{core,std}::{f*, u*, i*}`. I have in the last few days made sure that the documentation in the main rust repository uses the new constants in every place I could find (rust-lang#69860, rust-lang#70782). So the next step is naturally to make the linter recommend the new constants as well.

This PR only changes two lints. There are more. But I did not want the PR to be too big. And since I have not contributed to clippy before it felt saner to start with a small PR so I see if there are any quirks. More will come later.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-runtime Area: std's runtime and "pre-main" init for handling backtraces, unwinds, stack overflows E-easy Call for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue.
Projects
None yet
Development

No branches or pull requests

5 participants