summary refs log tree commit diff
path: root/src/test/auxiliary
AgeCommit message (Collapse)AuthorLines
2014-01-03test: De-`@mut` the test suitePatrick Walton-7/+18
2013-12-31Conservatively export all trait methods and implsAlex Crichton-0/+81
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-23rustc: Add a lint for the obsolete crate-level link attributeBrian Anderson-95/+0
2013-12-19librustc: Add missing case for the `Pod` bound in `tydecode`.Patrick Walton-0/+10
2013-12-19Rename pkgid to crate_idCorey Richardson-41/+41
Closes #11035
2013-12-18auto merge of #11012 : alexcrichton/rust/needstest, r=alexcrichtonbors-0/+32
Closes #5806 Closes #8259 Closes #8578 Closes #8851 Closes #10412
2013-12-18Adding tests for closed issuesAlex Crichton-0/+32
Closes #5806 Closes #5950 Closes #7178 Closes #8259 Closes #8578 Closes #8851 Closes #9129 Closes #10412
2013-12-16Fallout of rewriting std::commAlex Crichton-1/+1
2013-12-11Make 'self lifetime illegal.Erik Price-2/+2
Also remove all instances of 'self within the codebase. This fixes #10889.
2013-12-10Make crate hash stable and externally computable.Jack Moffitt-7/+84
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-08encode trait lifetime params in metadata to allow cross-crate usageDavid Renshaw-0/+13
2013-12-03Fix a bug in exporting trait implementationsAlex Crichton-0/+19
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-03Resume propagation of linking to native dylibsAlex Crichton-1/+1
The reasons for this are outlined in issue #10743 as well as the comment I have now placed in the code. Closes #10743
2013-11-30auto merge of #10528 : alexcrichton/rust/static-linking-v2, r=pcwaltonbors-3/+4
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-30Wrap the return value of the type_id intrinsic in an opaque boxCorey Richardson-18/+20
Closes #10594
2013-11-29Statically link librustrt to libstdAlex Crichton-3/+4
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-26test: Remove non-procedure uses of `do` from compiletest, libstd tests,Patrick Walton-2/+2
compile-fail tests, run-fail tests, and run-pass tests.
2013-11-26librustc: Remove remaining uses of `&fn()` in favor of `||`.Patrick Walton-1/+1
2013-11-26test: Remove most uses of `&fn()` from the tests.Patrick Walton-4/+4
2013-11-22auto merge of #10583 : alexcrichton/rust/privacy-reexport, r=pcwaltonbors-0/+15
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-22Move more of the exportation burden into privacyAlex Crichton-0/+15
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-19Don't use win64 calling convention on 32-bit machines.Eric Holk-3/+13
2013-11-18Add Win64 calling convention.Eric Holk-0/+27
2013-11-11Remove #[fixed_stack_segment] and #[rust_stack]Alex Crichton-1/+0
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-08Added tests for default generation of package_id meta attributeAndrei Formiga-0/+17
2013-11-04auto merge of #10182 : alexcrichton/rust/typeid-intrinsic, r=nikomatsakisbors-0/+64
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-02auto merge of #10242 : thestinger/rust/inline_dtor, r=alexcrichtonbors-0/+18
Closes #7793
2013-11-02fix cross-crate destructor inliningDaniel Micay-0/+18
Closes #7793
2013-11-01Add a type_id intrinsicAlex Crichton-0/+64
Closes #9913
2013-10-31Reduce the aggressiveness of reachabilityAlex Crichton-0/+36
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-23register snapshotsDaniel Micay-0/+5
2013-10-22Drop the '2' suffix from logging macrosAlex Crichton-13/+13
Who doesn't like a massive renaming?
2013-10-21Propagate reachability through reexported implsAlex Crichton-0/+60
When re-exporting a trait/structure/enum, then we need to propagate the reachability of the type through the methods that are defined on it. Closes #9906 Closes #9968
2013-10-19Use __morestack to detect stack overflowAlex Crichton-1/+0
This commit resumes management of the stack boundaries and limits when switching between tasks. This additionally leverages the __morestack function to run code on "stack overflow". The current behavior is to abort the process, but this is probably not the best behavior in the long term (for deails, see the comment I wrote up in the stack exhaustion routine).
2013-10-16drop the linenoise libraryDaniel Micay-36/+0
Closes #5038
2013-10-14Removing ccdeclSteve Klabnik-1/+1
as per https://github.com/mozilla/rust/pull/9606#discussion_r6930872
2013-10-14Remove unused abi attributes.Steve Klabnik-3/+1
They've been replaced by putting the name on the extern block. #[abi = "foo"] goes to extern "foo" { } Closes #9483.
2013-10-10Add tests and un-xfail a few issuesAlex Crichton-0/+39
Closes #4545 Closes #5791 Closes #6470 Closes #8044
2013-10-10Use the result of privacy for reachabilityAlex Crichton-0/+15
This fixes a bug in which the visibility rules were approximated by reachability, but forgot to cover the case where a 'pub use' reexports a private item. This fixes the commit by instead using the results of the privacy pass of the compiler to create the initial working set of the reachability pass. This may have the side effect of increasing the size of metadata, but it's difficult to avoid for correctness purposes sadly. Closes #9790
2013-10-09auto merge of #9664 : alexcrichton/rust/logging, r=huonwbors-0/+14
This makes some headway on #3309, see commits for details.
2013-10-06Add appropriate #[feature] directives to testsAlex Crichton-0/+3
2013-10-03Use the correct logging crate while monomorphingAlex Crichton-0/+14
This makes sure that the top-level crate name is correct when emitting log statements for a monomorphized function in another crate. This happens by tracing the monomorphized ID back to the external source and then using that crate index to get the name of the crate. Closes #3046
2013-10-03Close out #9155Steven Fackler-0/+17
Add a test to make sure it works and switch a private struct over to a newtype. Closes #9155
2013-10-01remove the `float` typeDaniel Micay-8/+8
It is simply defined as `f64` across every platform right now. A use case hasn't been presented for a `float` type defined as the highest precision floating point type implemented in hardware on the platform. Performance-wise, using the smallest precision correct for the use case greatly saves on cache space and allows for fitting more numbers into SSE/AVX registers. If there was a use case, this could be implemented as simply a type alias or a struct thanks to `#[cfg(...)]`. Closes #6592 The mailing list thread, for reference: https://mail.mozilla.org/pipermail/rust-dev/2013-July/004632.html
2013-09-30rpass: Remove usage of fmt!Alex Crichton-11/+11
2013-09-26Ensure that skipped items aren't encodedAlex Crichton-0/+17
If an item is skipped due to it being unreachable or for some optimization, then it shouldn't be encoded into the metadata (because it wasn't present in the first place).
2013-09-25auto merge of #9432 : alexcrichton/rust/correct-item-visibility, r=pcwaltonbors-4/+61
This fixes private statics and functions from being usable cross-crates, along with some bad privacy error messages. This is a reopening of #8365 with all the privacy checks in privacy.rs instead of resolve.rs (where they should be anyway). These maps of exported items will hopefully get used for generating documentation by rustdoc Closes #8592
2013-09-24auto merge of #9336 : alexcrichton/rust/issue-7981, r=catamorphismbors-1/+1
Progress on #7981 This doesn't completely close the issue because `struct A;` is still allowed, and it's a much larger change to disallow that. I'm also not entirely sure that we want to disallow that. Regardless, punting that discussion to the issue instead.
2013-09-24Stop accepting 'impl ...;', require {} insteadAlex Crichton-1/+1
Progress on #7981
2013-09-24Correctly encode item visibility in metadataAlex Crichton-4/+61
This fixes private statics and functions from being usable cross-crates, along with some bad privacy error messages. This is a reopening of #8365 with all the privacy checks in privacy.rs instead of resolve.rs (where they should be anyway). These maps of exported items will hopefully get used for generating documentation by rustdoc Closes #8592