-
Notifications
You must be signed in to change notification settings - Fork 12.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Rollup of 15 pull requests #30883
Rollup of 15 pull requests #30883
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.)
r? @jroesch (rust_highfive has picked a reviewer for you, use r? to override) |
@bors r+ p=100 |
📌 Commit 9ec003e has been approved by |
⌛ Testing commit 9ec003e with merge fedac8f... |
💔 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`. } } ```
@bors r+ |
📌 Commit 1246f43 has been approved by |
💔 Test failed - auto-linux-64-nopt-t |
@bors retry force |
⚡ 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... |
💔 Test failed - auto-linux-64-nopt-t |
@bors retry force |
⚡ 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... |
InternalBufWriter
implementation #30850, Don't use dropflag hints when the type is dropless #30851, Fix memory leak in resolve #30863