- 20 1月, 2015 1 次提交
-
-
由 Tom Chittenden 提交于
-
- 17 1月, 2015 12 次提交
-
-
由 bors 提交于
This stops the compiler ICEing on the use of SIMD types in FFI signatures. It emits correct code for LLVM intrinsics, but I am quite unsure about the ABI handling in general so I've added a new feature gate `simd_ffi` to try to ensure people don't use it without realising there's a non-trivial risk of codegen brokenness. Closes #20043.
-
由 bors 提交于
Loading methods from external crates was erroneously using the type's privacy for each method instead of each method's privacy. This commit fixes that. Closes #21202 This commit also moves privacy to its own crate because I thought that was where the bug was. Turns out it wasn't, but it helped me iterate at least!
-
由 bors 提交于
**The implementation is a direct adaptation of libcxx's condition_variable implementation.** I also added a wait_timeout_with method, which matches the second overload in C++'s condition_variable. The implementation right now is kind of dumb but it works. There is an outstanding issue with it: as is it doesn't support the use case where a user doesn't care about poisoning and wants to continue through poison. r? @alexcrichton @aturon
-
由 Huon Wilson 提交于
I don't know if this handling of SIMD types is correct for the C ABI on all platforms, so lets add an even finer feature gate than just the `simd` one. The `simd` one can be used with (relatively) little risk of complete nonsense, the reason for it is that it is likely that things will change. Using the types in FFI with an incorrect ABI will at best give absolute nonsense results, but possibly cause serious breakage too, so this is a step up in badness, hence a new feature gate.
-
由 Huon Wilson 提交于
This just compiles a test using SIMD in FFI (mostly importing LLVM intrinsics) for almost all rustc's supported platforms, but not linking it or running it, so there's absolutely no guarantee that this is correct.
-
由 bors 提交于
For a call like `foo.bar()` where the method `bar` can't be resolved, the compiler will search for traits that have methods with name `bar` to give a more informative error, providing a list of possibilities. Closes #7643.
-
由 bors 提交于
With the addition of separate search paths to the compiler, it was intended that applications such as Cargo could require a `--extern` flag per `extern crate` directive in the source. The system can currently be subverted, however, due to the `existing_match()` logic in the crate loader. When loading crates we first attempt to match an `extern crate` directive against all previously loaded crates to avoid reading metadata twice. This "hit the cache if possible" step was erroneously leaking crates across the search path boundaries, however. For example: extern crate b; extern crate a; If `b` depends on `a`, then it will load crate `a` when the `extern crate b` directive is being processed. When the compiler reaches `extern crate a` it will use the previously loaded version no matter what. If the compiler was not invoked with `-L crate=path/to/a`, it will still succeed. This behavior is allowing `extern crate` declarations in Cargo without a corresponding declaration in the manifest of a dependency, which is considered a bug. This commit fixes this problem by keeping track of the origin search path for a crate. Crates loaded from the dependency search path are not candidates for crates which are loaded from the crate search path.
-
由 Steven Fackler 提交于
**The implementation is a direct adaptation of libcxx's condition_variable implementation.** pthread_cond_timedwait uses the non-monotonic system clock. It's possible to change the clock to a monotonic via pthread_cond_attr, but this is incompatible with static initialization. To deal with this, we calculate the timeout using the system clock, and maintain a separate record of the start and end times with a monotonic clock to be used for calculation of the return value.
-
由 Alex Crichton 提交于
With the addition of separate search paths to the compiler, it was intended that applications such as Cargo could require a `--extern` flag per `extern crate` directive in the source. The system can currently be subverted, however, due to the `existing_match()` logic in the crate loader. When loading crates we first attempt to match an `extern crate` directive against all previously loaded crates to avoid reading metadata twice. This "hit the cache if possible" step was erroneously leaking crates across the search path boundaries, however. For example: extern crate b; extern crate a; If `b` depends on `a`, then it will load crate `a` when the `extern crate b` directive is being processed. When the compiler reaches `extern crate a` it will use the previously loaded version no matter what. If the compiler was not invoked with `-L crate=path/to/a`, it will still succeed. This behavior is allowing `extern crate` declarations in Cargo without a corresponding declaration in the manifest of a dependency, which is considered a bug. This commit fixes this problem by keeping track of the origin search path for a crate. Crates loaded from the dependency search path are not candidates for crates which are loaded from the crate search path. As a result of this fix, this is a likely a breaking change for a number of Cargo packages. If the compiler starts informing that a crate can no longer be found, it likely means that the dependency was forgotten in your Cargo.toml. [breaking-change]
-
由 Alex Crichton 提交于
Loading methods from external crates was erroneously using the type's privacy for each method instead of each method's privacy. This commit fixes that. Closes #21202
-
由 Alex Crichton 提交于
-
由 bors 提交于
This fixes #16530 by hashing nullary structs [the same way as the empty tuple] (https://github.com/rust-lang/rust/blob/master/src/libcore/hash/mod.rs#L185). Other approaches are possible, but this was the simplest.
-
- 16 1月, 2015 27 次提交
-
-
由 bors 提交于
This PR adds rules for negative implementations. It follows pretty much what the [RFC](https://github.com/rust-lang/rfcs/blob/master/text/0019-opt-in-builtin-traits.md) says with 1 main difference: Instead of positive implementations override negative implementations, this have been implemented in a way that a negative implementation of `Trait` for `T` will overlap with a positive implementation, causing a coherence error. @nikomatsakis r? cc #13231 [breaking-change]
-
由 Huon Wilson 提交于
If `a.method();` can't be resolved, we first look for implemented traits globally and suggest those. If there are no such traits found, we only then fall back to suggesting from the unfiltered list of traits.
-
由 Huon Wilson 提交于
This seems to match what clang does on arm, but I cannot do any experimentation with mips, but it matches how the LLVM intrinsics are defined in any case...
-
由 Huon Wilson 提交于
Unlike the intrinics in C, this types the SSE values base on integer size. This matches the LLVM intrinsics which have concrete vector types (`<4 x i32>` etc.), and is no loss of expressivity: if one is using a C function that really takes an untyped integral SSE value, just give it whatever Rust type makes most sense.
-
由 Huon Wilson 提交于
-
由 Huon Wilson 提交于
This seems to work on x86-64, but I am not able to test on other platforms. cc #20043
-
由 Flavio Percoco 提交于
-
由 Flavio Percoco 提交于
-
由 Flavio Percoco 提交于
-
由 Flavio Percoco 提交于
-
由 Flavio Percoco 提交于
-
由 Flavio Percoco 提交于
-
由 Flavio Percoco 提交于
-
由 Flavio Percoco 提交于
-
由 Flavio Percoco 提交于
-
由 Flavio Percoco 提交于
-
由 Flavio Percoco 提交于
-
由 Flavio Percoco 提交于
-
由 Flavio Percoco 提交于
-
由 Flavio Percoco 提交于
-
由 Flavio Percoco 提交于
-
由 Flavio Percoco 提交于
-
由 Flavio Percoco 提交于
-
由 Flavio Percoco 提交于
-
由 bors 提交于
Fix commented graphs in src/doc/trpl/ownership.md Reviewed-by: huonw
-
由 bors 提交于
Fix std::sync::condvar::Condvar::notify_one docs Reviewed-by: alexcrichton
-
由 bors 提交于
Two minor fixes for save-analysis Reviewed-by: huonw
-