summary refs log tree commit diff
path: root/src/librustc/front
AgeCommit message (Collapse)AuthorLines
2014-01-06Disowned the Visitor.Eduard Burtescu-12/+9
2014-01-03librustc: Remove `@mut` support from the parserPatrick Walton-3/+2
2014-01-03auto merge of #11276 : brson/rust/0.9, r=pcwaltonbors-1/+1
2014-01-02auto merge of #11093 : alexcrichton/rust/issue-11085, r=pcwaltonbors-1/+37
Closes #11085
2014-01-02Bump version to 0.9Brian Anderson-1/+1
2014-01-02auto merge of #10696 : fhahn/rust/issue9543-remove-extern-mod-foo, r=pcwaltonbors-11/+12
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-02Inject std libs with versionsFlorian Hahn-4/+13
2014-01-01Remove `extern mod foo (name="bar")` syntax, closes #9543Florian Hahn-9/+1
2014-01-01syntax::codemap: Add static DUMMY_SPklutzy-16/+16
It replaces `dummy_sp()`.
2013-12-30auto merge of #11182 : luisbg/rust/crateid, r=cmrbors-1/+1
Issue #11048
2013-12-29Remove @muts from ExtCtxtSteven Fackler-10/+10
2013-12-29Make ast_fold take &mut selfSteven Fackler-19/+19
2013-12-29Rename pkgid variablesLuis de Bethencourt-1/+1
2013-12-28Stop using @ExtCtxtSteven Fackler-13/+12
2013-12-26librustc: De-`@mut` `building_library` in the sessionPatrick Walton-2/+2
2013-12-26librustc: De-`@mut` the test contextPatrick Walton-5/+5
2013-12-26librustc: De-`@mut` `TestCtxt::testfns`Patrick Walton-6/+12
2013-12-26librustc: De-`@mut` `TestCtxt::path`Patrick Walton-6/+13
2013-12-24rustc: Strip struct fields and enum variantsAlex Crichton-1/+37
Closes #11085
2013-12-24rustc: Temporarily inject libgreen with librustuvAlex Crichton-0/+9
This measure is simply to allow programs to continue compiling as they once did. In the future, this needs a more robust solution to choose how to start with libgreen or libnative.
2013-12-15Register new snapshotsAlex Crichton-3/+2
Understand 'pkgid' in stage0. As a bonus, the snapshot now contains now metadata (now that those changes have landed), and the snapshot download is half as large as it used to be!
2013-12-12Gate literal box expressions in addition to typesAlex Crichton-6/+21
Closes #10920
2013-12-11Make 'self lifetime illegal.Erik Price-3/+3
Also remove all instances of 'self within the codebase. This fixes #10889.
2013-12-10Extend allocation lint for boxing expressionsSeo Sanghyeon-1/+1
2013-12-07syntax: print expansion info from #[attribute] macros in the correctHuon Wilson-1/+2
format. Previously, any attempt to use this information from inside something like #[deriving(Foo)] would result in it printing like `deriving(Foo)!`.
2013-12-03auto merge of #10747 : alexcrichton/rust/snapshots, r=cmrbors-4/+2
This registers new snapshots after the landing of #10528, and then goes on to tweak the build process to build a monolithic `rustc` binary for use in future snapshots. This mainly involved dropping the dynamic dependency on `librustllvm`, so that's now built as a static library (with a dynamically generated rust file listing LLVM dependencies). This currently doesn't actually make the snapshot any smaller (24MB => 23MB), but I noticed that the executable has 11MB of metadata so once progress is made on #10740 we should have a much smaller snapshot. There's not really a super-compelling reason to distribute just a binary because we have all the infrastructure for dealing with a directory structure, but to me it seems "more correct" that a snapshot compiler is just a `rustc` binary.
2013-12-03Register new snapshotsAlex Crichton-4/+2
2013-12-01auto merge of #10676 : eddyb/rust/ast-box-in-enums, r=cmrbors-6/+6
**Note**: I only tested on top of my #10670 PR, size reductions come from both change sets. With this, [more enums are shrinked](https://gist.github.com/eddyb/08fef0dfc6ff54e890bc), the most significant one being `ast_node`, from 104 bytes (master) to 96 (#10670) and now to 32 bytes. My own testcase requires **200MB** less when compiling (not including the other **200MB** gained in #10670), and rustc-stage2 is down by about **130MB**. I believe there is more to gain by fiddling with the enums' layouts.
2013-11-30Test fixes and merge conflictsAlex Crichton-1/+1
2013-12-01Box Block, fn_decl, variant and Ty in the AST, as they were inflating ↵Eduard Burtescu-6/+6
critical enum sizes.
2013-11-29Add generation of static libraries to rustcAlex Crichton-1/+14
This commit implements the support necessary for generating both intermediate and result static rust libraries. This is an implementation of my thoughts in https://mail.mozilla.org/pipermail/rust-dev/2013-November/006686.html. When compiling a library, we still retain the "lib" option, although now there are "rlib", "staticlib", and "dylib" as options for crate_type (and these are stackable). The idea of "lib" is to generate the "compiler default" instead of having too choose (although all are interchangeable). For now I have left the "complier default" to be a dynamic library for size reasons. Of the rust libraries, lib{std,extra,rustuv} will bootstrap with an rlib/dylib pair, but lib{rustc,syntax,rustdoc,rustpkg} will only be built as a dynamic object. I chose this for size reasons, but also because you're probably not going to be embedding the rustc compiler anywhere any time soon. Other than the options outlined above, there are a few defaults/preferences that are now opinionated in the compiler: * If both a .dylib and .rlib are found for a rust library, the compiler will prefer the .rlib variant. This is overridable via the -Z prefer-dynamic option * If generating a "lib", the compiler will generate a dynamic library. This is overridable by explicitly saying what flavor you'd like (rlib, staticlib, dylib). * If no options are passed to the command line, and no crate_type is found in the destination crate, then an executable is generated With this change, you can successfully build a rust program with 0 dynamic dependencies on rust libraries. There is still a dynamic dependency on librustrt, but I plan on removing that in a subsequent commit. This change includes no tests just yet. Our current testing infrastructure/harnesses aren't very amenable to doing flavorful things with linking, so I'm planning on adding a new mode of testing which I believe belongs as a separate commit. Closes #552
2013-11-28Register new snapshotsAlex Crichton-5/+2
2013-11-27auto merge of #10680 : alexcrichton/rust/relax-feature-gate, r=thestingerbors-1/+6
Instead of forcibly always aborting compilation, allow usage of #[warn(unknown_features)] and related lint attributes to selectively abort compilation. By default, this lint is deny.
2013-11-27Relax restrictions on unknown feature directivesAlex Crichton-1/+6
Instead of forcibly always aborting compilation, allow usage of #[warn(unknown_features)] and related lint attributes to selectively abort compilation. By default, this lint is deny.
2013-11-26auto merge of #10649 : sfackler/rust/multi-macro, r=alexcrichtonbors-26/+18
The majority of this change is modifying some of the `ast_visit` methods to return multiple values. It's prohibitively expensive to allocate a `~[Foo]` every time a statement, declaration, item, etc is visited, especially since the vast majority will have 0 or 1 elements. I've added a `SmallVector` class that avoids allocation in the 0 and 1 element cases to take care of that.
2013-11-26Support multiple item macrosSteven Fackler-26/+18
Closes #4375
2013-11-26auto merge of #10312 : thestinger/rust/thread_local, r=alexcritchtonbors-2/+14
This provides a building block for fast thread-local storage. It does not change the safety semantics of `static mut`. Closes #10310
2013-11-26add a thread_local feature gateDaniel Micay-2/+14
2013-11-26librustc: Remove non-procedure uses of `do` from librustc, librustdoc,Patrick Walton-25/+19
and librustpkg.
2013-11-26librustc: Remove remaining uses of `&fn()` in favor of `||`.Patrick Walton-1/+1
2013-11-22auto merge of #10605 : huonw/rust/ascii-ident-gate, r=pcwaltonbors-0/+11
cf. https://mail.mozilla.org/pipermail/rust-dev/2013-November/006920.html
2013-11-23Put non-ascii identifiers behind a feature gate.Huon Wilson-0/+11
cf. https://mail.mozilla.org/pipermail/rust-dev/2013-November/006920.html
2013-11-22mention `Gc` in the managed box feature gateDaniel Micay-5/+3
2013-11-19librustc: Change most uses of `&fn()` to `||`.Patrick Walton-1/+1
2013-11-08Generalize AST and ty::Generics to accept multiple lifetimes.Niko Matsakis-4/+4
2013-10-31Make managed_boxes feature gate error less opinionatedBrian Anderson-6/+6
2013-10-29auto merge of #10132 : pcwalton/rust/proc, r=pcwaltonbors-1/+2
the feature gate for `once fn` if used with the `~` sigil. r? @brson
2013-10-29librustc: Implement the `proc` type as sugar for `~once fn` and `proc`Patrick Walton-1/+2
notation for closures, and disable the feature gate for `once fn` if used with the `~` sigil.
2013-10-29Move rust's uv implementation to its own crateAlex Crichton-7/+22
There are a few reasons that this is a desirable move to take: 1. Proof of concept that a third party event loop is possible 2. Clear separation of responsibility between rt::io and the uv-backend 3. Enforce in the future that the event loop is "pluggable" and replacable Here's a quick summary of the points of this pull request which make this possible: * Two new lang items were introduced: event_loop, and event_loop_factory. The idea of a "factory" is to define a function which can be called with no arguments and will return the new event loop as a trait object. This factory is emitted to the crate map when building an executable. The factory doesn't have to exist, and when it doesn't then an empty slot is in the crate map and a basic event loop with no I/O support is provided to the runtime. * When building an executable, then the rustuv crate will be linked by default (providing a default implementation of the event loop) via a similar method to injecting a dependency on libstd. This is currently the only location where the rustuv crate is ever linked. * There is a new #[no_uv] attribute (implied by #[no_std]) which denies implicitly linking to rustuv by default Closes #5019
2013-10-23register snapshotsDaniel Micay-2/+1