This commit allows you to write:
extern mod x = "a/b/c";
which means rustc will search in the RUST_PATH for a package with
ID a/b/c, and bind it to the name `x` if it's found.
Incidentally, move get_relative_to from back::rpath into std::path
- Made naming schemes consistent between Option, Result and Either
- Changed Options Add implementation to work like the maybe monad (return None if any of the inputs is None)
- Removed duplicate Option::get and renamed all related functions to use the term `unwrap` instead
* LLVM now has a C interface to LLVMBuildAtomicRMW
* The exception handling support for the JIT seems to have been dropped
* Various interfaces have been added or headers have changed
This is a cleanup pull request that does:
* removes `os::as_c_charp`
* moves `str::as_buf` and `str::as_c_str` into `StrSlice`
* converts some functions from `StrSlice::as_buf` to `StrSlice::as_c_str`
* renames `StrSlice::as_buf` to `StrSlice::as_imm_buf` (and adds `StrSlice::as_mut_buf` to match `vec.rs`.
* renames `UniqueStr::as_bytes_with_null_consume` to `UniqueStr::to_bytes`
* and other misc cleanups and minor optimizations
`crate => Crate`
`local => Local`
`blk => Block`
`crate_num => CrateNum`
`crate_cfg => CrateConfig`
Also, Crate and Local are not wrapped in spanned<T> anymore.
This does a number of things, but especially dramatically reduce the
number of allocations performed for operations involving attributes/
meta items:
- Converts ast::meta_item & ast::attribute and other associated enums
to CamelCase.
- Converts several standalone functions in syntax::attr into methods,
defined on two traits AttrMetaMethods & AttributeMethods. The former
is common to both MetaItem and Attribute since the latter is a thin
wrapper around the former.
- Deletes functions that are unnecessary due to iterators.
- Converts other standalone functions to use iterators and the generic
AttrMetaMethods rather than allocating a lot of new vectors (e.g. the
old code would have to allocate a new vector to use functions that
operated on &[meta_item] on &[attribute].)
- Moves the core algorithm of the #[cfg] matching to syntax::attr,
similar to find_inline_attr and find_linkage_metas.
This doesn't have much of an effect on the speed of #[cfg] stripping,
despite hugely reducing the number of allocations performed; presumably
most of the time is spent in the ast folder rather than doing attribute
checks.
Also fixes the Eq instance of MetaItem_ to correctly ignore spaces, so
that `rustc --cfg 'foo(bar)'` now works.
If the TLS key is 0-sized, then the linux linker is apparently smart enough to
put everything at the same pointer. OSX on the other hand, will reserve some
space for all of them. To get around this, the TLS key now actuall consumes
space to ensure that it gets a unique pointer
The free-standing functions in f32, f64, i8, i16, i32, i64, u8, u16,
u32, u64, float, int, and uint are replaced with generic functions in
num instead.
This means that instead of having to know everywhere what the type is, like
~~~
f64::sin(x)
~~~
You can simply write code that uses the type-generic versions in num instead, this works for all types that implement the corresponding trait in num.
~~~
num::sin(x)
~~~
Note 1: If you were previously using any of those functions, just replace them
with the corresponding function with the same name in num.
Note 2: If you were using a function that corresponds to an operator, use the
operator instead.
Note 3: This is just https://github.com/mozilla/rust/pull/7090 reopened against master.
The free-standing functions in f32, f64, i8, i16, i32, i64, u8, u16,
u32, u64, float, int, and uint are replaced with generic functions in
num instead.
If you were previously using any of those functions, just replace them
with the corresponding function with the same name in num.
Note: If you were using a function that corresponds to an operator, use
the operator instead.
I removed the `static-method-test.rs` test because it was heavily based
on `BaseIter` and there are plenty of other more complex uses of static
methods anyway.
This is another big refactoring of `trans` though this is unlikely to have much of an
impact on code size or speed.
The major change here is the implementation of a `Type` struct which is the new
home for all your LLVM `TypeRef` needs. It's a simple wrapper struct, with static
methods for constructing types, then regular methods for
manipulating/interrogating them. The purpose of this is mostly to make the code
surrounding them somewhat more ideomatic. A line like: `T_ptr(T_ptr(T_i8()))` is
now `Type::i8().ptr_to().ptr_to()`,which is much more like regular Rust code.
There are a variety of smaller changes here and there:
* Remove address spaces. At least it doesn't generate them, I haven't spent much
time looking for related code.
* Use a macro for declaring the LLVM intrinsics, makes it look much nicer.
* Make the type for a string slice actually create a named `str_slice` type in LLVM,
this makes reading the appropriate code much easier.
* Change the way struct and enum type names are generated. This just means
that a struct like `struct Foo { a: int }` now produces the IR
`%struct.Foo = type { i64 }`, which is much easier to read. Similarly, other structs
are a bit tighter to make it easier to read.
--- --- ---
This PR did get away from me a little, as I occasionally got distracted or as I fixed
up problems with unrelated code that were stopping me from continuing. One major
thing is that this PR contains the work from #7168, since that would have conflicted
with this and it was broken anyway. Sorry for bundling it like this.
Fixes#3670 and #7063
--- --- ---
EDIT: This no longer removes the llvm insn stats.
This is a bad default, because the binaries will point at an absolute
path regardless of where they are moved. This opens up a security issue
for packages, because they will attempt to load libraries from a path
that's often owned by a regular user.
Every Rust binary is currently flagged by Debian, Fedora and Arch lint
checkers as having dangerous rpaths. They don't meet the requirements to
be placed in the repositories without manually stripping this from each
binary.
The relative rpath is still enough to keep the binaries working until
they are moved relative to the crates they're linked against.
http://wiki.debian.org/RpathIssuehttps://fedoraproject.org/wiki/Packaging:Guidelines#Beware_of_Rpath
This is a bad default, because the binaries will point at an absolute
path regardless of where they are moved. This opens up a security issue
for packages, because they will attempt to load libraries from a path
that's often owned by a regular user.
Every Rust binary is currently flagged by Debian, Fedora and Arch lint
checkers as having dangerous rpaths. They don't meet the requirements to
be placed in the repositories without manually stripping this from each
binary.
The relative rpath is still enough to keep the binaries working until
they are moved relative to the crates they're linked against.
http://wiki.debian.org/RpathIssuehttps://fedoraproject.org/wiki/Packaging:Guidelines#Beware_of_Rpath
Remove all the explicit @mut-fields from CrateContext, though many
fields are still @-ptrs.
This required changing every single function call that explicitly
took a @CrateContext, so I took advantage and changed as many as I
could get away with to &-ptrs or &mut ptrs.
