summary refs log tree commit diff
path: root/src/librustc/metadata/creader.rs
AgeCommit message (Collapse)AuthorLines
2014-03-28auto merge of #13170 : eddyb/rust/syntax-cleanup, r=alexcrichtonbors-3/+4
Removes all Cell's/RefCell's from lexer::Reader implementations and a couple @.
2014-03-28Convert most code to new inner attribute syntax.Brian Anderson-1/+1
Closes #2569
2014-03-28De-@ IdentInterner.Eduard Burtescu-3/+4
2014-03-23iter: remove `to_owned_vec`Daniel Micay-2/+2
This needs to be removed as part of removing `~[T]`. Partial type hints are now allowed, and will remove the need to add a version of this method for `Vec<T>`. For now, this involves a few workarounds for partial type hints not completely working.
2014-03-22rustc: Fix fallout of removing get()Alex Crichton-14/+9
2014-03-20Removing imports of std::vec_ng::VecAlex Crichton-1/+0
It's now in the prelude.
2014-03-20rename std::vec_ng -> std::vecDaniel Micay-1/+1
Closes #12771
2014-03-17De-@ codemap and diagnostic.Eduard Burtescu-1/+1
2014-03-17De-@ CStore uses.Eduard Burtescu-18/+11
2014-03-17De-@ Session usage.Eduard Burtescu-21/+12
2014-03-08librustc: Fix up fallout from the automatic conversion.Felix S. Klock II-3/+5
2014-03-08librustc: Automatically change uses of `~[T]` to `Vec<T>` in rustc.Patrick Walton-3/+3
2014-03-07rename ast::ViewItemExternMod to ast::ViewItemExternCrate, and ↵Liigo Zhuang-1/+1
clean::ExternMod to clean::ExternCrate
2014-03-01librustc: Fix errors arising from the automated `~[T]` conversionPatrick Walton-3/+5
2014-02-28rustc: Add the concept of a Strict Version HashAlex Crichton-12/+18
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-28rustc: Simplify crate loading constraintsAlex Crichton-134/+94
The previous code passed around a {name,version} pair everywhere, but this is better expressed as a CrateId. This patch changes these paths to store and pass around crate ids instead of these pairs of name/version. This also prepares the code to change the type of hash that is stored in crates.
2014-02-23Move std::{trie, hashmap} to libcollectionsAlex Crichton-1/+1
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-21Changed NonCamelCaseTypes lint to warn by defaultmr.Shu-1/+3
Added allow(non_camel_case_types) to librustc where necesary Tried to fix problems with non_camel_case_types outside rustc fixed failing tests Docs updated Moved #[allow(non_camel_case_types)] a level higher. markdown.rs reverted Fixed timer that was failing tests Fixed another timer
2014-02-17Updated metadata::creader::resolve_crate_deps to use the correct span. ↵gentlefolk-8/+21
Clarified error message when an external crate's dependency is missing. Closes #2404.
2014-02-14extern mod => extern crateAlex Crichton-1/+1
This was previously implemented, and it just needed a snapshot to go through
2014-02-14Refactored ast_map and friends, mainly to have Paths without storing them.Eduard Burtescu-14/+14
2014-02-13Replace `crate` usage with `krate`Flavio Percoco-6/+6
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-02librustc: Remove a bunch of `@str` from the compiler around metadataPatrick Walton-30/+45
handling
2014-02-02librustc: Fix merge fallout.Patrick Walton-4/+4
2014-02-02libsyntax: Remove all `@str` from the ASTPatrick Walton-2/+2
2014-02-02libsyntax: De-`@str` literal strings in the ASTPatrick Walton-14/+10
2014-02-02libsyntax: Introduce an `InternedString` type to reduce `@str` in thePatrick Walton-5/+13
compiler and use it for attributes
2014-01-23Redo exported macro serializationSteven Fackler-1/+1
The old method of serializing the AST gives totally bogus spans if the expansion of an imported macro causes compilation errors. The best solution seems to be to serialize the actual textual macro definition and load it the same way the std-macros are. I'm not totally confident that getting the source from the CodeMap will always do the right thing, but it seems to work in simple cases.
2014-01-16Load macros from external modulesSteven Fackler-30/+105
2014-01-09libsyntax: Renamed types, traits and enum variants to CamelCase.Eduard Burtescu-9/+9
2014-01-06Disowned the Visitor.Eduard Burtescu-3/+3
2014-01-03librustc: De-`@mut` the span handlerPatrick Walton-1/+1
2014-01-02auto merge of #10696 : fhahn/rust/issue9543-remove-extern-mod-foo, r=pcwaltonbors-1/+1
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-01Remove `extern mod foo (name="bar")` syntax, closes #9543Florian Hahn-1/+1
2014-01-01syntax::codemap: Add static DUMMY_SPklutzy-2/+2
It replaces `dummy_sp()`.
2014-01-01syntax::diagnostic: Remove unnecessary traitsklutzy-2/+2
This removes trait `handler` and `span_handler`, and renames `HandlerT` to `Handler`, `CodemapT` to `SpanHandler`.
2013-12-29Rename PkgId to CrateIdLuis de Bethencourt-10/+10
2013-12-29Rename pkgid variablesLuis de Bethencourt-6/+6
2013-12-26librustc: De-`@mut` the crate cache in the crate readerPatrick Walton-11/+16
2013-12-26librustc: De-`@mut` the `cnum_map`Patrick Walton-1/+2
2013-12-26librustc: De-`@mut` `creader::Env`Patrick Walton-11/+18
2013-12-25Method-ify CStoreSteven Fackler-6/+6
2013-12-19auto merge of #11073 : klutzy/rust/issue-10978, r=alexcrichtonbors-1/+5
This patchset fixes small glitches which caused #10978.
2013-12-19Purge @-boxes from the reading half of EBMLAlex Crichton-4/+4
Now that the metadata is an owned value with a lifetime of a borrowed byte slice, it's possible to have future optimizations where the metadata doesn't need to be copied around (very expensive operation).
2013-12-20rustc: Handle `#[link(name = "")]` errorklutzy-1/+5
2013-12-10Make crate hash stable and externally computable.Jack Moffitt-67/+44
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-04Revert "libstd: Change `Path::new` to `Path::init`."Kevin Ballard-1/+1
This reverts commit c54427ddfbbab41a39d14f2b1dc4f080cbc2d41b. Leave the #[ignores] in that were added to rustpkg tests. Conflicts: src/librustc/driver/driver.rs src/librustc/metadata/creader.rs
2013-11-30Support OSX frameworksAlex Crichton-4/+18
This adds support to link to OSX frameworks via the new link attribute when using `kind = "framework"`. It is a compiler error to request linkage to a framework when the target is not macos because other platforms don't support frameworks. Closes #2023
2013-11-30Test fixes and merge conflictsAlex Crichton-4/+4
2013-11-29Add generation of static libraries to rustcAlex Crichton-80/+73
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
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-04-27 02:42:26 +0000