Merged
Conversation
use the `getentropy()` function instead of `syscall()` and syscall-numbers.
define `num_cpus()` function for openbsd that use `HW_NCPU` for grabbing the current number of cpus that could be used.
`siginfo_si_addr()` function is used once, and the returned value is casted to `usize`. So make the function returns a `usize`. it simplifies OpenBSD case, where the return type wouldn't be a `*mut libc::c_void` but a `*mut libc::c_char`.
In particular, bring back the `zero` flag for `lvalue_scratch_datum`, which controls whether the alloca's created immediately at function start are uninitialized at that point or have their embedded drop-flags initialized to "dropped". Then made `to_lvalue_datum_in_scope` pass "dropped" as `zero` flag.
In 8d90d3f `BufStream`, the only consumer of `InternalBufWriter`, was removed. As implied by the name, this type is private, hence it is currently dead code.
…le`s to fix memory leaks from Rc cycles
includes bugfixes pointed out during review: * Only `call_lifetime_start` for an alloca if the function entry does not itself initialize it to "dropped." * Remove `schedule_lifetime_end` after writing an *element* into a borrowed slice. (As explained by [dotdash][irc], "the lifetime end that is being removed was for an element in the slice, which is not an alloca of its own and has no lifetime start of its own") [irc]: https://botbot.me/mozilla/rust-internals/2016-01-13/?msg=57844504&page=3
…st-lang#30530, rust-lang#30822. Note that the test for rust-lang#30822 is folded into the test for rust-lang#30530 (but the file name mentions only 30530).
(The reason this is not factored as far as possible because a subsequent commit is going to need to do construction without having access to a `cx`.)
(This can/should be revisited when drop flags are stored out of band.)
(Note that it might be a good idea to replace *all* calls of `alloc_ty` with calls to `alloc_ty_init`, to encourage programmers to consider the appropriate value for the `init` flag when creating temporary values.)
Contributor
|
r? @jroesch (rust_highfive has picked a reviewer for you, use r? to override) |
Member
Author
|
@bors r+ p=100 |
Collaborator
|
📌 Commit 9ec003e has been approved by |
Collaborator
|
⌛ Testing commit 9ec003e with merge fedac8f... |
Collaborator
|
💔 Test failed - auto-win-msvc-64-opt |
Fixes rust-lang#30345 I'm not sure if there's anything else that belongs here. Thoughts?
This adds the ability to override the default OOM behavior by setting a handler function. This is used by libstd to print a message when running out of memory instead of crashing with an obscure "illegal hardware instruction" error (at least on Linux). Fixes rust-lang#14674
tikue pointed out in IRC that this was missing.
…r-issue-30530, r=dotdash Put back alloca zeroing for issues rust-lang#29092, rust-lang#30018, rust-lang#30530; inject zeroing for rust-lang#30822. ---- Background context: `fn alloca_zeroed` was removed in PR rust-lang#22969, so we haven't been "zero'ing" (\*) the alloca's since at least that point, but the logic behind that PR seems sound, so its not entirely obvious how *long* the underlying bug has actually been present. In other words, I have not yet done a survey to see when the new `alloc_ty` and `lvalue_scratch_datum` calls were introduced that should have had "zero'ing" the alloca's. ---- I first fixed rust-lang#30018, then decided to do a survey of `alloc_ty` calls to see if they needed similar treatment, which quickly led to a rediscovery of rust-lang#30530. While making the regression test for the latter, I discovered rust-lang#30822, which is a slightly different bug (in terms of where the "zero'ing" needs to go), but still relevant. I haven't finished the aforementioned survey of `fn alloc_ty` calls, but I decided I wanted to get this up for review in its current state (namely to see if my attempt to force developers to include a justification for passing `Uninit` can possibly fly, or if I should abandon that path of action). ---- (*): I am putting quotation marks around "zero'ing" because we no longer use zero as our "dropped" marker value. Fix rust-lang#29092 Fix rust-lang#30018 Fix rust-lang#30530 Fix rust-lang#30822
See [the intrinsics page](https://doc.rust-lang.org/nightly/core/intrinsics/index.html) for example.
I think this will fix rust-lang#30656.
The following PR updates libc version to latest commits for correctly support openbsd. It corrects several points in rustc to be compatible with libc changes. r? @alexcrichton
…sakis All the trait implementations of `PhantomData` use `impl<T: ?Sized>` except for `Debug` https://doc.rust-lang.org/nightly/std/marker/struct.PhantomData.html#implementations This PR fixes this.
In 8d90d3f `BufStream`, the only consumer of `InternalBufWriter`, was removed. As implied by the name, this type is private, hence it is currently dead code.
… r=pnkfelix
Apparently we allocate and maintain non-working dropflag hints since June... In anticipation of a working implementation of on-stack drop flag hints, let's not spend even more time on types that don't even need to be dropped.
```rust
fn main() {
let (i,j,k,l) = (0,0,0,0);
}
```
used to translate to (unoptimized only, of course):
```llvm
define internal void @_ZN4main20ha8deb085c47920d8eaaE() unnamed_addr #0 {
entry-block:
%dropflag_hint_10 = alloca i8
%dropflag_hint_11 = alloca i8
%dropflag_hint_12 = alloca i8
%dropflag_hint_13 = alloca i8
%const = alloca { i32, i32, i32, i32 }
%i = alloca i32
%j = alloca i32
%k = alloca i32
%l = alloca i32
store i8 61, i8* %dropflag_hint_10
store i8 61, i8* %dropflag_hint_11
store i8 61, i8* %dropflag_hint_12
store i8 61, i8* %dropflag_hint_13
%0 = bitcast { i32, i32, i32, i32 }* %const to i8*
call void @llvm.memcpy.p0i8.p0i8.i64(i8* %0, i8* bitcast ({ i32, i32, i32, i32 }* @const2752 to i8*), i64 16, i32 4, i1 false)
%1 = getelementptr inbounds { i32, i32, i32, i32 }, { i32, i32, i32, i32 }* %const, i32 0, i32 0
%2 = load i32, i32* %1, align 4
store i32 %2, i32* %i, align 4
%3 = getelementptr inbounds { i32, i32, i32, i32 }, { i32, i32, i32, i32 }* %const, i32 0, i32 1
%4 = load i32, i32* %3, align 4
store i32 %4, i32* %j, align 4
%5 = getelementptr inbounds { i32, i32, i32, i32 }, { i32, i32, i32, i32 }* %const, i32 0, i32 2
%6 = load i32, i32* %5, align 4
store i32 %6, i32* %k, align 4
%7 = getelementptr inbounds { i32, i32, i32, i32 }, { i32, i32, i32, i32 }* %const, i32 0, i32 3
%8 = load i32, i32* %7, align 4
store i32 %8, i32* %l, align 4
ret void
}
```
Now it gives:
```llvm
define internal void @_ZN4main20ha8deb085c47920d8eaaE() unnamed_addr #0 {
entry-block:
%const = alloca { i32, i32, i32, i32 }
%i = alloca i32
%j = alloca i32
%k = alloca i32
%l = alloca i32
%0 = bitcast { i32, i32, i32, i32 }* %const to i8*
call void @llvm.memcpy.p0i8.p0i8.i64(i8* %0, i8* bitcast ({ i32, i32, i32, i32 }* @const2748 to i8*), i64 16, i32 4, i1 false)
%1 = getelementptr inbounds { i32, i32, i32, i32 }, { i32, i32, i32, i32 }* %const, i32 0, i32 0
%2 = load i32, i32* %1, align 4
store i32 %2, i32* %i, align 4
%3 = getelementptr inbounds { i32, i32, i32, i32 }, { i32, i32, i32, i32 }* %const, i32 0, i32 1
%4 = load i32, i32* %3, align 4
store i32 %4, i32* %j, align 4
%5 = getelementptr inbounds { i32, i32, i32, i32 }, { i32, i32, i32, i32 }* %const, i32 0, i32 2
%6 = load i32, i32* %5, align 4
store i32 %6, i32* %k, align 4
%7 = getelementptr inbounds { i32, i32, i32, i32 }, { i32, i32, i32, i32 }* %const, i32 0, i32 3
%8 = load i32, i32* %7, align 4
store i32 %8, i32* %l, align 4
ret void
}
```
Let's hope I didn't break anything!
Use arena allocation instead of reference counting for `Module`s to fix memory leaks from `Rc` cycles.
A module references its module children and its import resolutions, and an import resolution references the module defining the imported name, so there is a cycle whenever a module imports something from an ancestor module.
For example,
```rust
mod foo { // `foo` references `bar`.
fn baz() {}
mod bar { // `bar` references the import.
use foo::baz; // The import references `foo`.
}
}
```
Member
Author
|
@bors r+ |
Collaborator
|
📌 Commit 1246f43 has been approved by |
Collaborator
Collaborator
|
💔 Test failed - auto-linux-64-nopt-t |
Member
Author
|
@bors retry force |
Collaborator
|
⚡ Previous build results for auto-linux-32-nopt-t, auto-linux-32-opt, auto-linux-64-debug-opt, auto-linux-64-opt, auto-linux-cross-opt, auto-linux-musl-64-opt, auto-mac-32-opt, auto-mac-64-nopt-t, auto-mac-64-opt, auto-win-msvc-32-opt are reusable. Rebuilding only auto-linux-64-nopt-t, auto-linux-64-x-android-t, auto-win-gnu-32-nopt-t, auto-win-gnu-32-opt, auto-win-gnu-64-nopt-t, auto-win-gnu-64-opt, auto-win-msvc-64-opt... |
Collaborator
|
💔 Test failed - auto-linux-64-nopt-t |
Member
Author
|
@bors retry force |
Collaborator
|
⚡ Previous build results for auto-linux-32-nopt-t, auto-linux-32-opt, auto-linux-64-debug-opt, auto-linux-64-opt, auto-linux-cross-opt, auto-linux-musl-64-opt, auto-mac-32-opt, auto-mac-64-nopt-t, auto-mac-64-opt, auto-win-msvc-32-opt are reusable. Rebuilding only auto-linux-64-nopt-t, auto-linux-64-x-android-t, auto-win-gnu-32-nopt-t, auto-win-gnu-32-opt, auto-win-gnu-64-nopt-t, auto-win-gnu-64-opt, auto-win-msvc-64-opt... |
Collaborator
This was referenced Jan 14, 2016
Merged
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
16 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
InternalBufWriterimplementation #30850, Don't use dropflag hints when the type is dropless #30851, Fix memory leak in resolve #30863