Commit Graph

469 Commits

Author SHA1 Message Date
Alex Crichton
d0a80cca6c rpass/cfail: Update field privacy where necessary 2014-03-31 15:47:36 -07:00
Alex Crichton
a5681d2590 Bump version to 0.10 2014-03-31 14:40:44 -07:00
Marvin Löbel
c356e3ba6a Removed deprecated functions map and flat_map for vectors and slices. 2014-03-30 03:47:04 +02:00
Brian Anderson
451e8c1c61 Convert most code to new inner attribute syntax.
Closes #2569
2014-03-28 17:12:21 -07:00
Flavio Percoco
81ec1f3c18 Rename Pod into Copy
Summary:
So far, we've used the term POD "Plain Old Data" to refer to types that
can be safely copied. However, this term is not consistent with the
other built-in bounds that use verbs instead. This patch renames the Pod
kind into Copy.

RFC: 0003-opt-in-builtin-traits

Test Plan: make check

Reviewers: cmr

Differential Revision: http://phabricator.octayn.net/D3
2014-03-28 10:34:02 +01:00
Alex Crichton
bb9172d7b5 Fix fallout of removing default bounds
This is all purely fallout of getting the previous commit to compile.
2014-03-27 10:14:50 -07:00
Eduard Burtescu
087ec2aa24 Implement cross-crate support for autoderef.
Closes #13044.
2014-03-23 01:11:39 +02:00
bors
7e7a5e3d3e auto merge of #13076 : FlaPer87/rust/remove-freeze, r=alexcrichton
This PR removes the `Freeze` kind and the `NoFreeze` marker completely.

Fixes #12577

cc @nikomatsakis r?
2014-03-22 13:01:52 -07:00
Alex Crichton
76f0b1ad1f test: Fix fallout of removing get() 2014-03-22 08:48:20 -07:00
Flavio Percoco
90e9d8ee62 test: Remove Freeze / NoFreeze from tests 2014-03-22 15:47:34 +01:00
bors
069cede305 auto merge of #13036 : alexcrichton/rust/atomics, r=alexcrichton
Closes #11583, rebasing of #12430 now that we've got `Share` and better analysis with statics.
2014-03-21 21:31:42 -07:00
Huon Wilson
6d778ff610 Remove outdated and unnecessary std::vec_ng::Vec imports.
(And fix some tests.)
2014-03-22 01:08:57 +11:00
Patrick Walton
af79a5aa7d test: Make manual changes to deal with the fallout from removal of
`~[T]` in test, libgetopts, compiletest, librustdoc, and libnum.
2014-03-21 23:37:21 +11:00
Patrick Walton
579eb2400b test: Automatically remove all ~[T] from tests. 2014-03-21 23:37:21 +11:00
Brian Anderson
eb25c42fc8 std: Make the generic atomics take unsafe pointers
These mutate values behind references that are Freeze, which is not
allowed.
2014-03-20 13:33:43 -07:00
Brian Anderson
f3fef9a649 std: Make atomics immutable. #11583
In Rust, the strongest guarantee that `&mut` provides is that the memory
pointed to is *not aliased*, whereas `&`'s guarantees are much weaker:
that the value can be aliased, and may be mutated under proper precautions
(interior mutability).

Our atomics though use `&mut` for mutation even while creating multiple
aliases, so this changes them to use 'interior mutability', mutating
through immutable references.
2014-03-20 09:44:29 -07:00
Flavio Percoco
12ecafb31d Replace Freeze bounds with Share bounds 2014-03-20 10:16:55 +01:00
Nick Cameron
3301223c99 Fix linkage1 test which fails due to --as-needed
It appears that the --as-needed flag to linkers will not pull in a dynamic library unless it satisfies a non weak undefined symbol. The linkage1 test was creating a dynamic library where it was only used for a weak-symbol as part of an executable, so the dynamic library was getting discarded.

This commit adds another symbol to the library which satisfies a strong undefined symbol, so the library is pulled in to resolve the weak reference.
2014-03-18 13:48:12 -07:00
Alex Crichton
cc6ec8df95 log: Introduce liblog, the old std::logging
This commit moves all logging out of the standard library into an external
crate. This crate is the new crate which is responsible for all logging macros
and logging implementation. A few reasons for this change are:

* The crate map has always been a bit of a code smell among rust programs. It
  has difficulty being loaded on almost all platforms, and it's used almost
  exclusively for logging and only logging. Removing the crate map is one of the
  end goals of this movement.

* The compiler has a fair bit of special support for logging. It has the
  __log_level() expression as well as generating a global word per module
  specifying the log level. This is unfairly favoring the built-in logging
  system, and is much better done purely in libraries instead of the compiler
  itself.

* Initialization of logging is much easier to do if there is no reliance on a
  magical crate map being available to set module log levels.

* If the logging library can be written outside of the standard library, there's
  no reason that it shouldn't be. It's likely that we're not going to build the
  highest quality logging library of all time, so third-party libraries should
  be able to provide just as high-quality logging systems as the default one
  provided in the rust distribution.

With a migration such as this, the change does not come for free. There are some
subtle changes in the behavior of liblog vs the previous logging macros:

* The core change of this migration is that there is no longer a physical
  log-level per module. This concept is still emulated (it is quite useful), but
  there is now only a global log level, not a local one. This global log level
  is a reflection of the maximum of all log levels specified. The previously
  generated logging code looked like:

    if specified_level <= __module_log_level() {
        println!(...)
    }

  The newly generated code looks like:

    if specified_level <= ::log::LOG_LEVEL {
        if ::log::module_enabled(module_path!()) {
            println!(...)
        }
    }

  Notably, the first layer of checking is still intended to be "super fast" in
  that it's just a load of a global word and a compare. The second layer of
  checking is executed to determine if the current module does indeed have
  logging turned on.

  This means that if any module has a debug log level turned on, all modules
  with debug log levels get a little bit slower (they all do more expensive
  dynamic checks to determine if they're turned on or not).

  Semantically, this migration brings no change in this respect, but
  runtime-wise, this will have a perf impact on some code.

* A `RUST_LOG=::help` directive will no longer print out a list of all modules
  that can be logged. This is because the crate map will no longer specify the
  log levels of all modules, so the list of modules is not known. Additionally,
  warnings can no longer be provided if a malformed logging directive was
  supplied.

The new "hello world" for logging looks like:

    #[phase(syntax, link)]
    extern crate log;

    fn main() {
        debug!("Hello, world!");
    }
2014-03-15 22:26:36 -07:00
Alex Crichton
58e4ab2b33 extra: Put the nail in the coffin, delete libextra
This commit shreds all remnants of libextra from the compiler and standard
distribution. Two modules, c_vec/tempfile, were moved into libstd after some
cleanup, and the other modules were moved to separate crates as seen fit.

Closes #8784
Closes #12413
Closes #12576
2014-03-14 13:59:02 -07:00
Alex Crichton
7858065113 std: Rename Chan/Port types and constructor
* Chan<T> => Sender<T>
* Port<T> => Receiver<T>
* Chan::new() => channel()
* constructor returns (Sender, Receiver) instead of (Receiver, Sender)
* local variables named `port` renamed to `rx`
* local variables named `chan` renamed to `tx`

Closes #11765
2014-03-13 13:23:29 -07:00
Michael Darakananda
f079c94f72 rustc: Remove matching on ~str from the language
The `~str` type is not long for this world as it will be superseded by the
soon-to-come DST changes for the language. The new type will be
`~Str`, and matching over the allocation will no longer be supported.
Matching on `&str` will continue to work, in both a pre and post DST world.
2014-03-12 19:17:36 -04:00
bors
9f3ebd8fc5 auto merge of #12556 : alexcrichton/rust/weak-linkage, r=brson
It is often convenient to have forms of weak linkage or other various types of
linkage. Sadly, just using these flavors of linkage are not compatible with
Rust's typesystem and how it considers some pointers to be non-null.

As a compromise, this commit adds support for weak linkage to external symbols,
but it requires that this is only placed on extern statics of type `*T`.
Codegen-wise, we get translations like:

```rust
    // rust code
    extern {
        #[linkage = "extern_weak"]
        static foo: *i32;
    }

    // generated IR
    @foo = extern_weak global i32
    @_some_internal_symbol = internal global *i32 @foo
```

All references to the rust value of `foo` then reference `_some_internal_symbol`
instead of the symbol `_foo` itself. This allows us to guarantee that the
address of `foo` will never be null while the value may sometimes be null.

An example was implemented in `std::rt::thread` to determine if
`__pthread_get_minstack()` is available at runtime, and a test is checked in to
use it for a static value as well. Function pointers a little odd because you
still need to transmute the pointer value to a function pointer, but it's
thankfully better than not having this capability at all.

Thanks to @bnoordhuis for the original patch, most of this work is still his!
2014-03-11 09:56:57 -07:00
Alex Crichton
699b33d060 rustc: Support various flavors of linkages
It is often convenient to have forms of weak linkage or other various types of
linkage. Sadly, just using these flavors of linkage are not compatible with
Rust's typesystem and how it considers some pointers to be non-null.

As a compromise, this commit adds support for weak linkage to external symbols,
but it requires that this is only placed on extern statics of type `*T`.
Codegen-wise, we get translations like:

    // rust code
    extern {
        #[linkage = "extern_weak"]
        static foo: *i32;
    }

    // generated IR
    @foo = extern_weak global i32
    @_some_internal_symbol = internal global *i32 @foo

All references to the rust value of `foo` then reference `_some_internal_symbol`
instead of the symbol `_foo` itself. This allows us to guarantee that the
address of `foo` will never be null while the value may sometimes be null.

An example was implemented in `std::rt::thread` to determine if
`__pthread_get_minstack()` is available at runtime, and a test is checked in to
use it for a static value as well. Function pointers a little odd because you
still need to transmute the pointer value to a function pointer, but it's
thankfully better than not having this capability at all.
2014-03-11 08:25:42 -07:00
Steven Fackler
eb4cbd55a8 Add an ItemModifier syntax extension type
Where ItemDecorator creates new items given a single item, ItemModifier
alters the tagged item in place. The expansion rules for this are a bit
weird, but I think are the most reasonable option available.

When an item is expanded, all ItemModifier attributes are stripped from
it and the item is folded through all ItemModifiers. At that point, the
process repeats until there are no ItemModifiers in the new item.
2014-03-11 00:28:25 -07:00
Alex Crichton
13e10f5b7e test: Add some tests for closed issues
Closes #6738
Closes #7061
Closes #7899
Closes #9719
Closes #10028
Closes #10228
Closes #10401
Closes #11192
Closes #11508
Closes #11529
Closes #11873
Closes #11925
2014-03-06 10:45:08 -08:00
Alex Crichton
02882fbd7e std: Change assert_eq!() to use {} instead of {:?}
Formatting via reflection has been a little questionable for some time now, and
it's a little unfortunate that one of the standard macros will silently use
reflection when you weren't expecting it. This adds small bits of code bloat to
libraries, as well as not always being necessary. In light of this information,
this commit switches assert_eq!() to using {} in the error message instead of
{:?}.

In updating existing code, there were a few error cases that I encountered:

* It's impossible to define Show for [T, ..N]. I think DST will alleviate this
  because we can define Show for [T].
* A few types here and there just needed a #[deriving(Show)]
* Type parameters needed a Show bound, I often moved this to `assert!(a == b)`
* `Path` doesn't implement `Show`, so assert_eq!() cannot be used on two paths.
  I don't think this is much of a regression though because {:?} on paths looks
  awful (it's a byte array).

Concretely speaking, this shaved 10K off a 656K binary. Not a lot, but sometime
significant for smaller binaries.
2014-02-28 23:01:54 -08:00
Alex Crichton
ec57db083f rustc: Add the concept of a Strict Version Hash
This new SVH is used to uniquely identify all crates as a snapshot in time of
their ABI/API/publicly reachable state. This current calculation is just a hash
of the entire crate's AST. This is obviously incorrect, but it is currently the
reality for today.

This change threads through the new Svh structure which originates from crate
dependencies. The concept of crate id hash is preserved to provide efficient
matching on filenames for crate loading. The inspected hash once crate metadata
is opened has been changed to use the new Svh.

The goal of this hash is to identify when upstream crates have changed but
downstream crates have not been recompiled. This will prevent the def-id drift
problem where upstream crates were recompiled, thereby changing their metadata,
but downstream crates were not recompiled.

In the future this hash can be expanded to exclude contents of the AST like doc
comments, but limitations in the compiler prevent this change from being made at
this time.

Closes #10207
2014-02-28 10:48:04 -08:00
Alex Crichton
9cc26cfdf4 test: Clean out the test suite a bit
This updates a number of ignore-test tests, and removes a few completely
outdated tests due to the feature being tested no longer being supported.

This brings a number of bench/shootout tests up to date so they're compiling
again. I make no claims to the performance of these benchmarks, it's just nice
to not have bitrotted code.

Closes #2604
Closes #9407
2014-02-25 09:21:09 -08:00
bors
672097753a auto merge of #12412 : alexcrichton/rust/deriving-show, r=huonw
This commit removes deriving(ToStr) in favor of deriving(Show), migrating all impls of ToStr to fmt::Show.

Most of the details can be found in the first commit message.

Closes #12477
2014-02-24 04:11:53 -08:00
Alex Crichton
b78b749810 Remove all ToStr impls, add Show impls
This commit changes the ToStr trait to:

    impl<T: fmt::Show> ToStr for T {
        fn to_str(&self) -> ~str { format!("{}", *self) }
    }

The ToStr trait has been on the chopping block for quite awhile now, and this is
the final nail in its coffin. The trait and the corresponding method are not
being removed as part of this commit, but rather any implementations of the
`ToStr` trait are being forbidden because of the generic impl. The new way to
get the `to_str()` method to work is to implement `fmt::Show`.

Formatting into a `&mut Writer` (as `format!` does) is much more efficient than
`ToStr` when building up large strings. The `ToStr` trait forces many
intermediate allocations to be made while the `fmt::Show` trait allows
incremental buildup in the same heap allocated buffer. Additionally, the
`fmt::Show` trait is much more extensible in terms of interoperation with other
`Writer` instances and in more situations. By design the `ToStr` trait requires
at least one allocation whereas the `fmt::Show` trait does not require any
allocations.

Closes #8242
Closes #9806
2014-02-23 20:51:56 -08:00
Nick Cameron
317a253b22 All uses of extern fn should mean extern "C" fn. Closes #9309. 2014-02-24 13:24:57 +13:00
bors
551da06157 auto merge of #12311 : brson/rust/unstable, r=alexcrichton
With the stability attributes we can put public-but unstable modules next to others, so this moves `intrinsics` and `raw` out of the `unstable` module (and marks both as `#[experimental]`).
2014-02-23 02:21:53 -08:00
Brian Anderson
4d10bdc5b9 std: Move intrinsics to std::intrinsics.
Issue #1457
2014-02-23 01:07:53 -08:00
Alex Crichton
2a14e084cf Move std::{trie, hashmap} to libcollections
These two containers are indeed collections, so their place is in
libcollections, not in libstd. There will always be a hash map as part of the
standard distribution of Rust, but by moving it out of the standard library it
makes libstd that much more portable to more platforms and environments.

This conveniently also removes the stuttering of 'std::hashmap::HashMap',
although 'collections::HashMap' is only one character shorter.
2014-02-23 00:35:11 -08:00
Alex Crichton
351d0ffaa1 Force all lang items to be reachable
This prevents linker errors as found in #11591

Closes #11591
2014-02-22 10:29:06 -08:00
Alex Crichton
afa5f574ff Re-work loading crates with nicer errors
This commit rewrites crate loading internally in attempt to look at less
metadata and provide nicer errors. The loading is now split up into a few
stages:

1. Collect a mapping of (hash => ~[Path]) for a set of candidate libraries for a
   given search. The hash is the hash in the filename and the Path is the
   location of the library in question. All candidates are filtered based on
   their prefix/suffix (dylib/rlib appropriate) and then the hash/version are
   split up and are compared (if necessary).

   This means that if you're looking for an exact hash of library you don't have
   to open up the metadata of all libraries named the same, but also in your
   path.

2. Once this mapping is constructed, each (hash, ~[Path]) pair is filtered down
   to just a Path. This is necessary because the same rlib could show up twice
   in the path in multiple locations. Right now the filenames are based on just
   the crate id, so this could be indicative of multiple version of a crate
   during one crate_id lifetime in the path. If multiple duplicate crates are
   found, an error is generated.

3. Now that we have a mapping of (hash => Path), we error on multiple versions
   saying that multiple versions were found. Only if there's one (hash => Path)
   pair do we actually return that Path and its metadata.

With this restructuring, it restructures code so errors which were assertions
previously are now first-class errors. Additionally, this should read much less
metadata with lots of crates of the same name or same version in a path.

Closes #11908
2014-02-20 17:48:32 -08:00
Alex Crichton
35c6e22fab Tweak how preference factors into linkage
The new methodology can be found in the re-worded comment, but the gist of it is
that -C prefer-dynamic doesn't turn off static linkage. The error messages
should also be a little more sane now.

Closes #12133
2014-02-19 08:33:08 -08:00
Alex Crichton
a41b0c2529 extern mod => extern crate
This was previously implemented, and it just needed a snapshot to go through
2014-02-14 22:55:21 -08:00
Alex Crichton
359ac360a4 Register new snapshots
This enables the parser error for `extern mod` => `extern crate` transitions.
2014-02-14 22:55:20 -08:00
Steven Fackler
6b429d07c9 Stop unloading syntax libraries
Externally loaded libraries are able to do things that cause references
to them to survive past the expansion phase (e.g. creating @-box cycles,
launching a task or storing something in task local data). As such, the
library has to stay loaded for the lifetime of the process.
2014-02-13 12:50:24 -08:00
Florian Hahn
f62460c1f5 Change xfail directives in compiletests to ignore, closes #11363 2014-02-11 18:23:20 +01:00
Derek Guenther
730bdb6403 Added tests to make tidy 2014-02-07 12:49:24 -06:00
bors
87fe3ccf09 auto merge of #12039 : alexcrichton/rust/no-conditions, r=brson
This has been a long time coming. Conditions in rust were initially envisioned
as being a good alternative to error code return pattern. The idea is that all
errors are fatal-by-default, and you can opt-in to handling the error by
registering an error handler.

While sounding nice, conditions ended up having some unforseen shortcomings:

* Actually handling an error has some very awkward syntax:

        let mut result = None;                                        
        let mut answer = None;                                        
        io::io_error::cond.trap(|e| { result = Some(e) }).inside(|| { 
            answer = Some(some_io_operation());                       
        });                                                           
        match result {                                                
            Some(err) => { /* hit an I/O error */ }                   
            None => {                                                 
                let answer = answer.unwrap();                         
                /* deal with the result of I/O */                     
            }                                                         
        }                                                             

  This pattern can certainly use functions like io::result, but at its core
  actually handling conditions is fairly difficult

* The "zero value" of a function is often confusing. One of the main ideas
  behind using conditions was to change the signature of I/O functions. Instead
  of read_be_u32() returning a result, it returned a u32. Errors were notified
  via a condition, and if you caught the condition you understood that the "zero
  value" returned is actually a garbage value. These zero values are often
  difficult to understand, however.

  One case of this is the read_bytes() function. The function takes an integer
  length of the amount of bytes to read, and returns an array of that size. The
  array may actually be shorter, however, if an error occurred.

  Another case is fs::stat(). The theoretical "zero value" is a blank stat
  struct, but it's a little awkward to create and return a zero'd out stat
  struct on a call to stat().

  In general, the return value of functions that can raise error are much more
  natural when using a Result as opposed to an always-usable zero-value.

* Conditions impose a necessary runtime requirement on *all* I/O. In theory I/O
  is as simple as calling read() and write(), but using conditions imposed the
  restriction that a rust local task was required if you wanted to catch errors
  with I/O. While certainly an surmountable difficulty, this was always a bit of
  a thorn in the side of conditions.

* Functions raising conditions are not always clear that they are raising
  conditions. This suffers a similar problem to exceptions where you don't
  actually know whether a function raises a condition or not. The documentation
  likely explains, but if someone retroactively adds a condition to a function
  there's nothing forcing upstream users to acknowledge a new point of task
  failure.

* Libaries using I/O are not guaranteed to correctly raise on conditions when an
  error occurs. In developing various I/O libraries, it's much easier to just
  return `None` from a read rather than raising an error. The silent contract of
  "don't raise on EOF" was a little difficult to understand and threw a wrench
  into the answer of the question "when do I raise a condition?"

Many of these difficulties can be overcome through documentation, examples, and
general practice. In the end, all of these difficulties added together ended up
being too overwhelming and improving various aspects didn't end up helping that
much.

A result-based I/O error handling strategy also has shortcomings, but the
cognitive burden is much smaller. The tooling necessary to make this strategy as
usable as conditions were is much smaller than the tooling necessary for
conditions.

Perhaps conditions may manifest themselves as a future entity, but for now
we're going to remove them from the standard library.

Closes #9795
Closes #8968
2014-02-06 17:11:33 -08:00
Alex Crichton
454882dcb7 Remove std::condition
This has been a long time coming. Conditions in rust were initially envisioned
as being a good alternative to error code return pattern. The idea is that all
errors are fatal-by-default, and you can opt-in to handling the error by
registering an error handler.

While sounding nice, conditions ended up having some unforseen shortcomings:

* Actually handling an error has some very awkward syntax:

    let mut result = None;
    let mut answer = None;
    io::io_error::cond.trap(|e| { result = Some(e) }).inside(|| {
        answer = Some(some_io_operation());
    });
    match result {
        Some(err) => { /* hit an I/O error */ }
        None => {
            let answer = answer.unwrap();
            /* deal with the result of I/O */
        }
    }

  This pattern can certainly use functions like io::result, but at its core
  actually handling conditions is fairly difficult

* The "zero value" of a function is often confusing. One of the main ideas
  behind using conditions was to change the signature of I/O functions. Instead
  of read_be_u32() returning a result, it returned a u32. Errors were notified
  via a condition, and if you caught the condition you understood that the "zero
  value" returned is actually a garbage value. These zero values are often
  difficult to understand, however.

  One case of this is the read_bytes() function. The function takes an integer
  length of the amount of bytes to read, and returns an array of that size. The
  array may actually be shorter, however, if an error occurred.

  Another case is fs::stat(). The theoretical "zero value" is a blank stat
  struct, but it's a little awkward to create and return a zero'd out stat
  struct on a call to stat().

  In general, the return value of functions that can raise error are much more
  natural when using a Result as opposed to an always-usable zero-value.

* Conditions impose a necessary runtime requirement on *all* I/O. In theory I/O
  is as simple as calling read() and write(), but using conditions imposed the
  restriction that a rust local task was required if you wanted to catch errors
  with I/O. While certainly an surmountable difficulty, this was always a bit of
  a thorn in the side of conditions.

* Functions raising conditions are not always clear that they are raising
  conditions. This suffers a similar problem to exceptions where you don't
  actually know whether a function raises a condition or not. The documentation
  likely explains, but if someone retroactively adds a condition to a function
  there's nothing forcing upstream users to acknowledge a new point of task
  failure.

* Libaries using I/O are not guaranteed to correctly raise on conditions when an
  error occurs. In developing various I/O libraries, it's much easier to just
  return `None` from a read rather than raising an error. The silent contract of
  "don't raise on EOF" was a little difficult to understand and threw a wrench
  into the answer of the question "when do I raise a condition?"

Many of these difficulties can be overcome through documentation, examples, and
general practice. In the end, all of these difficulties added together ended up
being too overwhelming and improving various aspects didn't end up helping that
much.

A result-based I/O error handling strategy also has shortcomings, but the
cognitive burden is much smaller. The tooling necessary to make this strategy as
usable as conditions were is much smaller than the tooling necessary for
conditions.

Perhaps conditions may manifest themselves as a future entity, but for now
we're going to remove them from the standard library.

Closes #9795
Closes #8968
2014-02-06 15:48:56 -08:00
Eduard Burtescu
b2d30b72bf Removed @self and @Trait. 2014-02-07 00:38:33 +02:00
bors
53864ce512 auto merge of #12025 : lilac/rust/feature-gate-quote, r=brson
Closes #11630.
2014-02-05 01:06:32 -08:00
bors
1bcc73fe9d auto merge of #12023 : nick29581/rust/err_res, r=alexcrichton
closes #3512
2014-02-04 23:46:37 -08:00
bors
4509b49451 auto merge of #12018 : alexcrichton/rust/triage, r=sfackler
Mostly just test suite modifications.
2014-02-04 21:46:35 -08:00
Alex Crichton
8a1dda92ba Adding tests for closed issues
Closes #5521
Closes #9396
Closes #10714
2014-02-04 18:05:13 -08:00
Nick Cameron
8d8c7835f7 Check for trait impl conflicts across crates 2014-02-05 08:50:05 +13:00
James Deng
124938bcf5 Replaced with a single "quote" feature gate. 2014-02-04 22:03:00 +11:00
James Deng
38f2526beb Feature gate all quasi-quoting macros. 2014-02-04 16:35:57 +11:00
Alex Crichton
b00147a99b Add an AtomicU64 type to std::sync::atomics
This also generalizes all atomic intrinsics over T so we'll be able to add u8
atomics if we really feel the need to (do we really want to?)
2014-02-03 12:04:30 -08:00
bors
362cbbe01c auto merge of #11932 : dmanescu/rust/11741-stability-cross-crate, r=alexcrichton
Fixes #11741
Added tests and removed xfail-fast from run-pass/simd-experimental which is now fixed (see #11738).
2014-02-01 05:31:24 -08:00
David Manescu
bc8983a3fa Handle attributes on cross-crate tuple-structs correctly
Fixes #11741
2014-01-31 22:16:39 +11:00
Eduard Burtescu
7d967741c3 Implement default type parameters in generics. 2014-01-30 19:28:41 +02:00
Scott Lawrence
3dbc1c34e6 Remove do keyword from test/ 2014-01-29 09:15:42 -05:00
Felix S. Klock II
b315aba7e4 test case for issue #10031. 2014-01-27 21:15:18 +01:00
Alex Crichton
4d6836f418 Fix privacy fallout from previous change 2014-01-26 11:03:13 -08:00
Alex Crichton
31ac9c4288 Change private structs to have private fields by default
This was the original intention of the privacy of structs, and it was
erroneously implemented before. A pub struct will now have default-pub fields,
and a non-pub struct will have default-priv fields. This essentially brings
struct fields in line with enum variants in terms of inheriting visibility.

As usual, extraneous modifiers to visibility are disallowed depend on the case
that you're dealing with.

Closes #11522
2014-01-26 10:37:08 -08:00
Steven Fackler
ab5bbd3c17 Simplify and rename macro API
Now that procedural macros can be implemented outside of the compiler,
it's more important to have a reasonable API to work with. Here are the
basic changes:

* Rename SyntaxExpanderTTTrait to MacroExpander, SyntaxExpanderTT to
    BasicMacroExpander, etc. I think "procedural macro" is the right
    term for these now, right? The other option would be SynExtExpander
    or something like that.

* Stop passing the SyntaxContext to extensions. This was only ever used
    by macro_rules, which doesn't even use it anymore. I can't think of
    a context in which an external extension would need it, and removal
    allows the API to be significantly simpler - no more
    SyntaxExpanderTTItemExpanderWithoutContext wrappers to worry about.
2014-01-25 13:55:39 -08:00
Steven Fackler
d049c27f5b Scan the entire crate for exported macros
It previously missed anything in an inner module.
2014-01-20 09:22:46 -08:00
bors
6d58c70fb3 auto merge of #11628 : alexcrichton/rust/issue-11593, r=brson
Turns out we were just forgetting to encode the privacy for trais, and
everything without privacy defaults to public!

Closes #11593
2014-01-19 00:36:48 -08:00
Alex Crichton
d37e2f79cc Disallow implementation of cross-crate priv traits
Turns out we were just forgetting to encode the privacy for trais, and
everything without privacy defaults to public!

Closes #11593
2014-01-18 10:58:01 -08:00
Alex Crichton
bd469341eb test: Add the ability to force a host target
The new macro loading infrastructure needs the ability to force a
procedural-macro crate to be built with the host architecture rather than the
target architecture (because the compiler is just about to dlopen it).
2014-01-17 11:13:22 -08:00
Steven Fackler
328b47d837 Load macros from external modules 2014-01-16 15:01:48 -08:00
Brendan Zabarauskas
4fc0452ace Remove re-exports of std::io::stdio::{print, println} in the prelude.
The `print!` and `println!` macros are now the preferred method of printing, and so there is no reason to export the `stdio` functions in the prelude. The functions have also been replaced by their macro counterparts in the tutorial and other documentation so that newcomers don't get confused about what they should be using.
2014-01-11 10:46:00 +11:00
Patrick Walton
c3694d732e test: De-@mut the test suite 2014-01-03 14:02:01 -08:00
Alex Crichton
0daaeab244 Conservatively export all trait methods and impls
The comments have more information as to why this is done, but the basic idea is
that finding an exported trait is actually a fairly difficult problem. The true
answer lies in whether a trait is ever referenced from another exported method,
and right now this kind of analysis doesn't exist, so the conservative answer of
"yes" is always returned to answer whether a trait is exported.

Closes #11224
Closes #11225
2013-12-31 12:42:13 -08:00
Brian Anderson
26f1b4db11 rustc: Add a lint for the obsolete crate-level link attribute 2013-12-23 21:04:01 -08:00
Patrick Walton
b982f08a66 librustc: Add missing case for the Pod bound in tydecode. 2013-12-19 14:13:19 -08:00
Corey Richardson
dee1107571 Rename pkgid to crate_id
Closes #11035
2013-12-19 10:10:23 -05:00
bors
6d2e61bc6c auto merge of #11012 : alexcrichton/rust/needstest, r=alexcrichton
Closes #5806
Closes #8259
Closes #8578
Closes #8851
Closes #10412
2013-12-18 10:36:51 -08:00
Alex Crichton
3e04d2e3db Adding tests for closed issues
Closes #5806
Closes #5950
Closes #7178
Closes #8259
Closes #8578
Closes #8851
Closes #9129
Closes #10412
2013-12-18 09:12:04 -08:00
Alex Crichton
529e268ab9 Fallout of rewriting std::comm 2013-12-16 17:47:11 -08:00
Erik Price
5731ca3078 Make 'self lifetime illegal.
Also remove all instances of 'self within the codebase.

This fixes #10889.
2013-12-11 10:54:06 -08:00
Jack Moffitt
b349036e5f Make crate hash stable and externally computable.
This replaces the link meta attributes with a pkgid attribute and uses a hash
of this as the crate hash. This makes the crate hash computable by things
other than the Rust compiler. It also switches the hash function ot SHA1 since
that is much more likely to be available in shell, Python, etc than SipHash.

Fixes #10188, #8523.
2013-12-10 17:04:24 -07:00
David Renshaw
d99efe84df encode trait lifetime params in metadata to allow cross-crate usage 2013-12-08 18:09:31 -05:00
Alex Crichton
7a2415f0e4 Fix a bug in exporting trait implementations
I used the wrong condition where I was looking for "is this method public or is
this implementation a trait" rather than what was being checked.
2013-12-03 15:15:17 -08:00
Alex Crichton
0dc9f62779 Resume propagation of linking to native dylibs
The reasons for this are outlined in issue #10743 as well as the comment I have
now placed in the code.

Closes #10743
2013-12-03 08:19:33 -08:00
bors
4252a24ae1 auto merge of #10528 : alexcrichton/rust/static-linking-v2, r=pcwalton
In this series of commits, I've implemented static linking for rust. The scheme I implemented was the same as my [mailing list post](https://mail.mozilla.org/pipermail/rust-dev/2013-November/006686.html).

The commits have more details to the nitty gritty of what went on. I've rebased this on top of my native mutex pull request (#10479), but I imagine that it will land before this lands, I just wanted to pre-emptively get all the rebase conflicts out of the way (becuase this is reorganizing building librustrt as well).

Some contentious points I want to make sure are all good:

* I've added more "compiler chooses a default" behavior than I would like, I want to make sure that this is all very clearly outlined in the code, and if not I would like to remove behavior or make it clearer.
* I want to make sure that the new "fancy suite" tests are ok (using make/python instead of another rust crate)

If we do indeed pursue this, I would be more than willing to write up a document describing how linking in rust works. I believe that this behavior should be very understandable, and the compiler should never hinder someone just because linking is a little fuzzy.
2013-11-30 14:41:40 -08:00
Corey Richardson
572635b76f Wrap the return value of the type_id intrinsic in an opaque box
Closes #10594
2013-11-30 02:58:36 -05:00
Alex Crichton
9fbba7b2ee Statically link librustrt to libstd
This commit alters the build process of the compiler to build a static
librustrt.a instead of a dynamic version. This means that we can stop
distributing librustrt as well as default linking against it in the compiler.

This also means that if you attempt to build rust code without libstd, it will
no longer work if there are any landing pads in play. The reason for this is
that LLVM and rustc will emit calls to the various upcalls in librustrt used to
manage exception handling. In theory we could split librustrt into librustrt and
librustupcall. We would then distribute librustupcall and link to it for all
programs using landing pads, but I would rather see just one librustrt artifact
and simplify the build process.

The major benefit of doing this is that building a static rust library for use
in embedded situations all of a sudden just became a whole lot more feasible.

Closes #3361
2013-11-29 18:36:14 -08:00
Patrick Walton
f571e46ddb test: Remove non-procedure uses of do from compiletest, libstd tests,
compile-fail tests, run-fail tests, and run-pass tests.
2013-11-26 08:25:27 -08:00
Patrick Walton
9e610573ba librustc: Remove remaining uses of &fn() in favor of ||. 2013-11-26 08:20:58 -08:00
Patrick Walton
406813957b test: Remove most uses of &fn() from the tests. 2013-11-26 08:19:00 -08:00
bors
cd9069ca73 auto merge of #10583 : alexcrichton/rust/privacy-reexport, r=pcwalton
I added a test case which does not compile today, and required changes on
privacy's side of things to get right. Additionally, this moves a good bit of
logic which did not belong in reachability into privacy.

All of reachability should solely be responsible for determining what the
reachable surface area of a crate is given the exported surface area (where the
exported surface area is that which is usable by external crates).

Privacy will now correctly figure out what's exported by deeply looking
through reexports. Previously if a module were reexported under another name,
nothing in the module would actually get exported in the executable. I also
consolidated the phases of privacy to be clearer about what's an input to what.
The privacy checking pass no longer uses the notion of an "all public" path, and
the embargo visitor is no longer an input to the checking pass.

Currently the embargo visitor is built as a saturating analysis because it's
unknown what portions of the AST are going to get re-exported.

This also cracks down on exported methods from impl blocks and trait blocks. If you implement a private trait, none of the symbols are exported, and if you have an impl for a private type none of the symbols are exported either. On the other hand, if you implement a public trait for a private type, the symbols are still exported. I'm unclear on whether this last part is correct, but librustc will fail to link unless it's in place.
2013-11-22 10:06:35 -08:00
Alex Crichton
93a0dec202 Move more of the exportation burden into privacy
I added a test case which does not compile today, and required changes on
privacy's side of things to get right. Additionally, this moves a good bit of
logic which did not belong in reachability into privacy.

All of reachability should solely be responsible for determining what the
reachable surface area of a crate is given the exported surface area (where the
exported surface area is that which is usable by external crates).

Privacy will now correctly figure out what's exported by deeply looking
through reexports. Previously if a module were reexported under another name,
nothing in the module would actually get exported in the executable. I also
consolidated the phases of privacy to be clearer about what's an input to what.
The privacy checking pass no longer uses the notion of an "all public" path, and
the embargo visitor is no longer an input to the checking pass.

Currently the embargo visitor is built as a saturating analysis because it's
unknown what portions of the AST are going to get re-exported.
2013-11-22 10:02:10 -08:00
Eric Holk
02e565a187 Don't use win64 calling convention on 32-bit machines. 2013-11-19 12:46:28 -05:00
Eric Holk
50fb4be1cc Add Win64 calling convention. 2013-11-18 19:20:09 -05:00
Alex Crichton
7755ffd013 Remove #[fixed_stack_segment] and #[rust_stack]
These two attributes are no longer useful now that Rust has decided to leave
segmented stacks behind. It is assumed that the rust task's stack is always
large enough to make an FFI call (due to the stack being very large).

There's always the case of stack overflow, however, to consider. This does not
change the behavior of stack overflow in Rust. This is still normally triggered
by the __morestack function and aborts the whole process.

C stack overflow will continue to corrupt the stack, however (as it did before
this commit as well). The future improvement of a guard page at the end of every
rust stack is still unimplemented and is intended to be the mechanism through
which we attempt to detect C stack overflow.

Closes #8822
Closes #10155
2013-11-11 10:40:34 -08:00
Andrei Formiga
23387b062d Added tests for default generation of package_id meta attribute 2013-11-08 17:42:46 -03:00
bors
4b04395c11 auto merge of #10182 : alexcrichton/rust/typeid-intrinsic, r=nikomatsakis
This isn't quite as fancy as the struct in #9913, but I'm not sure we should be exposing crate names/hashes of the types. That being said, it'd be pretty easy to extend this (the deterministic hashing regardless of what crate you're in was the hard part).
2013-11-04 19:21:50 -08:00
bors
4910b7ac28 auto merge of #10242 : thestinger/rust/inline_dtor, r=alexcrichton
Closes #7793
2013-11-02 23:26:00 -07:00
Daniel Micay
e58270219f fix cross-crate destructor inlining
Closes #7793
2013-11-02 23:55:23 -04:00
Alex Crichton
61637439dc Add a type_id intrinsic
Closes #9913
2013-11-01 10:31:33 -07:00
Alex Crichton
681fda0169 Reduce the aggressiveness of reachability
Previously, all functions called by a reachable function were considered
reachable, but this is only the case if the original function was possibly
inlineable (if it's type generic or #[inline]-flagged).
2013-10-31 20:47:23 -07:00
Daniel Micay
142672dca4 register snapshots 2013-10-23 18:06:12 -04:00
Alex Crichton
daf5f5a4d1 Drop the '2' suffix from logging macros
Who doesn't like a massive renaming?
2013-10-22 08:09:56 -07:00