- 26 3月, 2016 40 次提交
-
-
由 Manish Goregaokar 提交于
Document heap allocation location guarantee ``` 14:25 < aidanhs> is there any guarantee that boxes will not move the value on the heap when they are moved? 14:26 <@steveklabnik> aidanhs: ... i'm not sure if it's a guarantee, but it follows, generally 14:26 <@steveklabnik> aidanhs: moves mean memcpy, so you're memcpying the structure of the box itself, which is copying the pointer 14:26 <@steveklabnik> so the pointer won't be updated 14:26 <@steveklabnik> moves cannot do complex things like move the memory around on the heap 14:26 <@kmc> aidanhs: I would say it's guaranteed 14:27 < aidanhs> steveklabnik: yeah, that's what I was thinking, it'd be pretty strange for rust to do something, but I couldn't find any docs one way or the other 14:27 <@steveklabnik> kmc: aidanhs yeah, it's like a borderline thing that we don't explicitly guanratee but i think IS guaranteed by our other guarantees 14:27 <@steveklabnik> mostly that move == memcpy 14:28 < aidanhs> kmc: steveklabnik great thanks! would a PR to the rust reference along these lines be ok? 14:28 < jmesmon> aidanhs: I believe owning_ref has some discussion of that (stable references) 14:29 <@steveklabnik> aidanhs: i would probably take that, yeah 14:29 < aidanhs> jmesmon: thanks, I'll take a look at that ``` https://botbot.me/mozilla/rust/2016-02-22/?msg=60657619&page=18 r? @steveklabnik
-
由 bors 提交于
configure: update required LLVM version Rust 1.7.0 and newer appears to require LLVM 3.6.0 or newer when building against a version that's out of the tree with the --llvm-root flag. Signed-off-by: NDoug Goldstein <cardoe@cardoe.com>
-
由 bors 提交于
Rollup of 11 pull requests - Successful merges: #32131, #32199, #32257, #32325, #32435, #32447, #32448, #32456, #32469, #32476, #32482 - Failed merges: #32240
-
由 Manish Goregaokar 提交于
-
由 Manish Goregaokar 提交于
use new visitor to erase regions r? @nagisa
-
由 Manish Goregaokar 提交于
Fix unsound behaviour with null characters in thread names (issue #32475) Previously, the thread name (&str) was converted to a CString in the new thread, but outside unwind::try, causing a panic to continue into FFI. This patch changes that behaviour, so that the panic instead happens in the parent thread (where panic infrastructure is properly set up), not the new thread. This could potentially be a breaking change for architectures who don't support thread names.
-
由 Manish Goregaokar 提交于
make available monomorphizations shared by CGU The current setup means that all generics are local to a codegen-unit, which means massive duplication.
-
由 Manish Goregaokar 提交于
Hardcode accepting 0 as a valid str char boundary If we check explicitly for index == 0, that removes the need to read the byte at index 0, so it avoids a trip to the string's memory, and it optimizes out the slicing index' bounds check whenever it is (a constant) zero.
-
由 Manish Goregaokar 提交于
Add augmented assignment operator impls for time types r? @alexcrichton
-
由 Manish Goregaokar 提交于
Remove ungrammatical dots from the error index. They were probably meant as a shorthand for omitted code. Part of #32446 but there should be a separate fix for the issue.
-
由 Manish Goregaokar 提交于
Some fixes for error recovery in the compiler
-
由 Manish Goregaokar 提交于
std: Fix inheriting stdin on status() This regression was accidentally introduced in #31618, and it's just flipping a boolean! Closes #32254
-
由 Manish Goregaokar 提交于
Restrict constants in patterns This implements [RFC 1445](https://github.com/rust-lang/rfcs/blob/master/text/1445-restrict-constants-in-patterns.md). The primary change is to limit the types of constants used in patterns to those that *derive* `Eq` (note that implementing `Eq` is not sufficient). This has two main effects: 1. Floating point constants are linted, and will eventually be disallowed. This is because floating point constants do not implement `Eq` but only `PartialEq`. This check replaces the existing special case code that aimed to detect the use of `NaN`. 2. Structs and enums must derive `Eq` to be usable within a match. This is a [breaking-change]: if you encounter a problem, you are most likely using a constant in an expression where the type of the constant is some struct that does not currently implement `Eq`. Something like the following: ```rust struct SomeType { ... } const SOME_CONST: SomeType = ...; match foo { SOME_CONST => ... } ``` The easiest and most future compatible fix is to annotate the type in question with `#[derive(Eq)]` (note that merely *implementing* `Eq` is not enough, it must be *derived*): ```rust struct SomeType { ... } const SOME_CONST: SomeType = ...; match foo { SOME_CONST => ... } ``` Another good option is to rewrite the match arm to use an `if` condition (this is also particularly good for floating point types, which implement `PartialEq` but not `Eq`): ```rust match foo { c if c == SOME_CONST => ... } ``` Finally, a third alternative is to tag the type with `#[structural_match]`; but this is not recommended, as the attribute is never expected to be stabilized. Please see RFC #1445 for more details. cc https://github.com/rust-lang/rust/issues/31434 r? @pnkfelix
-
由 Manish Goregaokar 提交于
resolve: Minimize hacks in name resolution of primitive types When resolving the first unqualified segment in a path with `n` segments and `n - 1` associated item segments, e.g. (`a` or `a::assoc` or `a::assoc::assoc` etc) try to resolve `a` without considering primitive types first. If the "normal" lookup fails or results in a module, then try to resolve `a` as a primitive type as a fallback. This way backward compatibility is respected, but the restriction from E0317 can be lifted, i.e. primitive names mostly can be shadowed like any other names. Furthermore, if names of primitive types are [put into prelude](https://github.com/petrochenkov/rust/tree/prim2) (now it's possible to do), then most of names will be resolved in conventional way and amount of code relying on this fallback will be greatly reduced. Although, it's not entirely convenient to put them into prelude right now due to temporary conflicts like `use prelude::v1::*; use usize;` in libcore/libstd, I'd better wait for proper glob shadowing before doing it. I wish the `no_prelude` attribute were unstable as intended :( cc @jseyfried @arielb1 r? @EddyB
-
由 bors 提交于
Revamp symbol names for impls (and make them deterministic, etc) This builds on @michaelwoerister's epic PR #31539 (note that his PR never landed, so I just incorporated it into this one). The main change here is that we remove the "name" from `DefPathData` for impls, since that name is synthetic and not sufficiently predictable for incr comp. However, just doing that would cause bad symbol names since those are based on the `DefPath`. Therefore, I introduce a new mechanism for getting symbol names (and also paths for user display) called `item_path`. This is kind of simplistic for now (based on strings) but I expect to expand it later to support richer types, hopefully generating C++-mangled names that gdb etc can understand. Along the way I cleaned up how we track the path that leads to an extern crate. There is still some cleanup left undone here. Notably, I didn't remove the impl names altogether -- that would probably make sense. I also didn't try to remove the `item_symbols` vector. Mostly I want to unblock my other incr. comp. work. =) r? @EddyB cc @EddyB @alexcrichton @michaelwoerister
-
由 Niko Matsakis 提交于
-
由 bors 提交于
resolve: Refactor how the prelude is handled This PR refactors how the prelude is handled in `resolve`. Instead of importing names from the prelude into each module's `resolutions`, this PR adds a new field `prelude: RefCell<Option<Module>>` to `ModuleS` that is set during import resolution but used only when resolving in a lexical scope (i.e. the scope of an initial segment of a relative path). r? @nikomatsakis
-
由 Jeffrey Seyfried 提交于
exclude the prelude from `resolve_name(.., allow_private_imports = true)`.
-
由 Jeffrey Seyfried 提交于
-
由 Jeffrey Seyfried 提交于
-
由 Jeffrey Seyfried 提交于
-
由 Jeffrey Seyfried 提交于
-
由 Niko Matsakis 提交于
-
由 Niko Matsakis 提交于
-
由 Niko Matsakis 提交于
-
由 Niko Matsakis 提交于
-
由 Niko Matsakis 提交于
-
由 Niko Matsakis 提交于
-
由 Niko Matsakis 提交于
-
由 Niko Matsakis 提交于
-
由 Niko Matsakis 提交于
the intention is to give some simple protection like link-guards but not impede ability to upgrade dylib in place
-
由 Niko Matsakis 提交于
This reverts commit b52004d202ddfffa100d4963216e1673a0be0b95.
-
由 Niko Matsakis 提交于
As discussed in https://github.com/rust-lang/rust/pull/32293#issuecomment-200597130, adding link guards are a heuristic that is causing undue complications: - the link guards inject extra public symbols, which is not always OK. - link guards as implemented could be a non-trivial performance hit, because no attempt is made to "de-duplicate" the dependency graph, so at worst you have O(N!) calls to the link guard functions. Nonetheless, link guards are very helpful in detecting errors, so it may be worth adding them back in some modified form in the future.
-
由 Niko Matsakis 提交于
Link guards cause problems in some specific scenarios on windows because they force libcore to be instantiated, since we do not GC functions effectively on windows. The changes here are two: 1. disable core for rsbegin/rsend 2. make panic_fmt an extern fn for smallest-hello-world so that it is not marked as "internal" for LLVM
-
由 Niko Matsakis 提交于
another name was added in the meantime
-
由 Niko Matsakis 提交于
Full binary reproducible builds are not possible on all platforms because linker injects a certain amount of randomness, apparently. Or, at minimum, they don't work reliably yet.
-
由 Niko Matsakis 提交于
-
由 Niko Matsakis 提交于
-
由 Niko Matsakis 提交于
-
由 Niko Matsakis 提交于
Gah. I always find it confusing that make tidy gives me the highest error code, but not the **next** error code.
-