190 Commits

Author SHA1 Message Date
Steven Fackler
c305473d3c Add AttrId to Attribute_ 2014-05-24 16:08:36 -07:00
Patrick Walton
36195eb91f libstd: Remove ~str from all libstd modules except fmt and str. 2014-05-22 14:42:01 -07:00
Kevin Ballard
23ca66ecd2 Change std inject attributes to outer attributes
The #[phase(syntax,link)] attribute on `extern crate std` needs to be an
outer attribute so it can pretty-print properly.

Also add `#![no_std]` and `#[feature(phase)]` so compiling the
pretty-printed source will work.
2014-05-20 22:44:58 -07:00
Patrick Walton
93499b1eaf libtest: Remove all uses of ~str from libtest. 2014-05-14 18:29:13 -07:00
Kevin Ballard
752048a271 Handle more fallout
os::args() no longer auto-borrows to &[~str].
2014-05-08 12:06:22 -07:00
Patrick Walton
7f8f3dcf17 libsyntax: Remove uses of ~str from libsyntax, and fix fallout 2014-05-08 08:38:23 -07:00
Alex Crichton
825f6ace1d rustc: Remove the session building_library flag
This has long since not been too relevant since the introduction of many crate
type outputs. This commit removes the flag entirely, adjusting all logic to do
the most reasonable thing when building both a library and an executable.

Closes #13337
2014-05-02 15:26:45 -07:00
bors
a1ad41b93d auto merge of #13791 : lifthrasiir/rust/mod-inner-span, r=huonw
This PR is primarily motivated by (and fixes) #12926.

We currently only have a span for the individual item itself and not for the referred contents. This normally does not cause a problem since both are located in the same file; it *is* possible that the contained statement or item is located in the other file (the syntax extension can do that), but even in that case the syntax extension should be located in the same file as the item. The module item (i.e. `mod foo;`) is the only exception here, and thus warrants a special treatment.

Rustdoc would now distinguish `mod foo;` from `mod foo {...}` by checking if the span for the module item and module contents is in different files. If it's the case, we'd prefer module contents over module item. There are alternative strategies, but as noted above we will have some corner cases if we don't record the contents span explicitly.
2014-04-28 05:21:46 -07:00
Kang Seonghoon
dee21a67b8 syntax: Mod records the span for inner contents.
this is useful when the module item and module contents are defined
from different files (like rustdoc). in most cases the original span
for the module item would be used; in other cases, the span for
module contents is available separately at the `inner` field.
2014-04-27 14:52:30 +09:00
Kang Seonghoon
b03547bac1 syntax: ViewItemUse no longer contains multiple view paths.
it reflected the obsolete syntax `use a, b, c;` and did not make
past the parser (though it was a non-fatal error so we can continue).
this legacy affected many portions of rustc and rustdoc as well,
so this commit cleans them up altogether.
2014-04-26 22:33:45 +09:00
Richo Healey
919889a1d6 Replace all ~"" with "".to_owned() 2014-04-18 17:25:34 -07:00
Liigo Zhuang
408f484b66 libtest: rename BenchHarness to Bencher
Closes #12640
2014-04-11 17:31:13 +08:00
Alex Crichton
83d2c0b8a6 rustc: Disallow importing through use statements
Resolve is currently erroneously allowing imports through private `use`
statements in some circumstances, even across module boundaries. For example,
this code compiles successfully today:

    use std::c_str;
    mod test {
        use c_str::CString;
    }

This should not be allowed because it was explicitly decided that private `use`
statements are purely bringing local names into scope, they are not
participating further in name resolution.

As a consequence of this patch, this code, while valid today, is now invalid:

    mod test {
        use std::c_str;

        unsafe fn foo() {
            ::test::c_str::CString::new(0 as *u8, false);
        }
    }

While plausibly acceptable, I found it to be more consistent if private imports
were only considered candidates to resolve the first component in a path, and no
others.

Closes #12612
2014-04-10 15:22:00 -07:00
Eduard Burtescu
7c48e53c1e syntax: remove obsolete mutability from ExprVec and ExprRepeat. 2014-04-04 13:23:03 -07:00
Erick Tryzelaar
7bcfe2ee10 std: Remove RefCell::get()
It's surprising that `RefCell::get()` is implicitly doing a clone
on a value. This patch removes it and replaces all users with
either `.borrow()` when we can autoderef, or `.borrow().clone()`
when we cannot.
2014-04-03 20:28:55 -07:00
Daniel Micay
cbbc1fc843 vec: convert append and append_one to methods
These were only free functions on `~[T]` because taking self by-value
used to be broken.
2014-03-31 01:13:48 -04:00
Steven Fackler
9ed33c00ea Use new inner attribute syntax in test framework 2014-03-29 16:04:45 -07:00
Brian Anderson
451e8c1c61 Convert most code to new inner attribute syntax.
Closes #2569
2014-03-28 17:12:21 -07:00
Alex Crichton
0dbb909bf7 rustc: Fix fallout of removing get() 2014-03-22 08:48:20 -07:00
Huon Wilson
e33676b793 Migrate all users of opt_vec to owned_slice, delete opt_vec.
syntax::opt_vec is now entirely unused, and so can go.
2014-03-22 09:54:18 +11:00
Daniel Micay
14f656d1a7 rename std::vec_ng -> std::vec
Closes #12771
2014-03-20 04:25:32 -04:00
Daniel Micay
ce620320a2 rename std::vec -> std::slice
Closes #12702
2014-03-20 01:30:27 -04:00
Corey Richardson
873f7408bd rustc: test: don't silently ignore bad benches
This is adequate because when a function has a type that isn't caught here,
that is, it has a single argument, but it *isn't* `&mut BenchHarness`, it
errors later on with:

     error: mismatched types: expected `fn(&mut test::BenchHarness)` but found
     `fn(int)` (expected &-ptr but found int)

which I consider acceptable.

Closes #12997
2014-03-18 13:47:50 -07:00
Eduard Burtescu
90cbe0cad2 De-@ ParseSess uses. 2014-03-17 09:53:07 +02:00
Eduard Burtescu
4fae06824c De-@ Session usage. 2014-03-17 09:53:06 +02:00
bors
f6fcdbb687 auto merge of #12791 : alexcrichton/rust/liblog, r=brson
The rationale and modifications can be found in the first commit message.

This does make logging a bit more painful to use initially because it involves a feature gate and some `phase` attributes, but I think it may be reasonable to not require the `phase` attribute for loading `macro_rules!` macros because defining them will still be gated.
2014-03-15 23:01:24 -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
Steven Fackler
2a35c08501 Squash test ~[] warning
The use of `std::os::args` creates a deprecated_owned_vector warning
with a bogus span.
2014-03-15 20:03:29 -07:00
Felix S. Klock II
586b619c76 Changed lists of lifetimes in ast and ty to use Vec instead of OptVec.
There is a broader revision (that does this across the board) pending
in #12675, but that is awaiting the arrival of more data (to decide
whether to keep OptVec alive by using a non-Vec internally).

For this code, the representation of lifetime lists needs to be the
same in both ScopeChain and in the ast and ty structures.  So it
seemed cleanest to just use `vec_ng::Vec`, now that it has a cheaper
empty representation than the current `vec` code.
2014-03-12 08:05:20 +01:00
Felix S. Klock II
43c07244b3 librustc: Fix up fallout from the automatic conversion. 2014-03-08 21:41:32 +01:00
Patrick Walton
3b6e9d4a7a librustc: Automatically change uses of ~[T] to Vec<T> in rustc. 2014-03-08 21:24:27 +01:00
Liigo Zhuang
2271860af1 rename ast::ViewItemExternMod to ast::ViewItemExternCrate, and clean::ExternMod to clean::ExternCrate 2014-03-07 15:57:45 +08:00
Alex Crichton
0a84132928 syntax: Conditionally deriving(Hash) with Writers
If #[feature(default_type_parameters)] is enabled for a crate, then
deriving(Hash) will expand with Hash<W: Writer> instead of Hash<SipState> so
more hash algorithms can be used.
2014-03-06 18:11:02 -08:00
Alex Crichton
b0e0cb5e32 Register new snapshots
This should fix the travis builds.
2014-03-03 18:00:52 -08:00
Patrick Walton
c1ed4d7d41 librustc: Fix errors arising from the automated ~[T] conversion 2014-03-01 22:40:53 -08:00
Liigo Zhuang
53b9d1a324 move extra::test to libtest 2014-02-20 16:03:58 +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
Eduard Burtescu
a02b10a062 Refactored ast_map and friends, mainly to have Paths without storing them. 2014-02-14 08:43:29 +02:00
Flavio Percoco
968633b60a Replace crate usage with krate
This patch replaces all `crate` usage with `krate` before introducing the
new keyword. This ensures that after introducing the keyword, there
won't be any compilation errors.

krate might not be the most expressive substitution for crate but it's a
very close abbreviation for it. `module` was already used in several
places already.
2014-02-13 20:52:07 +01:00
Patrick Walton
b890237e79 libsyntax: Fix tests. 2014-02-02 01:44:48 +11:00
Patrick Walton
c5cbfe89f8 librustc: De-@str NameAndSpan 2014-02-02 01:44:48 +11:00
Patrick Walton
8e52b85d5a libsyntax: De-@str literal strings in the AST 2014-02-02 01:44:48 +11:00
Patrick Walton
70c5a0fbf7 libsyntax: Introduce an InternedString type to reduce @str in the
compiler and use it for attributes
2014-02-02 01:44:47 +11:00
bors
b5a110c7fe auto merge of #11607 : alexcrichton/rust/issue-9957, r=cmr
For `use` statements, this means disallowing qualifiers when in functions and
disallowing `priv` outside of functions.

For `extern mod` statements, this means disallowing everything everywhere. It
may have been envisioned for `pub extern mod foo` to be a thing, but it
currently doesn't do anything (resolve doesn't pick it up), so better to err on
the side of forwards-compatibility and forbid it entirely for now.

Closes #9957
2014-01-18 13:01:47 -08:00
Alex Crichton
4a78364d49 Forbid unnecessary visibility on view items
For `use` statements, this means disallowing qualifiers when in functions and
disallowing `priv` outside of functions.

For `extern mod` statements, this means disallowing everything everywhere. It
may have been envisioned for `pub extern mod foo` to be a thing, but it
currently doesn't do anything (resolve doesn't pick it up), so better to err on
the side of forwards-compatibility and forbid it entirely for now.

Closes #9957
2014-01-18 10:46:32 -08:00
Steven Fackler
328b47d837 Load macros from external modules 2014-01-16 15:01:48 -08:00
Alex Crichton
7a37294acc Add a configure to disable libstd version injection
We'll use this when building snapshots so we can upgrade freely, but all
compilers will inject a version by default.
2014-01-15 08:22:16 -08:00
Brian Anderson
46905c04f5 Bump version to 0.10-pre 2014-01-12 17:45:22 -08:00
Eduard Burtescu
6b221768cf libsyntax: Renamed types, traits and enum variants to CamelCase. 2014-01-09 22:25:28 +02:00
bors
0df9b850ac auto merge of #10696 : fhahn/rust/issue9543-remove-extern-mod-foo, r=pcwalton
This patch for  #9543 throws an `obsolete syntax` error for `extern mod foo (name="bar")` . 
I was wondering if [this](https://github.com/fhahn/rust/compare/mozilla:master...fhahn:issue9543-remove-extern-mod-foo?expand=1#diff-da9d34ca1d0f6beee2838cf02e07345cR4444) is the correct place to do this?

I think the wording of the error message could probably be improved as well.

If this approach is OK, I'm going to run the whole test suite tomorrow and update the old syntax to the new one.
2014-01-02 11:32:09 -08:00