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

Experiment with interpreted glue #527

Closed
pcwalton opened this issue Jun 21, 2011 · 3 comments
Closed

Experiment with interpreted glue #527

pcwalton opened this issue Jun 21, 2011 · 3 comments

Comments

@pcwalton
Copy link
Contributor

We spend lots of time generating glue, even for stuff like cmp glue that is cold. We could emit a declarative description of the type and have a generic "cmp" function that uses that description.

@msullivan
Copy link
Contributor

That seems like it will trade compile time for run time, which seems like not something we want to do? On the other hand, it might be a win because of cache effects... Hm.

@pcwalton
Copy link
Contributor Author

Yeah, I think it's worth trying. I think this is what OCaml does at least. At the very least it should help -O0.

@graydon
Copy link
Contributor

graydon commented Aug 25, 2011

I believe this 'experiment' is successful, yes? Closing.

@graydon graydon closed this as completed Aug 25, 2011
arielb1 pushed a commit to arielb1/rust that referenced this issue Apr 10, 2015
Corrected some typos for RFC 114
keeperofdakeys pushed a commit to keeperofdakeys/rust that referenced this issue Dec 12, 2017
add tmpnam and pthread_exit

tmpnam and readdir are trivial IMO.

About the `pthread_create` change: It needs `unsafe` for passing `C` functions to pthread_create (with rust functions the omission of `unsafe` is working of course).

`bindgen` produces this function definition:

```
pub fn pthread_create(arg1: *mut pthread_t,
                      arg2: *const pthread_attr_t,
                      arg3: Option<unsafe extern "C" fn(arg1: *mut c_void) -> *mut c_void>,
                      arg4: *mut c_void) -> c_int;
```

So it would add an additional `Option` around the function. But that would break existing code which uses `libc::pthread_create` and what use is it to call pthread_create without any function pointer, so I left `Option` out.

For reference: I also opened a [stackoverflow question](http://stackoverflow.com/questions/42284562) where the answers were also suggesting adding `unsafe` to the function definition.
kazcw pushed a commit to kazcw/rust that referenced this issue Oct 23, 2018
The `proc_macro` feature has stabilized in the compiler and usage of it largely
needs to switch to `use_extern_macros` now.
pdietl pushed a commit to pdietl/rust that referenced this issue Apr 23, 2020
bors pushed a commit to rust-lang-ci/rust that referenced this issue Oct 26, 2020
Bumps [proc-macro2](https://github.com/alexcrichton/proc-macro2) from 0.4.29 to 0.4.30.
- [Release notes](https://github.com/alexcrichton/proc-macro2/releases)
- [Commits](dtolnay/proc-macro2@0.4.29...0.4.30)

Signed-off-by: dependabot[bot] <support@dependabot.com>
celinval pushed a commit to celinval/rust-dev that referenced this issue Jun 4, 2024
…ang#527)

Co-authored-by: Adrian Palacios <73246657+adpaco-aws@users.noreply.github.com>
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

No branches or pull requests

3 participants