Is anyone else getting issues with the following tests failing on their local machines:
They pass on Travis so I've just been ignoring them locally.
I get problems in and around that area from time to time...
not sure if I'm seeing those specific errors
but it's the kind of test names I tend to ignore :P
Yes, but with
--keep-stage 0, not
i get those errors all the time
I cannot remember if its only with
--incremental or not
its very frustrating
I am using incremental in this case.
I have wondered if it is related to #53929
and I have also filed #53761
I am also using
codegen-units=N for N != 1 in my Cargo.toml
@davidtwco are you doing that as well? Or do you leave that at the default setting?
I'm not on OS X so if your issue is specific to OS X then it's probably something else. Just the default
(I am just throwing in potential reasons why you or I may be seeing local issues that Travis does not observe. Though now that I say that, I hope that my codegen-units setting does not affect what we do on the test suite itself.....)
This is the full error that I get for one of the test cases: https://gist.github.com/davidtwco/76255039178e6a347706b47f5c4a9a7d
Felix's one looks like #52528 (in particular, varkor's comment)
on Linux, on my migrate run-pass to ui branch, I am seeing the same cases fail as @davidtwco
(I'm double-checking now whether taking out
--incremental fixes it; I think it has in the past, but I'm not 100% certain)
(and yes, it looks like removing
--incremental fixes the problem for me on Linux)
Is there an issue out there for this specific problem?
If there's an existing issue, I don't think its been diagnosed properly. The closest might be #52528
but even there that's just because @varkor noted a connection
I'm seeing these test failures too with --incremental.
Does setting --incremental in
x.py make tests be build incrementally too? That wouldn't make sense.
Oh, the problem is (probably) that libstd was built incrementally ...
@mw and that somehow affected the codegen of the tests...?
or oh you mean the codegen of the libstd itself was broken in some way that the tests may be exposing...?
yes, I think so
I just tried with codegen-units=1000. that doesn't fail
but incr. comp. does a slightly different partitioning, splitting generic and non-generic code into different obj files
that might be part of the problem
[ui] ui/coherence/coherence-inherited-assoc-ty-cycle-err.rs [ui] ui/consts/const-size_of-cycle.rs [ui] ui/cycle-projection-based-on-where-clause.rs [ui] ui/cycle-trait/cycle-trait-default-type-trait.rs [ui] ui/cycle-trait/cycle-trait-supertrait-direct.rs [ui] ui/cycle-trait/cycle-trait-supertrait-indirect.rs [ui] ui/existential_types/no_inferrable_concrete_type.rs [ui] ui/impl-trait/auto-trait-leak.rs [ui] ui/infinite/infinite-tag-type-recursion.rs [ui] ui/infinite/infinite-vec-type-recursion.rs [ui] ui/issues/issue-12511.rs [ui] ui/issues/issue-17252.rs [ui] ui/issues/issue-20772.rs [ui] ui/issues/issue-21177.rs [ui] ui/issues/issue-22673.rs [ui] ui/issues/issue-23302-1.rs [ui] ui/issues/issue-23302-2.rs [ui] ui/issues/issue-23302-3.rs [ui] ui/issues/issue-26548.rs [ui] ui/issues/issue-3008-1.rs [ui] ui/issues/issue-3008-2.rs [ui] ui/issues/issue-32326.rs [ui] ui/issues/issue-34373.rs [ui] ui/issues/issue-36163.rs [ui] ui/issues/issue-44415.rs [ui] ui/no_owned_box_lang_item.rs [ui] ui/recursion/recursive-enum.rs [ui] ui/resolve/resolve-self-in-impl.rs [ui] ui/run-pass/panic-runtime/abort-link-to-unwinding-crates.rs [ui] ui/run-pass/panic-runtime/abort.rs [ui] ui/run-pass/panic-runtime/link-to-abort.rs [ui] ui/run-pass/thinlto/all-crates.rs [ui] ui/run-pass/thinlto/thin-lto-inlines2.rs [ui] ui/union/union-nonrepresentable.rs
are the tests that fialed for me today
Interesting, I just rebased an hour ago and ran the full ui suite and had no strange failures.
Is my config diff from what is default
--- config.toml.example 2018-10-27 13:47:09.761548565 +0300 +++ config.toml 2018-10-13 15:36:24.818581061 +0300 @@ -16,10 +16,10 @@ # Indicates whether rustc will support compilation with LLVM # note: rustc does not compile without LLVM at the moment -#enabled = true +enabled = true # Indicates whether the LLVM build is a Release or Debug build -#optimize = true +optimize = true # Indicates whether LLVM should be built with ThinLTO. Note that this will # only succeed if you use clang, lld, llvm-ar, and llvm-ranlib in your C/C++ @@ -28,10 +28,10 @@ #thin-lto = false # Indicates whether an LLVM Release build should include debug info -#release-debuginfo = false +release-debuginfo = false # Indicates whether the LLVM assertions are enabled or not -#assertions = false +assertions = true # Indicates whether ccache is used when building LLVM #ccache = false @@ -50,7 +50,7 @@ # Tell the LLVM build system to use Ninja instead of the platform default for # the generated build system. This can sometimes be faster than make, for # example. -#ninja = false +ninja = true # LLVM targets to build support for. # Note: this is NOT related to Rust compilation targets. However, as Rust is @@ -61,14 +61,14 @@ # support. You'll need to write a target specification at least, and most # likely, teach rustc about the C ABI of the target. Get in touch with the # Rust team and file an issue if you need assistance in porting! -#targets = "X86;ARM;AArch64;Mips;PowerPC;SystemZ;JSBackend;MSP430;Sparc;NVPTX;Hexagon" +targets = "X86;ARM;AArch64" # LLVM experimental targets to build support for. These targets are specified in # the same format as above, but since these targets are experimental, they are # not built by default and the experimental Rust compilation targets that depend # on them will not work unless the user opts in to building them. By default the # `WebAssembly` and `RISCV` targets are enabled when compiling LLVM from scratch. -#experimental-targets = "WebAssembly;RISCV" +experimental-targets = "" # Cap the number of parallel linker invocations when compiling LLVM. # This can be useful when building LLVM with debug info, which significantly @@ -76,7 +76,7 @@ # each linker process. # If absent or 0, linker invocations are treated like any other job and # controlled by rustbuild's -j parameter. -#link-jobs = 0 +link-jobs = 1 # When invoking `llvm-config` this configures whether the `--shared` argument is # passed to prefer linking to shared libraries. @@ -130,7 +130,7 @@ #compiler-docs = false # Indicate whether submodules are managed and updated automatically. -#submodules = true +submodules = false # Update submodules only when the checked out commit in the submodules differs # from what is committed in the main rustc repo. @@ -161,13 +161,13 @@ # would rather to perform a full bootstrap, compiling the compiler three times, # then you can set this option to true. You shouldn't ever need to set this # option to true. -#full-bootstrap = false +full-bootstrap = false # Enable a build of the extended rust tool set which is not only the compiler # but also tools such as Cargo. This will also produce "combined installers" # which are used to install Rust and Cargo together. This is disabled by # default. -#extended = false +extended = false # Installs chosen set of extended tools if enables. By default builds all. # If chosen tool failed to build the installation fails. @@ -177,14 +177,15 @@ #verbose = 0 # Build the sanitizer runtimes -#sanitizers = false +sanitizers = false # Build the profiler runtime #profiler = false -# Indicates whether the native libraries linked into Cargo will be statically -# linked or not. -#cargo-native-static = false +# Indicates whether the OpenSSL linked into Cargo will be statically linked or +# not. If static linkage is specified then the build system will download a +# known-good version of OpenSSL, compile it, and link it to Cargo. +#openssl-static = false # Run the build with low priority, by setting the process group's "nice" value # to +10 on Unix platforms, and by using a "low priority" job object on Windows. @@ -197,11 +198,11 @@ # Indicates that a local rebuild is occurring instead of a full bootstrap, # essentially skipping stage0 as the local compiler is recompiling itself again. -#local-rebuild = false +# local-rebuild = true # Print out how long each rustbuild step took (mostly intended for CI and # tracking over time) -#print-step-timings = false +# print-step-timings = true # ============================================================================= # General install configuration options @@ -242,48 +243,27 @@ # ============================================================================= [rust] -# Whether or not to optimize the compiler and standard library. -# +# Indicates that the build should be optimized for debugging Rust. Note that +# this is typically not what you want as it takes an incredibly large amount of +# time to have a debug-mode rustc compile any code (notably libstd). If this +# value is set to `true` it will affect a number of configuration options below +# as well, if unconfigured. +#debug = false + +# Whether or not to optimize the compiler and standard library # Note: the slowness of the non optimized compiler compiling itself usually # outweighs the time gains in not doing optimizations, therefore a -# full bootstrap takes much more time with `optimize` set to false. -#optimize = true - -# Indicates that the build should be configured for debugging Rust. A -# `debug`-enabled compiler and standard library will be somewhat -# slower (due to e.g. checking of debug assertions) but should remain -# usable. -# -# Note: If this value is set to `true`, it will affect a number of -# configuration options below as well, if they have been left -# unconfigured in this file. -# -# Note: changes to the `debug` setting do *not* affect `optimize` -# above. In theory, a "maximally debuggable" environment would -# set `optimize` to `false` above to assist the introspection -# facilities of debuggers like lldb and gdb. To recreate such an -# environment, explicitly set `optimize` to `false` and `debug` -# to `true`. In practice, everyone leaves `optimize` set to -# `true`, because an unoptimized rustc with debugging -# enabled becomes *unusably slow* (e.g. rust-lang/rust#24840 -# reported a 25x slowdown) and bootstrapping the supposed -# "maximally debuggable" environment (notably libstd) takes -# hours to build. -# -#debug = false +# full bootstrap takes much more time with optimize set to false. +optimize = true # Number of codegen units to use for each compiler invocation. A value of 0 # means "the number of cores on this machine", and 1+ is passed through to the # compiler. -#codegen-units = 1 - -# Sets the number of codegen units to build the standard library with, -# regardless of what the codegen-unit setting for the rest of the compiler is. -#codegen-units-std = 1 +codegen-units = 16 # Whether or not debug assertions are enabled for the compiler and standard # library. Also enables compilation of debug! and trace! logging macros. -#debug-assertions = false +debug-assertions = true # Whether or not debuginfo is emitted #debuginfo = false @@ -310,10 +290,10 @@ #backtrace = true # Whether to always use incremental compilation when building rustc -#incremental = false +incremental = true # Build rustc with experimental parallelization -#experimental-parallel-queries = false +experimental-parallel-queries = true # The default linker that will be hard-coded into the generated compiler for # targets that don't specify linker explicitly in their target specifications. @@ -413,24 +393,24 @@ # C compiler to be used to compiler C code. Note that the # default value is platform specific, and if not specified it may also depend on # what platform is crossing to what platform. -#cc = "cc" +# cc = "clang" # C++ compiler to be used to compiler C++ code (e.g. LLVM and our LLVM shims). # This is only used for host targets. -#cxx = "c++" +# cxx = "clang++" # Archiver to be used to assemble static libraries compiled from C/C++ code. # Note: an absolute path should be used, otherwise LLVM build will break. -#ar = "ar" +# ar = "llvm-ar" # Ranlib to be used to assemble static libraries compiled from C/C++ code. # Note: an absolute path should be used, otherwise LLVM build will break. -#ranlib = "ranlib" +# ranlib = "llvm-ranlib" # Linker to be used to link Rust code. Note that the # default value is platform specific, and if not specified it may also depend on # what platform is crossing to what platform. -#linker = "cc" +# linker = "clang -fuse-ld=lld" # Path to the `llvm-config` binary of the installation of a custom LLVM to link # against. Note that if this is specified we don't compile LLVM at all for this @@ -501,7 +481,3 @@ # as the one built on Windows will contain backslashes in paths causing problems # on linux #src-tarball = true -# - -# Whether to allow failures when building tools -#missing-tools = false
My diff in a gist - definitely less changed.
Well, this time I didn’t forget to update my submodules...
[ui] ui/coherence/coherence-inherited-assoc-ty-cycle-err.rs [ui] ui/consts/const-size_of-cycle.rs [ui] ui/cycle-projection-based-on-where-clause.rs [ui] ui/cycle-trait/cycle-trait-default-type-trait.rs [ui] ui/cycle-trait/cycle-trait-supertrait-indirect.rs [ui] ui/existential_types/no_inferrable_concrete_type.rs [ui] ui/impl-trait/auto-trait-leak.rs [ui] ui/infinite/infinite-tag-type-recursion.rs [ui] ui/infinite/infinite-vec-type-recursion.rs [ui] ui/issues/issue-12511.rs [ui] ui/issues/issue-17252.rs [ui] ui/issues/issue-20772.rs [ui] ui/issues/issue-21177.rs [ui] ui/issues/issue-23302-1.rs [ui] ui/issues/issue-23302-2.rs [ui] ui/issues/issue-23302-3.rs [ui] ui/issues/issue-26548.rs [ui] ui/issues/issue-32326.rs [ui] ui/issues/issue-34373.rs [ui] ui/issues/issue-36163.rs [ui] ui/issues/issue-44415.rs [ui] ui/recursion/recursive-static-definition.rs [ui] ui/resolve/issue-23305.rs [ui] ui/resolve/resolve-self-in-impl.rs [ui] ui/span/recursive-type-field.rs [ui] ui/variance/variance-regions-unused-indirect.rs
Still quite a few failures though