- 22 12月, 2015 2 次提交
-
-
由 Alex Crichton 提交于
This change modifies the feature gating of special `#[cfg]` attributes to not require a `#![feature]` directive in the crate-of-use if the source of the macro was declared with `#[allow_internal_unstable]`. This enables the standard library's macro for `thread_local!` to make use of the `#[cfg(target_thread_local)]` attribute despite it being feature gated (e.g. it's a hidden implementation detail).
-
由 Alex Crichton 提交于
Currently the standard library has some pretty complicated logic to detect whether #[thread_local] should be used or whether it's supported. This is also unfortunately not quite true for OSX where not all versions support the #[thread_local] attribute (only 10.7+ does). Compiling code for OSX 10.6 is typically requested via the MACOSX_DEPLOYMENT_TARGET environment variable (e.g. the linker recognizes this), but the standard library unfortunately does not respect this. This commit updates the compiler to add a `target_thread_local` cfg annotation if the platform being targeted supports the `#[thread_local]` attribute. This is feature gated for now, and it is only true on non-aarch64 Linux and 10.7+ OSX (e.g. what the module already does today). Logic has also been added to parse the deployment target environment variable.
-
- 19 12月, 2015 15 次提交
-
-
由 bors 提交于
-
由 bors 提交于
I think we can close #26873 with these tests.
-
由 bors 提交于
I didn't see any reason that debug couldn't be added to this object, since every field derives debug.
-
由 bors 提交于
This PR is a rebase of the original PR by @EddyB https://github.com/rust-lang/rust/pull/21836 with some unrebasable parts manually reapplied, feature gate added + type equality restriction added as described below. This implementation is partial because the type equality restriction is applied to all type ascription expressions and not only those in lvalue contexts. Thus, all difficulties with detection of these contexts and translation of coercions having effect in runtime are avoided. So, you can't write things with coercions like `let slice = &[1, 2, 3]: &[u8];`. It obviously makes type ascription less useful than it should be, but it's still much more useful than not having type ascription at all. In particular, things like `let v = something.iter().collect(): Vec<_>;` and `let u = t.into(): U;` work as expected and I'm pretty happy with these improvements alone. Part of https://github.com/rust-lang/rust/issues/23416
-
由 bors 提交于
This PR adds `memchr`and `memrchr` based on @BurntSushi 's rust-memchr crate to libstd (as discussed in #30151). I've update some places in libstd to use memchr/memrchr, but I am not sure if there are other places where it could be used as well. ref #30076
-
由 bors 提交于
-
由 Luqman Aden 提交于
-
由 Florian Hahn 提交于
-
由 bors 提交于
Make RFC 1214 warnings into errors, and rip out the "warn or err" associated machinery. Future such attempts should go through lints anyhow. There is a fair amount of fallout in the compile-fail tests, as WF checking now occurs earlier in the process. r? @arielb1
-
由 bors 提交于
Some notes: This patch enforces the rules from [RFC 136](https://github.com/rust-lang/rfcs/blob/master/text/0136-no-privates-in-public.md) and makes "private in public" a module-level concept and not crate-level. Only `pub` annotations are used by the new algorithm, crate-level exported node set produced by `EmbargoVisitor` is not used. The error messages are tweaked accordingly and don't use the word "exported" to avoid confusing people (https://github.com/rust-lang/rust/issues/29668). The old algorithm tried to be extra smart with impls, but it mostly led to unpredictable behavior and bugs like https://github.com/rust-lang/rust/issues/28325. The new algorithm tries to be as simple as possible - an impl is considered public iff its type is public and its trait is public (if presents). A type or trait is considered public if all its components are public, [complications](https://internals.rust-lang.org/t/limits-of-type-inference-smartness/2919) with private types leaking to other crates/modules through trait impls and type inference are deliberately ignored so far. The new algorithm is not recursive and uses the nice new facility `Crate::visit_all_items`! Obsolete pre-1.0 feature `visible_private_types` is removed. This is a [breaking-change]. The two main vectors of breakage are type aliases (https://github.com/rust-lang/rust/issues/28450) and impls (https://github.com/rust-lang/rust/issues/28325). I need some statistics from a crater run (cc @alexcrichton) to decide on the breakage mitigation strategy. UPDATE: All the new errors are reported as warnings controlled by a lint `private_in_public` and lint group `future_incompatible`, but the intent is to make them hard errors eventually. Closes https://github.com/rust-lang/rust/issues/28325 Closes https://github.com/rust-lang/rust/issues/28450 Closes https://github.com/rust-lang/rust/issues/29524 Closes https://github.com/rust-lang/rust/issues/29627 Closes https://github.com/rust-lang/rust/issues/29668 Closes https://github.com/rust-lang/rust/issues/30055 r? @nikomatsakis
-
由 Vadim Petrochenkov 提交于
Type aliases are still substituted when determining impl publicity
-
由 Niko Matsakis 提交于
associated machinery. Future such attempts should go through lints anyhow. There is a fair amount of fallout in the compile-fail tests, as WF checking now occurs earlier in the process.
-
由 Alex Burka 提交于
-
由 bors 提交于
Fixes #30371.
-
由 Vadim Petrochenkov 提交于
+ Rebase fixes
-
- 18 12月, 2015 23 次提交
-
-
由 bors 提交于
- Successful merges: #30272, #30286, #30365, #30381, #30384, #30398, #30406, #30408, #30420, #30431, #30447, #30452 - Failed merges:
-
由 Manish Goregaokar 提交于
LLVM doesn't really support reusing the same module to emit more than one file. One bug this causes is that the IR is invalidated by the stack coloring pass when emitting the first file, and then the IR verifier complains by the time we try to emit the second file. Also, we get different binaries with --emit=asm,link than with just --emit=link. In some cases leading to segfaults. Unfortunately, it seems that at this point in time, the most sensible option to circumvent this problem is to just clone the whole llvm module for the asm output if we need both, asm and obj file output. Fixes #24876 Fixes #26235
-
由 Manish Goregaokar 提交于
Added sentences for description of code and changed x in the example to an int
-
由 Manish Goregaokar 提交于
Remove a needless variable and simply a cfg().
-
由 Manish Goregaokar 提交于
Part of https://github.com/rust-lang/rust/pull/30095 not causing mysterious segfaults. r? @nrc
-
由 Florian Hahn 提交于
-
由 Florian Hahn 提交于
-
由 Florian Hahn 提交于
-
由 bors 提交于
previously the error was erased and a `non-const path` error was emitted at the location of the field access instead of at the overflow location (as can be seen in the playground: http://is.gd/EuAF5F )
-
由 Manish Goregaokar 提交于
The previous example had no chance of compiling in either form, due to the restrictive follow set for `ty`. This one has the desired behavior: http://is.gd/kYdw4g (well, I don't exactly desire this behavior at all, but it's true at least :p )
-
由 Manish Goregaokar 提交于
This fixes a double word typo, 'the'.
-
由 Manish Goregaokar 提交于
Should make it possible to add JSON or HTML errors. Also tidies up a lot.
-
由 Manish Goregaokar 提交于
previously the error was erased and a `non-const path` error was emitted at the location of the field access instead of at the overflow location (as can be seen in the playground: http://is.gd/EuAF5F )
-
由 bors 提交于
Second sentence actually repeats info from first sentence. "from start to end" also feels like it adds nothing. I also extended Vec::drain example.
-
由 Björn Steinbrink 提交于
LLVM doesn't really support reusing the same module to emit more than one file. One bug this causes is that the IR is invalidated by the stack coloring pass when emitting the first file, and then the IR verifier complains by the time we try to emit the second file. Also, we get different binaries with --emit=asm,link than with just --emit=link. In some cases leading to segfaults. Unfortunately, it seems that at this point in time, the most sensible option to circumvent this problem is to just clone the whole llvm module for the asm output if we need both, asm and obj file output. Fixes #24876 Fixes #26235
-
由 bors 提交于
It looks like #27937 accidentally switched the llvmdeps file from the target to the host by accident, so be sure to use the right llvmdeps file which is built for the target when building rustc_llvm
-
由 Vadim Petrochenkov 提交于
-
由 Vadim Petrochenkov 提交于
-
由 Vadim Petrochenkov 提交于
-
由 Vadim Petrochenkov 提交于
-
由 Vadim Petrochenkov 提交于
-
由 Vadim Petrochenkov 提交于
-
由 Vadim Petrochenkov 提交于
-