I have noticed these comments scattered across the codebase. They appear to be vestigial Emacs formatting settings and they don't appear in newer files. For the sake of consistency it's probably best to remove them.
this could probably use expansion - it just uses all of the default
options, which is usually what we want, but not always. maybe add a
separate function that takes more options?
only tested on linux/x86_64, but i got the values for other platforms
from their system header files.
no bindings for win32, because win32 doesn't include glob.h.
also, glob() takes a callback for error handling, but i'm just making
this a *c_void for now, since i don't know how to represent c calling
back into rust (if that's even currently possible).
I've added trt_field_vtable, trt_field_box, and trt_field_tydesc, and
inserted them in place of the "magic numbers" used to access trait
object fields through GEPi().
The drop block has been deprecated for quite some time. This patch series removes support for parsing it and all the related machinery that made drop work.
As a side feature of all this, I also added the ability to annote fields in structs. This allows comments to be properly associated with an individual field. However, I didn't update `rustdoc` to integrate these comment blocks into the documentation it generates.
After much discussion on IRC and #4819, we have decided to revert to the old naming of the `/` operator. This does not change its behavior. In making this change, we also have had to rename some of the methods in the `Integer` trait. Here is a list of the methods that have changed:
- `Quot::quot` -> `Div::div`
- `Rem::rem` - stays the same
- `Integer::quot_rem` -> `Integer::div_rem`
- `Integer::div` -> `Integer::div_floor`
- `Integer::modulo` -> `Integer::mod_floor`
- `Integer::div_mod` -> `Integer::div_mod_floor`
r? @brson or @thestinger : Added a change_dir_locked function to os, and use it in the
mkdir_recursive tests so that the tests don't clobber each other's
directory changes.
