summary refs log tree commit diff
path: root/src/librustc/metadata/encoder.rs
AgeCommit message (Collapse)AuthorLines
2015-01-07rollup merge of #20721: japaric/snapAlex Crichton-49/+49
Conflicts: src/libcollections/vec.rs src/libcore/fmt/mod.rs src/librustc/lint/builtin.rs src/librustc/session/config.rs src/librustc_trans/trans/base.rs src/librustc_trans/trans/context.rs src/librustc_trans/trans/type_.rs src/librustc_typeck/check/_match.rs src/librustdoc/html/format.rs src/libsyntax/std_inject.rs src/libsyntax/util/interner.rs src/test/compile-fail/mut-pattern-mismatched.rs
2015-01-07rollup merge of #20654: alexcrichton/stabilize-hashAlex Crichton-4/+5
This commit aims to prepare the `std::hash` module for alpha by formalizing its current interface whileholding off on adding `#[stable]` to the new APIs. The current usage with the `HashMap` and `HashSet` types is also reconciled by separating out composable parts of the design. The primary goal of this slight redesign is to separate the concepts of a hasher's state from a hashing algorithm itself. The primary change of this commit is to separate the `Hasher` trait into a `Hasher` and a `HashState` trait. Conceptually the old `Hasher` trait was actually just a factory for various states, but hashing had very little control over how these states were used. Additionally the old `Hasher` trait was actually fairly unrelated to hashing. This commit redesigns the existing `Hasher` trait to match what the notion of a `Hasher` normally implies with the following definition: trait Hasher { type Output; fn reset(&mut self); fn finish(&self) -> Output; } This `Hasher` trait emphasizes that hashing algorithms may produce outputs other than a `u64`, so the output type is made generic. Other than that, however, very little is assumed about a particular hasher. It is left up to implementors to provide specific methods or trait implementations to feed data into a hasher. The corresponding `Hash` trait becomes: trait Hash<H: Hasher> { fn hash(&self, &mut H); } The old default of `SipState` was removed from this trait as it's not something that we're willing to stabilize until the end of time, but the type parameter is always required to implement `Hasher`. Note that the type parameter `H` remains on the trait to enable multidispatch for specialization of hashing for particular hashers. Note that `Writer` is not mentioned in either of `Hash` or `Hasher`, it is simply used as part `derive` and the implementations for all primitive types. With these definitions, the old `Hasher` trait is realized as a new `HashState` trait in the `collections::hash_state` module as an unstable addition for now. The current definition looks like: trait HashState { type Hasher: Hasher; fn hasher(&self) -> Hasher; } The purpose of this trait is to emphasize that the one piece of functionality for implementors is that new instances of `Hasher` can be created. This conceptually represents the two keys from which more instances of a `SipHasher` can be created, and a `HashState` is what's stored in a `HashMap`, not a `Hasher`. Implementors of custom hash algorithms should implement the `Hasher` trait, and only hash algorithms intended for use in hash maps need to implement or worry about the `HashState` trait. The entire module and `HashState` infrastructure remains `#[unstable]` due to it being recently redesigned, but some other stability decision made for the `std::hash` module are: * The `Writer` trait remains `#[experimental]` as it's intended to be replaced with an `io::Writer` (more details soon). * The top-level `hash` function is `#[unstable]` as it is intended to be generic over the hashing algorithm instead of hardwired to `SipHasher` * The inner `sip` module is now private as its one export, `SipHasher` is reexported in the `hash` module. And finally, a few changes were made to the default parameters on `HashMap`. * The `RandomSipHasher` default type parameter was renamed to `RandomState`. This renaming emphasizes that it is not a hasher, but rather just state to generate hashers. It also moves away from the name "sip" as it may not always be implemented as `SipHasher`. This type lives in the `std::collections::hash_map` module as `#[unstable]` * The associated `Hasher` type of `RandomState` is creatively called... `Hasher`! This concrete structure lives next to `RandomState` as an implemenation of the "default hashing algorithm" used for a `HashMap`. Under the hood this is currently implemented as `SipHasher`, but it draws an explicit interface for now and allows us to modify the implementation over time if necessary. There are many breaking changes outlined above, and as a result this commit is a: [breaking-change]
2015-01-07use slicing sugarJorge Aparicio-49/+49
2015-01-07std: Stabilize the std::hash moduleAlex Crichton-4/+5
This commit aims to prepare the `std::hash` module for alpha by formalizing its current interface whileholding off on adding `#[stable]` to the new APIs. The current usage with the `HashMap` and `HashSet` types is also reconciled by separating out composable parts of the design. The primary goal of this slight redesign is to separate the concepts of a hasher's state from a hashing algorithm itself. The primary change of this commit is to separate the `Hasher` trait into a `Hasher` and a `HashState` trait. Conceptually the old `Hasher` trait was actually just a factory for various states, but hashing had very little control over how these states were used. Additionally the old `Hasher` trait was actually fairly unrelated to hashing. This commit redesigns the existing `Hasher` trait to match what the notion of a `Hasher` normally implies with the following definition: trait Hasher { type Output; fn reset(&mut self); fn finish(&self) -> Output; } This `Hasher` trait emphasizes that hashing algorithms may produce outputs other than a `u64`, so the output type is made generic. Other than that, however, very little is assumed about a particular hasher. It is left up to implementors to provide specific methods or trait implementations to feed data into a hasher. The corresponding `Hash` trait becomes: trait Hash<H: Hasher> { fn hash(&self, &mut H); } The old default of `SipState` was removed from this trait as it's not something that we're willing to stabilize until the end of time, but the type parameter is always required to implement `Hasher`. Note that the type parameter `H` remains on the trait to enable multidispatch for specialization of hashing for particular hashers. Note that `Writer` is not mentioned in either of `Hash` or `Hasher`, it is simply used as part `derive` and the implementations for all primitive types. With these definitions, the old `Hasher` trait is realized as a new `HashState` trait in the `collections::hash_state` module as an unstable addition for now. The current definition looks like: trait HashState { type Hasher: Hasher; fn hasher(&self) -> Hasher; } The purpose of this trait is to emphasize that the one piece of functionality for implementors is that new instances of `Hasher` can be created. This conceptually represents the two keys from which more instances of a `SipHasher` can be created, and a `HashState` is what's stored in a `HashMap`, not a `Hasher`. Implementors of custom hash algorithms should implement the `Hasher` trait, and only hash algorithms intended for use in hash maps need to implement or worry about the `HashState` trait. The entire module and `HashState` infrastructure remains `#[unstable]` due to it being recently redesigned, but some other stability decision made for the `std::hash` module are: * The `Writer` trait remains `#[experimental]` as it's intended to be replaced with an `io::Writer` (more details soon). * The top-level `hash` function is `#[unstable]` as it is intended to be generic over the hashing algorithm instead of hardwired to `SipHasher` * The inner `sip` module is now private as its one export, `SipHasher` is reexported in the `hash` module. And finally, a few changes were made to the default parameters on `HashMap`. * The `RandomSipHasher` default type parameter was renamed to `RandomState`. This renaming emphasizes that it is not a hasher, but rather just state to generate hashers. It also moves away from the name "sip" as it may not always be implemented as `SipHasher`. This type lives in the `std::collections::hash_map` module as `#[unstable]` * The associated `Hasher` type of `RandomState` is creatively called... `Hasher`! This concrete structure lives next to `RandomState` as an implemenation of the "default hashing algorithm" used for a `HashMap`. Under the hood this is currently implemented as `SipHasher`, but it draws an explicit interface for now and allows us to modify the implementation over time if necessary. There are many breaking changes outlined above, and as a result this commit is a: [breaking-change]
2015-01-07Merge pull request #20674 from jbcrail/fix-misspelled-commentsbors-1/+1
Fix misspelled comments. Reviewed-by: steveklabnik
2015-01-06Fix misspelled comments.Joseph Crail-1/+1
I cleaned up comments prior to the 1.0 alpha release.
2015-01-06Register new snapshotsAlex Crichton-1/+1
Conflicts: src/librbml/lib.rs src/libserialize/json_stage0.rs src/libserialize/serialize_stage0.rs src/libsyntax/ast.rs src/libsyntax/ext/deriving/generic/mod.rs src/libsyntax/parse/token.rs
2015-01-06rollup merge of #20481: seanmonstar/fmt-show-stringAlex Crichton-2/+2
Conflicts: src/compiletest/runtest.rs src/libcore/fmt/mod.rs src/libfmt_macros/lib.rs src/libregex/parse.rs src/librustc/middle/cfg/construct.rs src/librustc/middle/dataflow.rs src/librustc/middle/infer/higher_ranked/mod.rs src/librustc/middle/ty.rs src/librustc_back/archive.rs src/librustc_borrowck/borrowck/fragments.rs src/librustc_borrowck/borrowck/gather_loans/mod.rs src/librustc_resolve/lib.rs src/librustc_trans/back/link.rs src/librustc_trans/save/mod.rs src/librustc_trans/trans/base.rs src/librustc_trans/trans/callee.rs src/librustc_trans/trans/common.rs src/librustc_trans/trans/consts.rs src/librustc_trans/trans/controlflow.rs src/librustc_trans/trans/debuginfo.rs src/librustc_trans/trans/expr.rs src/librustc_trans/trans/monomorphize.rs src/librustc_typeck/astconv.rs src/librustc_typeck/check/method/mod.rs src/librustc_typeck/check/mod.rs src/librustc_typeck/check/regionck.rs src/librustc_typeck/collect.rs src/libsyntax/ext/format.rs src/libsyntax/ext/source_util.rs src/libsyntax/ext/tt/transcribe.rs src/libsyntax/parse/mod.rs src/libsyntax/parse/token.rs src/test/run-pass/issue-8898.rs
2015-01-07falloutNick Cameron-2/+2
2015-01-06core: split into fmt::Show and fmt::StringSean McArthur-2/+2
fmt::Show is for debugging, and can and should be implemented for all public types. This trait is used with `{:?}` syntax. There still exists #[derive(Show)]. fmt::String is for types that faithfully be represented as a String. Because of this, there is no way to derive fmt::String, all implementations must be purposeful. It is used by the default format syntax, `{}`. This will break most instances of `{}`, since that now requires the type to impl fmt::String. In most cases, replacing `{}` with `{:?}` is the correct fix. Types that were being printed specifically for users should receive a fmt::String implementation to fix this. Part of #20013 [breaking-change]
2015-01-07Replace full slice notation with index callsNick Cameron-44/+44
2015-01-05rollup merge of #20482: kmcallister/macro-reformAlex Crichton-19/+16
Conflicts: src/libflate/lib.rs src/libstd/lib.rs src/libstd/macros.rs src/libsyntax/feature_gate.rs src/libsyntax/parse/parser.rs src/libsyntax/show_span.rs src/test/auxiliary/macro_crate_test.rs src/test/compile-fail/lint-stability.rs src/test/run-pass/intrinsics-math.rs src/test/run-pass/tcp-connect-timeouts.rs
2015-01-05EncodeInlinedItem: convert to "unboxed" closuresJorge Aparicio-4/+3
2015-01-05Reformat metadata for exported macrosKeegan McAllister-19/+16
Instead of copy-pasting the whole macro_rules! item from the original .rs file, we serialize a separate name, attributes list, and body, the latter as pretty-printed TTs. The compilation of macro_rules! macros is decoupled somewhat from the expansion of macros in item position. This filters out comments, and facilitates selective imports.
2015-01-04Add syntax for negative implementations of traitsFlavio Percoco-2/+11
This commit introduces the syntax for negative implmenetations of traits as shown below: `impl !Trait for Type {}` cc #13231 Part of RFC #3
2015-01-03sed -i -s 's/#\[deriving(/#\[derive(/g' **/*.rsJorge Aparicio-1/+1
2015-01-03sed -i -s 's/\bmod,/self,/g' **/*.rsJorge Aparicio-2/+2
2015-01-03rustc: fix falloutJorge Aparicio-1/+1
2015-01-02rollup merge of #20385: nick29581/x-objectAlex Crichton-5/+4
Closes #19056
2015-01-01auto merge of #20363 : japaric/rust/moar-uc, r=nmatsakisbors-1/+1
The the last argument of the `ItemDecorator::expand` method has changed to `Box<FnMut>`. Syntax extensions will break. [breaking-change] --- This PR removes pretty much all the remaining uses of boxed closures from the libraries. There are still boxed closures under the `test` directory, but I think those should be removed or replaced with unboxed closures at the same time we remove boxed closures from the language. In a few places I had to do some contortions (see the first commit for an example) to work around issue #19596. I have marked those workarounds with FIXMEs. In the future when `&mut F where F: FnMut` implements the `FnMut` trait, we should be able to remove those workarounds. I've take care to avoid placing the workaround functions in the public API. Since `let f = || {}` always gets type checked as a boxed closure, I have explictly annotated those closures (with e.g. `|&:| {}`) to force the compiler to type check them as unboxed closures. Instead of removing the type aliases (like `GetCrateDataCb`), I could have replaced them with newtypes. But this seemed like overcomplicating things for little to no gain. I think we should be able to remove the boxed closures from the languge after this PR lands. (I'm being optimistic here) r? @alexcrichton or @aturon cc @nikomatsakis
2014-12-31rustc: unbox closures used in let bindingsJorge Aparicio-1/+1
2015-01-01Fix a bug with cross-crate trait implsNick Cameron-5/+4
Closes #19056
2015-01-01auto merge of #20374 : nikomatsakis/rust/assoc-types, r=nikomatsakisbors-0/+1
These mostly derive from problems that @japaric encountered. r? @pcwalton
2014-12-31Incorporate fix from japaric for cross-crate ICENiko Matsakis-0/+1
2014-12-30Fallout from stabilizationAaron Turon-1/+1
2014-12-30Encode the TypeScheme for associated typesNiko Matsakis-0/+3
2014-12-30Patch more metadata decoding problems.Niko Matsakis-1/+2
2014-12-30Encode the name for associated items on a trait. Fixes #18048.Niko Matsakis-0/+2
2014-12-30Implement associated type projection and normalization.Niko Matsakis-0/+9
2014-12-30Rename `Polytype` to `TypeScheme` to differentiate type schemes (early ↵Niko Matsakis-1/+1
bound) from higher-ranked things (late-bound), which also use the `Poly` prefix.
2014-12-26Accept `?Sized` as well as `Sized?`Nick Cameron-1/+1
Includes a bit of refactoring to store `?` unbounds as bounds with a modifier, rather than in their own world, in the AST at least.
2014-12-21Fallout of std::str stabilizationAlex Crichton-44/+44
2014-12-20Visit + encode stability for foreign itemsTom Jakubowski-0/+4
Fix #19649
2014-12-20metadata: Encode attrs for foreign items.Tom Jakubowski-0/+2
Related to #19649 and #16289
2014-12-20rustc: middle: move Export and ExportMap from resolve to def.Eduard Burtescu-7/+7
2014-12-20rustc: middle: use cheaper Name in resolve::Export instead of String.Eduard Burtescu-6/+4
2014-12-20middle: resolve: fix inconsistencies around ExportMap and remove the 2 suffix.Eduard Burtescu-9/+9
2014-12-17rollup merge of #19849: alexcrichton/second-pass-optionAlex Crichton-5/+5
This commit takes a second pass through the `std::option` module to fully stabilize any lingering methods inside of it. These items were made stable as-is * Some * None * as_mut * expect * unwrap * unwrap_or * unwrap_or_else * map * map_or * map_or_else * and_then * or_else * unwrap_or_default * Default implementation * FromIterator implementation * Copy implementation These items were made stable with modifications * iter - now returns a struct called Iter * iter_mut - now returns a struct called IterMut * into_iter - now returns a struct called IntoIter, Clone is never implemented This is a breaking change due to the modifications to the names of the iterator types returned. Code referencing the old names should updated to referencing the newer names instead. This is also a breaking change due to the fact that `IntoIter` no longer implements the `Clone` trait. These items were explicitly not stabilized * as_slice - waiting on indexing conventions * as_mut_slice - waiting on conventions with as_slice as well * cloned - the API was still just recently added * ok_or - API remains experimental * ok_or_else - API remains experimental [breaking-change]
2014-12-15rollup merge of #19793: tomjakubowski/metadata-const-attrsBrian Anderson-0/+1
Fix #19773 Together with #19774 (which this is rebased on): Fix #18156, fix #19722, fix #19185 r? @alexcrichton (since this was your suggestion!)
2014-12-14std: Fully stabilize Option<T>Alex Crichton-5/+5
This commit takes a second pass through the `std::option` module to fully stabilize any lingering methods inside of it. These items were made stable as-is * Some * None * as_mut * expect * unwrap * unwrap_or * unwrap_or_else * map * map_or * map_or_else * and_then * or_else * unwrap_or_default * Default implementation * FromIterator implementation * Copy implementation These items were made stable with modifications * iter - now returns a struct called Iter * iter_mut - now returns a struct called IterMut * into_iter - now returns a struct called IntoIter, Clone is never implemented This is a breaking change due to the modifications to the names of the iterator types returned. Code referencing the old names should updated to referencing the newer names instead. This is also a breaking change due to the fact that `IntoIter` no longer implements the `Clone` trait. These items were explicitly not stabilized * as_slice - waiting on indexing conventions * as_mut_slice - waiting on conventions with as_slice as well * cloned - the API was still just recently added * ok_or - API remains experimental * ok_or_else - API remains experimental [breaking-change]
2014-12-14Parse `unsafe impl` but don't do anything particularly interesting with the ↵Niko Matsakis-11/+12
results.
2014-12-14Parse `unsafe trait` but do not do anything with it beyond parsing and ↵Niko Matsakis-1/+10
integrating into rustdoc etc.
2014-12-13librustc: use unboxed closuresJorge Aparicio-3/+7
2014-12-12Switch to using predicates to drive checking. Correct various tests --Niko Matsakis-0/+12
in most cases, just the error message changed, but in some cases we are reporting new errors that OUGHT to have been reported before but we're overlooked (mostly involving the `'static` bound on `Send`).
2014-12-12metadata: Encode attributes for const itemsTom Jakubowski-0/+1
Fix #19773 Together with #19774 (which this is rebased on): Fix #18156, fix #19722, fix #19185
2014-12-09auto merge of #19563 : alexcrichton/rust/issue-19501, r=pnkfelixbors-1/+26
One of the causes of #19501 was that the metadata on OSX was getting corrupted. For any one particular invocation of the compiler the metadata file inside of an rlib archive would have extra bytes appended to the end of it. These extra bytes end up confusing rbml and have it run off the end of the array (resulting in the out of bounds detected). This commit prepends the length of metadata to the start of the metadata to ensure that we always slice the precise amount that we want, and it also un-ignores the test from #19502. Closes #19501
2014-12-08rustc: Prepend a length to all metadataAlex Crichton-1/+26
One of the causes of #19501 was that the metadata on OSX was getting corrupted. For any one particular invocation of the compiler the metadata file inside of an rlib archive would have extra bytes appended to the end of it. These extra bytes end up confusing rbml and have it run off the end of the array (resulting in the out of bounds detected). This commit prepends the length of metadata to the start of the metadata to ensure that we always slice the precise amount that we want, and it also un-ignores the test from #19502. Closes #19501
2014-12-06librustc: remove unnecessary `as_slice()` callsJorge Aparicio-1/+1
2014-11-29Replace some verbose match statements with their `if let` equivalent.jfager-86/+63
No semantic changes, no enabling `if let` where it wasn't already enabled.
2014-11-26rollup merge of #19317: sfackler/xcrate-namespaceAlex Crichton-10/+0
The chunk of code in encoder.rs was at one point deleted, but must have come back in a rebase or something :( Closes #19293
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-07-13 05:39:06 +0000