Skip to content
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

Associate an allocator to boxes #58457

Open
wants to merge 2 commits into
base: master
from

Conversation

@glandium
Copy link
Contributor

commented Feb 14, 2019

This turns Box<T> into Box<T, A = Global>, with a A: Alloc bound
for impls.

Ideally, inherent methods like Box::new would be applied to
Box<T, A: Alloc + Default>, but as of now, that would be backwards
incompatible because it would require type annotations in places where
they currently aren't required.

impl FromIterator is not covered because it relies on Vec, which
would need allocator awareness.

DispatchFromDyn is left out or being generic over A because there
is no bound that would make it work currently. FnBox is left out
because it's related to DispatchFromDyn.

@rust-highfive

This comment has been minimized.

Copy link
Collaborator

commented Feb 14, 2019

r? @Mark-Simulacrum

(rust_highfive has picked a reviewer for you, use r? to override)

@glandium

This comment has been minimized.

Copy link
Contributor Author

commented Feb 14, 2019

@rust-highfive

This comment has been minimized.

Copy link
Collaborator

commented Feb 14, 2019

The job x86_64-gnu-llvm-6.0 of your PR failed on Travis (raw log). Through arcane magic we have determined that the following fragments from the build log may contain information about the problem.

Click to expand the log.
travis_time:end:053dfaa0:start=1550131794107733276,finish=1550131795060649094,duration=952915818
$ git checkout -qf FETCH_HEAD
travis_fold:end:git.checkout

Encrypted environment variables have been removed for security reasons.
See https://docs.travis-ci.com/user/pull-requests/#pull-requests-and-security-restrictions
$ export SCCACHE_BUCKET=rust-lang-ci-sccache2
$ export SCCACHE_REGION=us-west-1
Setting environment variables from .travis.yml
$ export IMAGE=x86_64-gnu-llvm-6.0
---

[00:03:41] travis_fold:start:tidy
travis_time:start:tidy
tidy check
[00:03:41] tidy error: /checkout/src/liballoc/boxed.rs:819: line longer than 100 chars
[00:03:41] tidy error: /checkout/src/liballoc/boxed.rs:831: line longer than 100 chars
[00:03:43] some tidy checks failed
[00:03:43] 
[00:03:43] 
[00:03:43] command did not execute successfully: "/checkout/obj/build/x86_64-unknown-linux-gnu/stage0-tools-bin/tidy" "/checkout/src" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage0/bin/cargo" "--no-vendor" "--quiet"
[00:03:43] 
[00:03:43] 
[00:03:43] failed to run: /checkout/obj/build/bootstrap/debug/bootstrap test src/tools/tidy
[00:03:43] Build completed unsuccessfully in 0:00:43
[00:03:43] Build completed unsuccessfully in 0:00:43
[00:03:43] make: *** [tidy] Error 1
[00:03:43] Makefile:68: recipe for target 'tidy' failed
The command "stamp sh -x -c "$RUN_SCRIPT"" exited with 2.
travis_time:start:07811662
$ date && (curl -fs --head https://google.com | grep ^Date: | sed 's/Date: //g' || true)
Thu Feb 14 08:13:48 UTC 2019
---
travis_time:end:02c0f0e8:start=1550132029647321317,finish=1550132029651571203,duration=4249886
travis_fold:end:after_failure.3
travis_fold:start:after_failure.4
travis_time:start:0267e6a0
$ ln -s . checkout && for CORE in obj/cores/core.*; do EXE=$(echo $CORE | sed 's|obj/cores/core\.[0-9]*\.!checkout!\(.*\)|\1|;y|!|/|'); if [ -f "$EXE" ]; then printf travis_fold":start:crashlog\n\033[31;1m%s\033[0m\n" "$CORE"; gdb --batch -q -c "$CORE" "$EXE" -iex 'set auto-load off' -iex 'dir src/' -iex 'set sysroot .' -ex bt -ex q; echo travis_fold":"end:crashlog; fi; done || true
travis_fold:end:after_failure.4
travis_fold:start:after_failure.5
travis_time:start:038921a0
travis_time:start:038921a0
$ cat ./obj/build/x86_64-unknown-linux-gnu/native/asan/build/lib/asan/clang_rt.asan-dynamic-i386.vers || true
cat: ./obj/build/x86_64-unknown-linux-gnu/native/asan/build/lib/asan/clang_rt.asan-dynamic-i386.vers: No such file or directory
travis_fold:end:after_failure.5
travis_fold:start:after_failure.6
travis_time:start:20dd8622
$ dmesg | grep -i kill

I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact @TimNN. (Feature Requests)

@glandium glandium force-pushed the glandium:box branch from 1cfaffd to 0244789 Feb 14, 2019

@rust-highfive

This comment has been minimized.

Copy link
Collaborator

commented Feb 14, 2019

The job x86_64-gnu-llvm-6.0 of your PR failed on Travis (raw log). Through arcane magic we have determined that the following fragments from the build log may contain information about the problem.

Click to expand the log.
travis_time:end:0f619200:start=1550133308740812575,finish=1550133309708794144,duration=967981569
$ git checkout -qf FETCH_HEAD
travis_fold:end:git.checkout

Encrypted environment variables have been removed for security reasons.
See https://docs.travis-ci.com/user/pull-requests/#pull-requests-and-security-restrictions
$ export SCCACHE_BUCKET=rust-lang-ci-sccache2
$ export SCCACHE_REGION=us-west-1
Setting environment variables from .travis.yml
$ export IMAGE=x86_64-gnu-llvm-6.0
---
[01:09:51] .................................................................................................... 1500/2949
[01:10:01] .......................................................................i............................ 1600/2949
[01:10:15] .................................................................................................... 1700/2949
[01:10:28] .................................................................................................... 1800/2949
[01:10:39] ...............................................................................F.................... 1900/2949
[01:11:19] .................................................................................................... 2100/2949
[01:11:40] ................................................................................test [run-pass] run-pass/mpsc_stress.rs has been running for over 60 seconds
[01:11:42] .................... 2200/2949
[01:11:53] .....................................................................ii............................. 2300/2949
---
[01:13:37] 
[01:13:37] thread 'main' panicked at 'Some tests failed', src/tools/compiletest/src/main.rs:496:22
[01:13:37] 
[01:13:37] 
[01:13:37] command did not execute successfully: "/checkout/obj/build/x86_64-unknown-linux-gnu/stage0-tools-bin/compiletest" "--compile-lib-path" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage2/lib" "--run-lib-path" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage2/lib/rustlib/x86_64-unknown-linux-gnu/lib" "--rustc-path" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage2/bin/rustc" "--src-base" "/checkout/src/test/run-pass" "--build-base" "/checkout/obj/build/x86_64-unknown-linux-gnu/test/run-pass" "--stage-id" "stage2-x86_64-unknown-linux-gnu" "--mode" "run-pass" "--target" "x86_64-unknown-linux-gnu" "--host" "x86_64-unknown-linux-gnu" "--llvm-filecheck" "/usr/lib/llvm-6.0/bin/FileCheck" "--host-rustcflags" "-Crpath -O -Zunstable-options  -Lnative=/checkout/obj/build/x86_64-unknown-linux-gnu/native/rust-test-helpers" "--target-rustcflags" "-Crpath -O -Zunstable-options  -Lnative=/checkout/obj/build/x86_64-unknown-linux-gnu/native/rust-test-helpers" "--docck-python" "/usr/bin/python2.7" "--lldb-python" "/usr/bin/python2.7" "--gdb" "/usr/bin/gdb" "--quiet" "--llvm-version" "6.0.0\n" "--system-llvm" "--cc" "" "--cxx" "" "--cflags" "" "--llvm-components" "" "--llvm-cxxflags" "" "--adb-path" "adb" "--adb-test-dir" "/data/tmp/work" "--android-cross-path" "" "--color" "always"
[01:13:37] 
[01:13:37] 
[01:13:37] failed to run: /checkout/obj/build/bootstrap/debug/bootstrap test
[01:13:37] Build completed unsuccessfully in 0:11:01
[01:13:37] Build completed unsuccessfully in 0:11:01
[01:13:37] make: *** [check] Error 1
[01:13:37] Makefile:48: recipe for target 'check' failed
The command "stamp sh -x -c "$RUN_SCRIPT"" exited with 2.
travis_time:start:1dcf5473
$ date && (curl -fs --head https://google.com | grep ^Date: | sed 's/Date: //g' || true)
Thu Feb 14 09:48:59 UTC 2019

I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact @TimNN. (Feature Requests)

@glandium

This comment has been minimized.

Copy link
Contributor Author

commented Feb 14, 2019

Aha, this is something I had already hit in the allocator_api crate but didn't transpose to my rustc branch.

@glandium glandium force-pushed the glandium:box branch from 0244789 to ae9bdf3 Feb 14, 2019

@kennytm

This comment has been minimized.

Copy link
Member

commented Feb 14, 2019

Previous attempts for reference: #55139, #50882 (all blocked by #52694 which has been closed).

@SimonSapin

This comment has been minimized.

Copy link
Contributor

commented Feb 14, 2019

How is Default related to the allocator handle being zero-size or DyspatchFromDyn? https://doc.rust-lang.org/std/default/trait.Default.html#implementors contains many non-zero-size types.

@glandium

This comment has been minimized.

Copy link
Contributor Author

commented Feb 14, 2019

How is Default related to the allocator handle being zero-size or DyspatchFromDyn? https://doc.rust-lang.org/std/default/trait.Default.html#implementors contains many non-zero-size types.

It's not related, what is is PhantomData. Default is used to get an allocator from nothing.

@glandium

This comment has been minimized.

Copy link
Contributor Author

commented Feb 14, 2019

It's not related, what is is PhantomData. Default is used to get an allocator from nothing.

And you won't be able to do anything useful with a non-ZST allocator since we're always using default().

@kennytm

This comment has been minimized.

Copy link
Member

commented Feb 14, 2019

This implementation means A::default() must be able to deallocate memory allocated from any instance of A. 😕

I think it's better just to implement the "quick and dirty" solution from #50882 (comment).

@glandium

This comment has been minimized.

Copy link
Contributor Author

commented Feb 14, 2019

This implementation means A::default() must be able to deallocate memory allocated from any instance of A. confused

I think it's better just to implement the "quick and dirty" solution from #50882 (comment).

2 things:

  • that doesn't address the compiler end of the "box can't be larger than a pointer" problem.
  • I have no clue how to even do it.

I'd rather have /something/ than wait even more for the above to be addressed.

@rust-highfive

This comment has been minimized.

Copy link
Collaborator

commented Feb 14, 2019

The job x86_64-gnu-llvm-6.0 of your PR failed on Travis (raw log). Through arcane magic we have determined that the following fragments from the build log may contain information about the problem.

Click to expand the log.
travis_time:end:0001dd24:start=1550141804655293538,finish=1550141806916553600,duration=2261260062
$ git checkout -qf FETCH_HEAD
travis_fold:end:git.checkout

Encrypted environment variables have been removed for security reasons.
See https://docs.travis-ci.com/user/pull-requests/#pull-requests-and-security-restrictions
$ export SCCACHE_BUCKET=rust-lang-ci-sccache2
$ export SCCACHE_REGION=us-west-1
Setting environment variables from .travis.yml
$ export IMAGE=x86_64-gnu-llvm-6.0
---
travis_time:start:test_codegen
Check compiletest suite=codegen mode=codegen (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu)
[01:12:02] 
[01:12:02] running 130 tests
[01:12:05] i..iii...iii..iiiiF....i.................i..i................i.....i.........ii...i..i.ii........... 100/130
[01:12:06] failures:
[01:12:06] 
[01:12:06] ---- [codegen] codegen/box-maybe-uninit.rs stdout ----
[01:12:06] 
[01:12:06] 
[01:12:06] error: verification with 'FileCheck' failed
[01:12:06] status: exit code: 1
[01:12:06] command: "/usr/lib/llvm-6.0/bin/FileCheck" "--input-file" "/checkout/obj/build/x86_64-unknown-linux-gnu/test/codegen/box-maybe-uninit/box-maybe-uninit.ll" "/checkout/src/test/codegen/box-maybe-uninit.rs"
[01:12:06] ------------------------------------------
[01:12:06] 
[01:12:06] ------------------------------------------
[01:12:06] stderr:
[01:12:06] stderr:
[01:12:06] ------------------------------------------
[01:12:06] /checkout/obj/build/x86_64-unknown-linux-gnu/test/codegen/box-maybe-uninit/box-maybe-uninit.ll:28:2: error: CHECK-NOT: string occurred!
[01:12:06]  store i64 8, i64* %.fca.0.gep.i.i, align 8
[01:12:06]  ^
[01:12:06] /checkout/src/test/codegen/box-maybe-uninit.rs:11:16: note: CHECK-NOT: pattern specified here
[01:12:06]  // CHECK-NOT: store
[01:12:06] 
[01:12:06] ------------------------------------------
[01:12:06] 
[01:12:06] thread '[codegen] codegen/box-maybe-uninit.rs' panicked at 'explicit panic', src/tools/compiletest/src/runtest.rs:3295:9
---
[01:12:06] 
[01:12:06] thread 'main' panicked at 'Some tests failed', src/tools/compiletest/src/main.rs:496:22
[01:12:06] 
[01:12:06] 
[01:12:06] command did not execute successfully: "/checkout/obj/build/x86_64-unknown-linux-gnu/stage0-tools-bin/compiletest" "--compile-lib-path" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage2/lib" "--run-lib-path" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage2/lib/rustlib/x86_64-unknown-linux-gnu/lib" "--rustc-path" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage2/bin/rustc" "--src-base" "/checkout/src/test/codegen" "--build-base" "/checkout/obj/build/x86_64-unknown-linux-gnu/test/codegen" "--stage-id" "stage2-x86_64-unknown-linux-gnu" "--mode" "codegen" "--target" "x86_64-unknown-linux-gnu" "--host" "x86_64-unknown-linux-gnu" "--llvm-filecheck" "/usr/lib/llvm-6.0/bin/FileCheck" "--host-rustcflags" "-Crpath -O -Zunstable-options  -Lnative=/checkout/obj/build/x86_64-unknown-linux-gnu/native/rust-test-helpers" "--target-rustcflags" "-Crpath -O -Zunstable-options  -Lnative=/checkout/obj/build/x86_64-unknown-linux-gnu/native/rust-test-helpers" "--docck-python" "/usr/bin/python2.7" "--lldb-python" "/usr/bin/python2.7" "--gdb" "/usr/bin/gdb" "--quiet" "--llvm-version" "6.0.0\n" "--system-llvm" "--cc" "" "--cxx" "" "--cflags" "" "--llvm-components" "" "--llvm-cxxflags" "" "--adb-path" "adb" "--adb-test-dir" "/data/tmp/work" "--android-cross-path" "" "--color" "always"
[01:12:06] 
[01:12:06] 
[01:12:06] failed to run: /checkout/obj/build/bootstrap/debug/bootstrap test
[01:12:06] Build completed unsuccessfully in 0:11:28
[01:12:06] Build completed unsuccessfully in 0:11:28
[01:12:06] make: *** [check] Error 1
[01:12:06] Makefile:48: recipe for target 'check' failed
The command "stamp sh -x -c "$RUN_SCRIPT"" exited with 2.
travis_time:start:012ebd40
$ date && (curl -fs --head https://google.com | grep ^Date: | sed 's/Date: //g' || true)
Thu Feb 14 12:09:05 UTC 2019

I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact @TimNN. (Feature Requests)

@glandium

This comment has been minimized.

Copy link
Contributor Author

commented Feb 14, 2019

Haha, moving off the box keyword broke codegen/box-maybe-uninit.rs. This means that even if Box::new is restored to use the box keyword, Box::new_in(MaybeUninit::uninitialized(), alloc) would still copy garbage from the stack.

@Mark-Simulacrum

This comment has been minimized.

Copy link
Member

commented Feb 14, 2019

@glandium

This comment has been minimized.

Copy link
Contributor Author

commented Feb 14, 2019

Also, the codegen/box-maybe-uninit.rs test is kind of biased... If it was using Box<MaybeUninit<[usize;40]>>, it wouldn't pass already.

What do we do about this? Keeping the box keyword where it's currently used means:

  • restoring Box::new and Box::pin to be unmodified, not much of a problem
  • using specialization for Default and Clone to use the box keyword for Global

That's all artificial to keep things nicer for Global, at the cost of silently making things "bad" for other allocators.

@glandium

This comment has been minimized.

Copy link
Contributor Author

commented Feb 14, 2019

In fact, it doesn't even pass with Box<MaybeUninit<[usize;2]>>. Funnily enough, it does pass for Box<MaybeUninit<(usize, usize)>>.

@glandium

This comment has been minimized.

Copy link
Contributor Author

commented Feb 14, 2019

And it fails for Box<MaybeUninit<(usize, usize, usize)>>. I'm ready to say this test is not very useful...

@SimonSapin

This comment has been minimized.

Copy link
Contributor

commented Feb 14, 2019

I see, in this PR the Box struct contains a field with type PhantomData<A> rather than A, and uses Default every time it needs a value of type A.

I think this hack can be useful to experiment with e.g. adding a type parameter and see the effects on type inference, find bugs in the compiler, etc. However I think we maybe shouldn’t land it: it’s reasonable for an allocator that has per-instance state to implement Default for its constructor, and this PR would end up using different instance to manage the same box.

@glandium

This comment has been minimized.

Copy link
Contributor Author

commented Feb 14, 2019

@SimonSapin Your message makes me realize there's something fundamentally dangerous with Alloc. What kind of state could be kept in an Alloc that would be kept inside each and every box associated with it? None that could be created with Default, if you ask me.

In case the above is not entirely clear, take this example:

struct StatefulAlloc {
    next_free: *mut u8,
}

impl Alloc for StatefulAlloc { ... }

// Do stuff with Box<T, StatefulAlloc>

I don't see actual examples where the above uses would make sense.

However

impl<'a> Alloc for &'a StatefulAlloc { ... }

// Do stuff with Box<T, &StatefulAlloc>

does make sense. An alternative would be

struct MyGlobalStatefulAlloc;

static mut MyGlobalAllocState: StatefulAlloc = StatefulAlloc::default();

impl Alloc for MyGlobalStatefulAlloc { /* impl using MyGlobalAllocState */ }

IOW, the usecases are either ZSTs or refs, and other kinds of types make little sense. And a generic Alloc doesn't put such restrictions. Without such restrictions, you can be sure a lot of people are actually going to shoot themselves in the foot like in the first example above.

@SimonSapin

This comment has been minimized.

Copy link
Contributor

commented Feb 14, 2019

That’s a good point. In my previous message I somewhat confused an allocator "instance" (which could be shared between many Boxes and Vecs etc) and the "handle" to it kept inside each Box struct.

So it’s true that the "bad" cases are probably not useful, but Default is still not the correct bound for this IMO.

the compiler itself only really supports ZSTs for the extra fields in the Box type, and DyspatchFromDyn only allows PhantomData extra fields

Those might be dependent bugs that should be fixed before we can land this.

@phil-opp

This comment has been minimized.

Copy link
Contributor

commented Feb 14, 2019

struct StatefulAlloc {
    next_free: *mut u8,
}

impl Alloc for StatefulAlloc { ... }

// Do stuff with Box<T, StatefulAlloc>

I don't see actual examples where the above uses would make sense.

Maybe not for Box, but it could make sense for Vec and other growable collection types. For example, a critical Vec could use it's own heap area to guarantee that it won't be affected when the rest of the program runs out of memory. By taking ownership of the Alloc instance, there is no synchronization overhead.

@Ericson2314

This comment has been minimized.

Copy link
Contributor

commented Feb 14, 2019

I really would like to land something, no matter how piecemeal, just to make forward progress. For example, once @glandium lands something, I can use the same hacks that end up being used to get #52420 to work, in parallel to people trying to obviate those hacks. As long as the stable APIs of things aren't broken, it should be OK, right?

@@ -83,7 +84,7 @@ use crate::str::from_boxed_utf8_unchecked;
#[lang = "owned_box"]
#[fundamental]
#[stable(feature = "rust1", since = "1.0.0")]
pub struct Box<T: ?Sized>(Unique<T>);
pub struct Box<T: ?Sized, A: Alloc + Default = Global>(Unique<T>, PhantomData<A>);

This comment has been minimized.

Copy link
@scottmcm

scottmcm Feb 14, 2019

Member

Curiosity: Why include the trait bounds here? I don't recall anywhere else the libraries do that when the definition of the type doesn't need something from one of the traits.

Also, this new type parameter is insta-stable, right? Is that a concern? (Would it work to make the lang item an unstable CustomBox<T, A>, and have type Box<T> = CustomBox<T, Global>; for now?)

This comment has been minimized.

Copy link
@glandium

glandium Feb 14, 2019

Author Contributor

Curiosity: Why include the trait bounds here?

I don't know, that kind of ensures the bounds on all the various impls are right?

Also, this new type parameter is insta-stable, right? Is that a concern?

Insta-stable, yes. A concern? I don't know.

(Would it work to make the lang item an unstable CustomBox<T, A>, and have type Box<T> = CustomBox<T, Global>; for now?)

Unfortunately, the compiler desugars such aliases when printing errors. See #50882 (comment) (the part about the extra parameter doesn't apply anymore)

Centril added a commit to Centril/rust that referenced this pull request May 1, 2019

Rollup merge of rust-lang#60369 - TimDiekmann:dispatch-zst, r=eddyb
Support ZSTs in DispatchFromDyn

Allows to use ZSTs with 1 byte alignment in `DispatchFromDyn` implementation. This is required for `Box<T, A: Alloc>`

cc rust-lang#58457

Centril added a commit to Centril/rust that referenced this pull request May 1, 2019

Rollup merge of rust-lang#60369 - TimDiekmann:dispatch-zst, r=eddyb
Support ZSTs in DispatchFromDyn

Allows to use ZSTs with 1 byte alignment in `DispatchFromDyn` implementation. This is required for `Box<T, A: Alloc>`

cc rust-lang#58457

Centril added a commit to Centril/rust that referenced this pull request May 1, 2019

Rollup merge of rust-lang#60369 - TimDiekmann:dispatch-zst, r=eddyb
Support ZSTs in DispatchFromDyn

Allows to use ZSTs with 1 byte alignment in `DispatchFromDyn` implementation. This is required for `Box<T, A: Alloc>`

cc rust-lang#58457
@SimonSapin

This comment has been minimized.

Copy link
Contributor

commented May 3, 2019

Landing this should be blocked on resolving rust-lang/wg-allocators#2 one way or another, in my opinion.

@rust-highfive

This comment has been minimized.

Copy link
Collaborator

commented May 3, 2019

The job x86_64-gnu-llvm-6.0 of your PR failed on Travis (raw log). Through arcane magic we have determined that the following fragments from the build log may contain information about the problem.

Click to expand the log.
travis_time:end:1d0cdd50:start=1556893065462725387,finish=1556893066319475169,duration=856749782
$ git checkout -qf FETCH_HEAD
travis_fold:end:git.checkout

Encrypted environment variables have been removed for security reasons.
See https://docs.travis-ci.com/user/pull-requests/#pull-requests-and-security-restrictions
$ export SCCACHE_BUCKET=rust-lang-ci-sccache2
$ export SCCACHE_REGION=us-west-1
$ export GCP_CACHE_BUCKET=rust-lang-ci-cache
$ export AWS_ACCESS_KEY_ID=AKIA46X5W6CZEJZ6XT55
---
travis_time:start:test_assembly
Check compiletest suite=assembly mode=assembly (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu)
[01:19:43] 
[01:19:43] running 9 tests
[01:19:43] iiiiiiiii
[01:19:43] 
[01:19:43]  finished in 0.148
[01:19:43] travis_fold:end:test_assembly

---
travis_time:start:test_debuginfo
Check compiletest suite=debuginfo mode=debuginfo-both (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu)
[01:19:58] 
[01:19:58] running 121 tests
[01:20:23] .iiiii...i.....i..i...i..i.i.i..i.ii...i.....i..i....i..........iiii..........i...ii...i.......ii.i. 100/121
[01:20:28] i.i......iii.i.....ii
[01:20:28] 
[01:20:28]  finished in 30.099
[01:20:28] travis_fold:end:test_debuginfo

---
[01:28:14]    Compiling alloc v0.0.0 (/checkout/src/liballoc)
[01:28:15] error[E0432]: unresolved import `crate::boxed::stage0_unphantom`
[01:28:15]   --> src/liballoc/alloc.rs:15:5
[01:28:15]    |
[01:28:15] 15 | use crate::boxed::stage0_unphantom;
[01:28:15]    |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ no `stage0_unphantom` in `boxed`
[01:28:15] 
[01:28:15] error[E0432]: unresolved import `crate::boxed::stage0_phantom`
[01:28:15]    |
[01:28:15]    |
[01:28:15] 27 | use crate::boxed::{Box, stage0_phantom};
[01:28:15]    |                         ^^^^^^^^^^^^^^ no `stage0_phantom` in `boxed`
[01:28:15] 
[01:28:15] error[E0432]: unresolved import `crate::boxed::stage0_phantom`
[01:28:15]     |
[01:28:15]     |
[01:28:15] 251 | use crate::boxed::stage0_phantom;
[01:28:15]     |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ no `stage0_phantom` in `boxed`
[01:28:15] error[E0432]: unresolved import `crate::boxed::stage0_unphantom`
[01:28:15]   --> src/liballoc/str.rs:43:25
[01:28:15]    |
[01:28:15]    |
[01:28:15] 43 | use crate::boxed::{Box, stage0_unphantom};
[01:28:15]    |                         ^^^^^^^^^^^^^^^^ no `stage0_unphantom` in `boxed`
[01:28:17] error[E0277]: the trait bound `std::alloc::System: std::alloc::Alloc` is not satisfied
[01:28:17]  --> src/liballoc/../liballoc/tests/heap.rs:6:5
[01:28:17]   |
[01:28:17]   |
[01:28:17] 6 |     check_overalign_requests(System)
[01:28:17]   |     ^^^^^^^^^^^^^^^^^^^^^^^^ the trait `std::alloc::Alloc` is not implemented for `std::alloc::System`
[01:28:17]   |
[01:28:17] note: required by `heap::check_overalign_requests`
[01:28:17]   |
[01:28:17]   |
[01:28:17] 14| fn check_overalign_requests<T: Alloc>(mut allocator: T) {
[01:28:17] 
[01:28:18] error[E0616]: field `1` of struct `std::boxed::Box` is private
[01:28:18]    --> src/liballoc/str.rs:586:24
[01:28:18]     |
[01:28:18]     |
[01:28:18] 586 |     let a = ptr::read(&v.1);
[01:28:18] 
[01:28:18] error: aborting due to 5 previous errors
[01:28:18] 
[01:28:18] Some errors have detailed explanations: E0432, E0616.
---
[01:28:21] 
[01:28:21] To learn more, run the command again with --verbose.
[01:28:21] 
[01:28:21] 
[01:28:21] command did not execute successfully: "/checkout/obj/build/x86_64-unknown-linux-gnu/stage0/bin/cargo" "test" "--target" "x86_64-unknown-linux-gnu" "-j" "4" "--release" "--locked" "--color" "always" "--features" "panic-unwind backtrace" "--manifest-path" "/checkout/src/libstd/Cargo.toml" "-p" "alloc" "--" "--quiet"
[01:28:21] 
[01:28:21] 
[01:28:21] failed to run: /checkout/obj/build/bootstrap/debug/bootstrap test
[01:28:21] Build completed unsuccessfully in 0:20:18
[01:28:21] Build completed unsuccessfully in 0:20:18
[01:28:21] make: *** [check] Error 1
[01:28:21] Makefile:48: recipe for target 'check' failed
The command "stamp sh -x -c "$RUN_SCRIPT"" exited with 2.
travis_time:start:030f40c0
$ date && (curl -fs --head https://google.com | grep ^Date: | sed 's/Date: //g' || true)
Fri May  3 15:46:19 UTC 2019

I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact @TimNN. (Feature Requests)

@rust-highfive

This comment has been minimized.

Copy link
Collaborator

commented May 3, 2019

The job x86_64-gnu-llvm-6.0 of your PR failed on Travis (raw log). Through arcane magic we have determined that the following fragments from the build log may contain information about the problem.

Click to expand the log.
travis_time:end:0c23c966:start=1556923096162306809,finish=1556923181881906267,duration=85719599458
$ git checkout -qf FETCH_HEAD
travis_fold:end:git.checkout

Encrypted environment variables have been removed for security reasons.
See https://docs.travis-ci.com/user/pull-requests/#pull-requests-and-security-restrictions
$ export SCCACHE_BUCKET=rust-lang-ci-sccache2
$ export SCCACHE_REGION=us-west-1
$ export GCP_CACHE_BUCKET=rust-lang-ci-cache
$ export AWS_ACCESS_KEY_ID=AKIA46X5W6CZEJZ6XT55
---

[00:04:05] travis_fold:start:tidy
travis_time:start:tidy
tidy check
[00:04:05] tidy error: /checkout/src/liballoc/boxed.rs:90: line longer than 100 chars
[00:04:05] tidy error: /checkout/src/liballoc/boxed.rs:860: TODO is deprecated; use FIXME
[00:04:05] tidy error: /checkout/src/liballoc/boxed.rs:874: TODO is deprecated; use FIXME
[00:04:10] some tidy checks failed
[00:04:10] 
[00:04:10] 
[00:04:10] command did not execute successfully: "/checkout/obj/build/x86_64-unknown-linux-gnu/stage0-tools-bin/tidy" "/checkout/src" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage0/bin/cargo" "--no-vendor" "--quiet"
[00:04:10] 
[00:04:10] 
[00:04:10] failed to run: /checkout/obj/build/bootstrap/debug/bootstrap test src/tools/tidy
[00:04:10] Build completed unsuccessfully in 0:01:06
[00:04:10] Build completed unsuccessfully in 0:01:06
[00:04:10] make: *** [tidy] Error 1
[00:04:10] Makefile:67: recipe for target 'tidy' failed
The command "stamp sh -x -c "$RUN_SCRIPT"" exited with 2.
travis_time:start:0ac8a3a8
$ date && (curl -fs --head https://google.com | grep ^Date: | sed 's/Date: //g' || true)
Fri May  3 22:44:01 UTC 2019
---
travis_time:end:028a5bb8:start=1556923442466968403,finish=1556923442471855157,duration=4886754
travis_fold:end:after_failure.3
travis_fold:start:after_failure.4
travis_time:start:174bdf48
$ ln -s . checkout && for CORE in obj/cores/core.*; do EXE=$(echo $CORE | sed 's|obj/cores/core\.[0-9]*\.!checkout!\(.*\)|\1|;y|!|/|'); if [ -f "$EXE" ]; then printf travis_fold":start:crashlog\n\033[31;1m%s\033[0m\n" "$CORE"; gdb --batch -q -c "$CORE" "$EXE" -iex 'set auto-load off' -iex 'dir src/' -iex 'set sysroot .' -ex bt -ex q; echo travis_fold":"end:crashlog; fi; done || true
travis_fold:end:after_failure.4
travis_fold:start:after_failure.5
travis_time:start:10343d84
travis_time:start:10343d84
$ cat ./obj/build/x86_64-unknown-linux-gnu/native/asan/build/lib/asan/clang_rt.asan-dynamic-i386.vers || true
cat: ./obj/build/x86_64-unknown-linux-gnu/native/asan/build/lib/asan/clang_rt.asan-dynamic-i386.vers: No such file or directory
travis_fold:end:after_failure.5
travis_fold:start:after_failure.6
travis_time:start:0247d9fb
$ dmesg | grep -i kill

I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact @TimNN. (Feature Requests)

@bors

This comment has been minimized.

Copy link
Contributor

commented May 21, 2019

☔️ The latest upstream changes (presumably #60986) made this pull request unmergeable. Please resolve the merge conflicts.

@Ericson2314

This comment has been minimized.

Copy link
Contributor

commented Jun 10, 2019

When is the next rust release? It would be cool if we waited long enough for the #[cfg(stage0)] to go away again.

@mati865

This comment has been minimized.

Copy link
Contributor

commented Jun 10, 2019

@Ericson2314

This comment has been minimized.

Copy link
Contributor

commented Jun 11, 2019

Oh right, beta.

[@mati865 I couldn't help myself but https://xkcd.com/1179/, my broken American brain can pull itself together for the ISO standard, but flails around confronted with anything else consistent as it may be.]

glandium added some commits May 3, 2019

Associate an allocator to boxes
This turns `Box<T>` into `Box<T, A = Global>`, with a `A: Alloc` bound
for impls.

Ideally, inherent methods like `Box::new` would be applied to
`Box<T, A: Alloc + Default>`, but as of now, that would be backwards
incompatible because it would require type annotations in places where
they currently aren't required.

`impl FromIterator` is not covered because it relies on `Vec`, which
would need allocator awareness.

`DispatchFromDyn` is left out or being generic over `A` because there
is no bound that would make it work currently. `FnBox` is left out
because it's related to `DispatchFromDyn`.
@glandium

This comment has been minimized.

Copy link
Contributor Author

commented Jun 11, 2019

beta already has what it takes to build without #[cfg(stage0)].

@Ericson2314

This comment has been minimized.

Copy link
Contributor

commented Jun 11, 2019

@glandium I'd thought for bootstrapping purposes we'd need to wait another cycle for it to hit stable. But, glad to be wrong in any event!

@JohnCSimon

This comment has been minimized.

Copy link

commented Jul 20, 2019

Pinging @glandium from triage - this PR has sat idle for more than a month.

@JohnCSimon

This comment has been minimized.

Copy link

commented Jul 27, 2019

Pinging @glandium from triage - giving this one more week before closing for inactivity

@JohnTitor

This comment has been minimized.

Copy link
Member

commented Aug 4, 2019

Landing this should be blocked on resolving rust-lang/wg-allocators#2 one way or another, in my opinion.

Ping from triage: @glandium @SimonSapin, is this still blocked by the above comment? If so, this may be labeled as S-blocked.

@SimonSapin SimonSapin added the S-blocked label Aug 4, 2019

@SimonSapin

This comment has been minimized.

Copy link
Contributor

commented Aug 4, 2019

Yes it is. Added the label.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
You can’t perform that action at this time.