Using the object (calling Rust methods from Ruby) after consuming
would raise a RuntimeError.
Also fixes some parser bugs that previously allowed invalid syntax
through in the arguments position.
The main use case for symbols is to use them as a HashMap key. However,
this introduces a GC problem – we cannot store Ruby values in the heap
without properly marking/registering them, otherwise they might get
GC'ed by Ruby unexpectedly. (In fact, this is already a problem if you
have a `Vec<VALUE>`.)
I tried to avoid introducing additional problems by pinning down any
symbols that goes thought the coercion protocol. This is probably
overly aggressive, as it would cause any dynamic symbols (e.g.
`String#to_sym`) to become un-GC-able. We can revisit this once we
have a more general-purpose system to encode pinning semantics in
the type system.
For project name with more then one '-' using `sub` will only replace
the first occurence. This cause `copy_native` to be failed due to
`File.exist?` check failed. Use `gsub` instead to fix.
- Make `Checked` an associated type. This allows `from_ruby` to carry
over additional information (useful for `Option` etc)
- Move `ToRust` into `FromRuby` to ensure both get implemented together
This switches the `to_ruby` trait method to return a `Result`, which
allows the coercion to fail.
The most obvious use case for this is to implement coercion for the
`Result` type in Rust (included in this PR), but there could be other
reasons why a coercion might fail. For example, if we were to implement
a coercion between a Rust and Ruby regular expression, the coercion
could fail if the Rust regular expression uses some Rust-specific
features that are not supported by the Ruby regular expression
implementation.
Apparently, `-m` still includes some 64 bit objects when running
dlltool. It leads to a linking error when compiling on 32-bit windows:
```
helix-runtime-0-6-3.i386.lib(dnekh.o) : fatal error LNK1112: module
machine type 'x64' conflicts with target machine type 'X86'
```
When analyzing the 32-bit lib file, you can see the 64-bit objects.
```
$ objdump -f helix-runtime-0-6-2.i386.lib
In archive helix-runtime-0-6-2.i386.lib:
dfrzt.o: file format pe-x86-64
architecture: i386:x86-64, flags 0x00000038:
HAS_DEBUG, HAS_SYMS, HAS_LOCALS
start address 0x0000000000000000
dfrzh.o: file format pe-x86-64
architecture: i386:x86-64, flags 0x00000039:
HAS_RELOC, HAS_DEBUG, HAS_SYMS, HAS_LOCALS
start address 0x0000000000000000
dfrzs00056.o: file format pe-i386
architecture: i386, flags 0x00000039:
HAS_RELOC, HAS_DEBUG, HAS_SYMS, HAS_LOCALS
start address 0x00000000
```
This fix ensures we only run the 32-bit dlltool when building the 32-bit
native lib file
There is a bug in Cargo, where .gitignore will override the include
directive in Cargo.toml. Since the .gitignore included .lib, the
helix-runtime-*.x86_64.lib and helix-runtime-*.i386.lib weren't being
packaged.
Since we already have the `Cargo.toml`, we don't actually need the
user to pass the project name. Further more, the build task doesn't
actually work correctly if you pass any name _other than_ what is
in your `Cargo.toml` (as seen in #92).
Fixes#110.