Add LispObarrayRef and port intern functions to Rust#267
Add LispObarrayRef and port intern functions to Rust#267birkenfeld merged 8 commits intoremacs:masterfrom atheriel:obarray
Conversation
| } | ||
|
|
||
| /// Intern (e.g. create a symbol from) a string. | ||
| #[allow(dead_code)] |
There was a problem hiding this comment.
dead_code still needed?
| /// This is a wrapper around the C function `oblookup`. It is capable of | ||
| /// handling multibyte strings, unlike intern_1 and friends. | ||
| pub fn lookup(&self, name: LispObject) -> LispObject { | ||
| let string = if name.is_symbol() { |
There was a problem hiding this comment.
It's still better to use as_symbol which does the conversion already.
Anyway, this is basically LispObject::symbol_or_string_as_string.
| return obarray; | ||
| } | ||
|
|
||
| /* Like check_obarray, but for the global Vobarray. */ |
There was a problem hiding this comment.
Is it not possible to access the V... from Rust?
There was a problem hiding this comment.
No, it's not exposed in any .h files. I got a linker error when I tried. Is there another way?
There was a problem hiding this comment.
it looks like Vobarray is defined as #define Vobarray globals.f_Vobarray in globals.h. We set up the emacs globals as remacs_sys::globals, so it seems like if we need access to the V... variables in Rust, we can just use the global object (unless I am misunderstanding the situation).
There was a problem hiding this comment.
So... at first I thought this would work. But if I replace
let obarray = unsafe { check_vobarray() };with
let obarray = unsafe { check_obarray(globals.f_Vobarray) };The bootstrapping process fails on the first call to intern_1 in the C code, and Emacs will not build past the temacs stage, because globals.f_Vobarray is inexplicably nil at that point. This is a totally bizarre bug I haven't been able to track down. My best guess at the moment is that the globals object might have different contents for obarray during the bootstrap process and the regular Emacs incarnation.
Any thoughts on this would be appreciated.
There was a problem hiding this comment.
Ouch, that's odd. Let's open an issue and fix that, but I don't think it should hold up this PR.
Wilfred
left a comment
Wilfred
left a comment
There was a problem hiding this comment.
I like your LispObarrayRef, looks good :)
Generally looks good to me, but I agree we should use globals.f_Vobarray. Other than that, I think this is good to go ✨
Wilfred
left a comment
Wilfred
left a comment
There was a problem hiding this comment.
Sorry for the delay on this.
I think this is ready to merge. It would be nice to fix the globals.V_obarray issue, but that shouldn't delay this PR. It's nice clean Rust and makes it easier for us to build additional symbol functionality.
|
@Wilfred I've actually been working on other major symbol table work that builds on this PR, and I fixed one of the |
In order to get access to the `obarray` lisp object, I've had to add an extern function to the C sources: `check_vobarray`. Signed-off-by: Aaron Jacobs <atheriel@gmail.com>
Signed-off-by: Aaron Jacobs <atheriel@gmail.com>
This commit adds an extern function to the C code in order to get access to a previously un-exposed piece of global state: whether Emacs has set the `purify-flag'. Signed-off-by: Aaron Jacobs <atheriel@gmail.com>
Signed-off-by: Aaron Jacobs <atheriel@gmail.com>
Signed-off-by: Aaron Jacobs <atheriel@gmail.com>
|
This should be good to go now. |
birkenfeld
left a comment
birkenfeld
left a comment
There was a problem hiding this comment.
Just some minor comments.
| pub use lists::merge; | ||
| pub use buffers::Fget_buffer; | ||
| pub use buffers::Fcurrent_buffer; | ||
| pub use obarray::intern_1; |
There was a problem hiding this comment.
You're declaring intern_1 in remacs-sys but also exporting it here...
| /// This is a wrapper around the C function `oblookup`. It is capable of | ||
| /// handling multibyte strings, unlike intern_1 and friends. | ||
| pub fn lookup(&self, name: LispObject) -> LispObject { | ||
| let string = LispObject::symbol_or_string_as_string(name); |
There was a problem hiding this comment.
Should use normal method call syntax here.
Port category-table and category-table-p to rust
|
Resolved conflicts and my two suggestions. |
|
@birkenfeld Thanks for doing that, I wasn't able to get back to it this past weekend. |
5 participants
This PR ports a chunk of the obarray-related code from
lread.cto Rust, including the lisp functionsinternandintern-soft. I had to add some extern functions to the C code in order to get access to some global state.