Giter Club home page Giter Club logo

compiletest-rs's Introduction

compiletest-rs

This project is an attempt at extracting the compiletest utility from the Rust compiler.

The compiletest utility is useful for library and plugin developers, who want to include test programs that should fail to compile, issue warnings or otherwise produce compile-time output.

To use in your project

To use compiletest-rs in your application, add the following to Cargo.toml

[dev-dependencies]
compiletest_rs = "0.10.0"

By default, compiletest-rs should be able to run on both stable, beta and nightly channels of rust. We use the tester fork of Rust's builtin test crate, so that we don't have require nightly. If you are running nightly and want to use Rust's test crate directly, you need to have the rustc development libraries install (which you can get by running rustup component add rustc-dev --toolchain nightly). Once you have the rustc development libraries installed, you can use the rustc feature to make compiletest use them instead of the tester crate.

[dev-dependencies]
compiletest_rs = { version = "0.10.0", features = [ "rustc" ] }

Create a tests folder in the root folder of your project. Create a test file with something like the following:

extern crate compiletest_rs as compiletest;

use std::path::PathBuf;

fn run_mode(mode: &'static str) {
    let mut config = compiletest::Config::default();

    config.mode = mode.parse().expect("Invalid mode");
    config.src_base = PathBuf::from(format!("tests/{}", mode));
    config.link_deps(); // Populate config.target_rustcflags with dependencies on the path
    config.clean_rmeta(); // If your tests import the parent crate, this helps with E0464

    compiletest::run_tests(&config);
}

#[test]
fn compile_test() {
    run_mode("compile-fail");
    run_mode("run-pass");
}

Each mode corresponds to a folder with the same name in the tests folder. That is for the compile-fail mode the test runner looks for the tests/compile-fail folder.

Adding flags to the Rust compiler is a matter of assigning the correct field in the config. The most common flag to populate is the target_rustcflags to include the link dependencies on the path.

// NOTE! This is the manual way of adding flags
config.target_rustcflags = Some("-L target/debug".to_string());

This is useful (and necessary) for library development. Note that other secondary library dependencies may have their build artifacts placed in different (non-obvious) locations and these locations must also be added.

For convenience, Config provides a link_deps() method that populates target_rustcflags with all the dependencies found in the PATH variable (which is OS specific). For most cases, it should be sufficient to do:

let mut config = compiletest::Config::default();
config.link_deps();

Note that link_deps() panics if any of the added paths contain spaces, as these are currently not handled correctly.

Example

See the test-project folder for a complete working example using the compiletest-rs utility. Simply cd test-project and cargo test to see the tests run. The annotation syntax is documented in the rustc-guide.

TODO

  • The run-pass mode is strictly not necessary since it's baked right into Cargo, but I haven't bothered to take it out

Contributing

Thank you for your interest in improving this utility! Please consider submitting your patch to the upstream source instead, as it will be incorporated into this repo in due time. Still, there are some supporting files that are specific to this repo, for example:

  • src/lib.rs
  • src/uidiff.rs
  • test-project/

If you are unsure, open a pull request anyway and we would be glad to help!

compiletest-rs's People

Contributors

alessandrod avatar denzp avatar dependabot[bot] avatar dtolnay avatar dwrensha avatar eddyb avatar eijebong avatar erickt avatar fpoli avatar hdhoang avatar kflansburg avatar llogiq avatar manishearth avatar mati865 avatar mcarton avatar messense avatar munksgaard avatar nabijaczleweli avatar oli-obk avatar phansch avatar ralfjung avatar ryman avatar sergiobenitez avatar simonsapin avatar smoelius avatar taiki-e avatar tamird avatar thomcc avatar vadorovsky avatar zhaixiaojuan avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar

compiletest-rs's Issues

"unexpected "error": '8:1: 8:33: multiple matching crates for `deny_public_fields` [E0464]'" after Cargo update

Servo’s CI failed after updating Cargo: servo/servo#16601 (comment)

CC @nox

I suspect that the issue is using -L path/to/directory whereas Cargo uses --extern name=path/to/file.rlib. I tried to reproduce outside of Servo but failed.

Attempted steps:

  • rustup update nightly
  • rustup update nightly-2017-04-21
  • Use this branch master...SimonSapin:dep
  • cd test-project
  • cargo +nightly test
  • cargo +nightly-2017-04-21 test

Multiple matching crates error, if dependency on compiletest is optional

I'm trying to use compiletest for a #[no_std] crate. Because the crate contains examples that need to be built for an embedded platform where std is not available (thumbv6m-none-eabi), I needed to make the dependency on compiletest optional and add a Cargo feature for it.

Further details:

This works works fine:

$ cargo clean
$ cargo test --features compiletest

This does not work:

$ cargo test
$ cargo test --features compiletest

It results in the following error (excerpt from full build log):

status: exit code: 101
command: "rustc" "tests/compile-fail/swm/assign-function-to-pin-with-unknown-state.rs" "-L" "/tmp" "--target=x86_64-unknown-linux-gnu" "--error-format" "json" "-C" "prefer-dynamic" "-o" "/tmp/swm/assign-function-to-pin-with-unknown-state.stage-id" "-L" "/home/travis/build/braun-robotics/rust-lpc82x-hal/target/debug/build/cortex-m-rt-e3337e5285e3af86/out" "-L" "/home/travis/build/braun-robotics/rust-lpc82x-hal/target/debug" "-L" "/home/travis/build/braun-robotics/rust-lpc82x-hal/target/debug/deps" "-L" "/home/travis/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib" "-L" "/home/travis/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib" "-L" "/tmp/swm/assign-function-to-pin-with-unknown-state.stage-id.aux" "-A" "unused"
unexpected errors (from JSON output): [
    Error {
        line_num: 1,
        kind: Some(
            Error
        ),
        msg: "1:1: 1:25: multiple matching crates for `lpc82x_hal` [E0464]"
    },
    Error {
        line_num: 1,
        kind: Some(
            Error
        ),
        msg: "1:1: 1:25: found crate `lpc82x_hal` compiled by an incompatible version of rustc [E0514]"
    }
]

I believe the important part is multiple matching crates. I think I understand what happens here: We have two versions of the crate, one with the feature, one without, and rustc doesn't know which one to use. Is this something that could be fixed in clean_rmeta?

Support running tests in parallel

It would be great if compiletest was able to run mutliple tests in parallel - e.g. when there are 80 run-pass tests, it should run several of them in parallel to speed up testing.

From what I am told, rustc does something like that already. So maybe all it takes is updating compiletest from rustc?

Support RUST_NEW_ERROR_FORMAT=true

Currently it fails to pick up correct error messages:

---- [compile-fail] compile-fail/str_ref_deser.rs stdout ----

error: expected error: on line 6 not found: Serde does not support deserializing fields of type &str

error: 0 unexpected errors found, 1 expected errors not found
status: exit code: 101
command: rustc tests/compile-fail/str_ref_deser.rs -L /tmp --target=x86_64-unknown-linux-gnu -L /tmp/str_ref_deser.stage3.compile-fail.libaux -C prefer-dynamic -o /tmp/str_ref_deser.stage3 -L target/debug/ -L target/debug/deps/
stdout:
------------------------------------------

------------------------------------------
stderr:
------------------------------------------
error: Serde does not support deserializing fields of type &str; consider using String instead
 --> tests/compile-fail/str_ref_deser.rs:6:5
  |>
6 |>     s: &'a str, //~ ERROR: Serde does not support deserializing fields of type &str
  |>     ^^^^^^^^^^

error: aborting due to previous error

------------------------------------------

This is from serde_macros. The same tests pass without RUST_NEW_ERROR_FORMAT.

Support for `cargo rustc` to build tests?

Is it feasible to support the new cargo rustc command as an alternative to rustc for running compile tests? It would mean significantly less pain specifying paths to dependencies. I tried to make it work with the existing options in compiletest::common::Config but to no avail, unfortunately.

(If you intend to keep the source of this crate as close to the upstream source in rust-lang/rust as possible, then this probably isn't an option, but I thought I'd ask anyway!)

nixcrates fails to compile

I got the following request from @sjmackenzie:

Hello,

If you could be so kind to follow rust convention and rename the
default lib entry point to lib.rs for this file
https://github.com/laumann/compiletest-rs/blob/master/Cargo.toml#L16

this library does not compile when using
github.com/fractalide/nixcrates which looks for the default lib.rs but
cannot find it.

kr/sjm

Should we let convention prevail here and just rename? Do we have any reason for keeping the lib entry point as compiletest.rs?

Multi-span messages are not matched

When multi-span messages are emitted, the compiler duplicates the message in the JSON output for each span. Compiletest recognizes the first message, and reports mismatch for the rest.

Broken on windows msvc

This line sets the build_base to /tmp, which makes zero sense on windows. Maybe the default could be target/debug or a subdirectory of that?

Broken on latest nightly

Compiletest does not build on today's nightly:

   Compiling compiletest_rs v0.2.4
error[E0063]: missing fields `filter_exact`, `list` in initializer of `test::TestOpts`
   --> /Users/sbenitez/.cargo/registry/src/github.com-1ecc6299db9ec823/compiletest_rs-0.2.4/src/compiletest.rs:129:5
    |
129 |     test::TestOpts {
    |     ^^^^^^^^^^^^^^ missing `filter_exact`, `list`

error: aborting due to previous error

error: Could not compile `compiletest_rs`.

Default value of build_base leads to races when running tests concurrently

In miri, we use compiletest in multiple #[test] functions, so they are executed in parallel. We see a lot of test failures like

error: compilation failed!

status: exit code: 101

command: target/release/miri tests/run-pass/aux_test.rs -L /tmp --target=x86_64-unknown-linux-gnu -Z dump-mir=all -Z mir-opt-level=3 -Z dump-mir-dir=/tmp/aux_test -L /tmp/aux_test.stage-id.mir-opt.libaux -C prefer-dynamic -o /tmp/aux_test.stage-id -Zmir-opt-level=0 -Zmir-emit-validate=1

stdout:

------------------------------------------

------------------------------------------

stderr:

------------------------------------------

error: linking with `cc` failed: exit code: 1

  |

  = note: "cc" "-Wl,--as-needed" "-Wl,-z,noexecstack" "-m64" "-L" "/home/travis/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib" "/tmp/aux_test.0.o" "-o" "/tmp/aux_test.stage-id" "/tmp/aux_test.crate.allocator.o" "-Wl,--gc-sections" "-pie" "-Wl,-z,relro,-z,now" "-nodefaultlibs" "-L" "/tmp" "-L" "/tmp/aux_test.stage-id.mir-opt.libaux" "-L" "/home/travis/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib" "-L" "/tmp/aux_test.stage-id.mir-opt.libaux" "-l" "dep" "-L" "/home/travis/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib" "-l" "std-ab8512bb715ab82f" "-Wl,-Bstatic" "/home/travis/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libcompiler_builtins-53095306c4bf2e4a.rlib" "-Wl,-Bdynamic" "-l" "dl" "-l" "rt" "-l" "pthread" "-l" "pthread" "-l" "gcc_s" "-l" "c" "-l" "m" "-l" "rt" "-l" "pthread" "-l" "util"

  = note: /usr/bin/ld: cannot find /tmp/aux_test.0.o: No such file or directory

          /usr/bin/ld: cannot find /tmp/aux_test.crate.allocator.o: No such file or directory

          collect2: ld returned 1 exit status

From the behavior of the bug (it only occurs spuriously), this feels a lot like a race condition.
(It also shows that compiletest messes with /tmp really badly, rather than creating its own subdirectory, which I would have expected.)

We track this in miri as rust-lang/miri#305

Request - Publish crate to crates.io

I have pinged #cargo as a quick check, and there's no issue with publishing this crate.

Use case: I have a plugin that uses this crate to ensure it works, but can't publish with those tests active (becuase cargo requires all dependencies to be on crates.io before you can publish)

Turn aux_base into an optional path

The aux_base parameter is currently not optional, but set to a "bogus" value (a path in my system). It's harmless when not in use, but is rather poor style. It should ideally be an Option

Have AppVeyor build run tests in test-project

The AppVeyor build only builds the library on nightly and stable, it doesn't run the tests in the test-project folder.

Add appropriate steps to the build script to do:

$ cd test-project
$ cargo test

Default config's `target` could be better

Currently the default target is set to 'x86_64-unknown-linux-gnu', it would be great if this library would handle setting up the target so downstream libs don't have to do their own conditional compilation.

Fails to build on 1.25.0-nightly (7d6e5b9da 2018-01-27)

error[E0560]: struct `test::TestOpts` has no field named `quiet`
  --> src/lib.rs:97:9
   |
97 |         quiet: config.quiet,
   |         ^^^^^^ `test::TestOpts` does not have this field
   |
   = note: available fields are: `list`, `filter`, `filter_exact`, `run_ignored`, `run_tests` ... and 8 others

warning: use of deprecated item 'std::slice::<impl [T]>::rotate': renamed to `rotate_left`
    --> src/runtest.rs:2614:30
     |
2614 |                         tail.rotate(data.len());
     |                              ^^^^^^
     |
     = note: #[warn(deprecated)] on by default

Align with rustc/compiletest

The current codebase is quite out-of-sync with the version in rustc.

Align the two implementations again. Keep in mind:

  • The stable feature is an add-on that might cause issues
  • The tmp feature

Most of the code that deviates from/adds to rustc's compiletest is found in common.rs, but some of it has snuck into runtest.rs (and maybe other places).

"every suggestion should have at least one span"

On the most recent nightly, 1.23.0-nightly (63739ab7b 2017-11-21), my compile-fail tests started failing with this error. The issue is reproduced as well in the test-project test cases in this repo. Is there a fix we need to grab from upstream?

test [compile-fail] compile-fail/asm-gated.rs ... FAILED
test [compile-fail] compile-fail/mut-suggestion.rs ... FAILED
test [compile-fail] compile-fail/multiple-errors.rs ... FAILED
test [compile-fail] compile-fail/trait-bounds-cant-coerce.rs ... FAILED
test [compile-fail] compile-fail/vector-cast-weirdness.rs ... FAILED
test [compile-fail] compile-fail/where-for-self.rs ... FAILED

failures:

---- [compile-fail] compile-fail/asm-gated.rs stdout ----
	thread '[compile-fail] compile-fail/asm-gated.rs' panicked at 'every suggestion should have at least one span', /checkout/src/libcore/option.rs:874:4
note: Run with `RUST_BACKTRACE=1` for a backtrace.

---- [compile-fail] compile-fail/mut-suggestion.rs stdout ----
	thread '[compile-fail] compile-fail/mut-suggestion.rs' panicked at 'every suggestion should have at least one span', /checkout/src/libcore/option.rs:874:4

---- [compile-fail] compile-fail/multiple-errors.rs stdout ----
	thread '[compile-fail] compile-fail/multiple-errors.rs' panicked at 'every suggestion should have at least one span', /checkout/src/libcore/option.rs:874:4

---- [compile-fail] compile-fail/trait-bounds-cant-coerce.rs stdout ----
	thread '[compile-fail] compile-fail/trait-bounds-cant-coerce.rs' panicked at 'every suggestion should have at least one span', /checkout/src/libcore/option.rs:874:4

---- [compile-fail] compile-fail/vector-cast-weirdness.rs stdout ----
	thread '[compile-fail] compile-fail/vector-cast-weirdness.rs' panicked at 'every suggestion should have at least one span', /checkout/src/libcore/option.rs:874:4

---- [compile-fail] compile-fail/where-for-self.rs stdout ----
	thread '[compile-fail] compile-fail/where-for-self.rs' panicked at 'every suggestion should have at least one span', /checkout/src/libcore/option.rs:874:4

Errors happening inside macro expansions

Let's say I have a complex macro in a library which I want to test, and it fails within macro expansion (i.e., the macro expands fine, but there's a compile error which points inside macro). I get errors like this:

stderr:
------------------------------------------
<pod_typeinfo macros>:6:48: 6:52 error: the trait `Copy` may not be implemented for this type; field `a` does not implement `Copy` [E0204]
<pod_typeinfo macros>:6 # [ allow ( dead_code ) ] # [ derive ( Clone , Copy ) ] $ ( # [ $ attr ] ) *
                                                                       ^~~~
<pod_typeinfo macros>:6:48: 6:52 note: in this expansion of #[derive_Copy] (defined in <pod_typeinfo macros>)
tests/compile-fail/derive-clone.rs:4:1: 8:2 note: in this expansion of def! (defined in <pod_typeinfo macros>)
<pod_typeinfo macros>:6:48: 6:52 help: run `rustc --explain E0204` to see a detailed explanation
error: aborting due to previous error

Is there any way to match these errors? Placing //~ ERROR at the invocation line doesn't seem to work as it only captures macro expansion failures...

And here's the test itself:

#[macro_use]
extern crate pod_typeinfo;

def! {
    struct Foo {
        a: String 
    }
}

fn main() {}

Test does not get compiled via `compiletest-rs`

I'm having troubles incorporating compiletest into lazy_static codebase - I have a simple setup but compiletest does not find any warnings/errors:

error: 0 unexpected errors found, 1 expected errors not found
status: exit code: 101

even though if I run the command printed out it works as expected - yields the expected error. Am I doing something wrong, or is it a problem with compiletest?

$ rustc --version
rustc 1.23.0-nightly (02004ef78 2017-11-08)

I can reproduce the same problems by simply running cargo test in the test-project directory of this crate.

Does not compile on rustc 1.19.0-nightly (f4209651e 2017-05-05)

error[E0433]: failed to resolve. Could not find `Options` in `test`
   --> src/lib.rs:146:18
    |
146 |         options: test::Options::new(),
    |                  ^^^^^^^^^^^^^^^^^^ Could not find `Options` in `test`

error[E0560]: struct `test::TestOpts` has no field named `options`
   --> src/lib.rs:146:9
    |
146 |         options: test::Options::new(),
    |         ^^^^^^^^ `test::TestOpts` does not have this field

error: aborting due to previous error

Could not compile on Windows 10

Hi! Tried to set up compiletest to fire up some learning tests for language semantics (I'm still totally n00b at Rust). Got this error both on my project and in the test project from a fresh clone of the repo.

error[E0433]: failed to resolve. Could not find `OutputFormat` in `test`
  --> D:\Projects\Rust\compiletest-rs\src\lib.rs:97:41
   |
97 |         format: if config.quiet { test::OutputFormat::Terse } else { test::OutputFormat::Pretty },
   |                                         ^^^^^^^^^^^^ Could not find `OutputFormat` in `test`

error[E0433]: failed to resolve. Could not find `OutputFormat` in `test`
  --> D:\Projects\Rust\compiletest-rs\src\lib.rs:97:76
   |
97 |         format: if config.quiet { test::OutputFormat::Terse } else { test::OutputFormat::Pretty },
   |                                                                            ^^^^^^^^^^^^ Could not find `OutputFormat` in `test`

error[E0560]: struct `test::TestOpts` has no field named `format`
  --> D:\Projects\Rust\compiletest-rs\src\lib.rs:97:9
   |
97 |         format: if config.quiet { test::OutputFormat::Terse } else { test::OutputFormat::Pretty },
   |         ^^^^^^^ `test::TestOpts` does not have this field
   |
   = note: available fields are: `list`, `filter`, `filter_exact`, `run_ignored`, `run_tests` ... and 8 others

error[E0593]: closure is expected to take a single tuple as argument, but it takes 0 arguments
   --> D:\Projects\Rust\compiletest-rs\src\lib.rs:270:21
    |
270 |       test::DynTestFn(Box::new(move || {
    |                       ^        ------- help: consider changing the closure to accept a tuple: `|()|`
    |  _____________________|
    | |
271 | |         runtest::run(config, &testpaths)
272 | |     }))
    | |______^ expected closure that takes a single tuple as argument
    |
    = note: required because of the requirements on the impl of `test::FnBox<()>` for `[closure@D:\Projects\Rust\compiletest-rs\src\lib.rs:270:30: 272:6 config:_, testpaths:_]`
    = note: required for the cast to the object type `test::FnBox<()>`

error: aborting due to 4 previous errors

error: Could not compile `compiletest_rs`.

Multiple matching crates for parent crate [E0464]

See https://travis-ci.org/Robbepop/string-interner/jobs/339735884 for the build log (config.link_deps()).
And https://travis-ci.org/Robbepop/string-interner/jobs/339733480 for an earlier one (config.target_ruscflags = Some("-L target/debug/deps").

Locally on my Windows machine, config.link_deps() fails due to #81 and config.target_rustcflags = Some("-L target/debug/deps") works fine. config.clean_rmeta is called after setting the link arguments in both cases.

Compile test harness here: https://github.com/CAD97/string-interner/blob/d95952459bb0b0a99448c9f5c84ff182b2ef7e38/tests/compiletests.rs
Singular compile-fail test here: https://github.com/CAD97/string-interner/blob/d95952459bb0b0a99448c9f5c84ff182b2ef7e38/tests/compile-fail/pooled_str_outlives.rs

0 unexpected errors

Hi!

I briefly evaluated using compiletest-rs for the rulinalg library and ran into some issues. I unfortunately don't have the time to create a completely minimal example, but the example is already quite minimal.

I also pushed the code to the compiletest branch on my fork of rulinalg. The crux of the matter is that compiletest-rs says:

error: 0 unexpected errors found, 1 expected errors not found

when rustc clearly shows that there should be an unexpected error.

Edit: This was using the nightly compiler:

nightly-x86_64-unknown-linux-gnu (default)
rustc 1.13.0-nightly (1265cbf4e 2016-09-15)

Feature request: Inline code to test

My compile-fail directory is full of code snippets that contain the same lines (with one variation to exercise multiple failures) over and over.

To reduce clutter, it would be nice if we could define a prefix + suffix and a slice of code strings and pipe prefix + code + suffix into rustc instead of requiring specific files.

Clarification/Feature request: #[bench]

Can compiletest-rs benchmark compilation? How would this work?

Use case: I think at some point it may be useful to benchmark our lints at rust-clippy to see bottlenecks.

[E0464]: multiple matching crates after using cargo check

Running cargo check creates a .rmeta file with a different hash than the actual rlib built. This makes cargo test unable to compile tests which import the tested crate for integration testing.

This travis build fails because of the duplicate files https://travis-ci.org/hdhoang/testee/jobs/285433441#L481
It runs fine after removing the rmeta file https://travis-ci.org/hdhoang/testee/builds/285434745#L443

This is possibly related to rust-lang/cargo#3501. Until check and build use the same metadata, this issue would hinder compiletest-rs adoption.

I think we can workaround this by removing the relevant rmeta files when building tests.

Unable to use "pretty" tests

Tests with Mode::Pretty aren't currently working because:

error: pretty-printing failed in round 0 revision None
status: exit code: 101
command: "rustc" "-" "-Zunstable-options" "--unpretty" "expanded" "--target" "x86_64-unknown-linux-gnu" "-L" "/tmp/target-attr.stage-id.pretty.aux" "-L" "crate=../target/debug/" "-L" "dependency=../target/debug/deps/"

stdout:
------------------------------------------
------------------------------------------

stderr:
------------------------------------------
error: Unrecognized option: 'unpretty'
------------------------------------------

It caused by changes in Rust #47440.
Instead of -Zunstable-options --unpretty TYPE we need to use -Z unpretty=TYPE.

Should it be enough just to propagate the changes here?

Fix the OS X env incompatibility

I've encountered a small problem in compile this package, due to there is no LD_LIBRARY_PATH in OS X. To fix it, just need to change line 46 of src/compiletest.rs to the following code:

#[cfg(target_os = "macos")]
static LD_LIBRARY_PATH: &'static str = env!("DYLD_LIBRARY_PATH");

#[cfg(target_os = "linux")]
static LD_LIBRARY_PATH: &'static str = env!("LD_LIBRARY_PATH");

Due to it's just a small issue so I just pasted it here and too lazy to make a PR :P

Incorrect folder name is printed for each test

In miri, we have a folder compile-fail-fullmir for compile-fail tests that need a different setup than those in compile-fail. This reveals that compiletest prints the wrong path to the file that it is testing:

## Running compile-fail tests in tests/compile-fail-fullmir against miri for target x86_64-unknown-linux-gnu

running 1 test
test [compile-fail] compile-fail/undefined_byte_read.rs ... ok

This says the file name is compile-fail/undefined_byte_read.rs while it really is compile-fail-fullmir/undefined_byte_read.rs. compiletest seems to use the suite name when printing the folder name, which is not in general correct.

I tried to fix this myself, but unfortunately I could not even find the place in the code that does this printing...

Build broken with latest Rust nightly.

Compile test does not seem to work with the latest Rust nightly.
Errors:

compiletest_rs-0.0.5/src/compiletest.rs:34:5: 34:22 error: use of unstable library feature 'thunk': use FnBox instead
compiletest_rs-0.0.5/src/compiletest.rs:34 use std::thunk::Thunk;
                                               ^~~~~~~~~~~~~~~~~
compiletest_rs-0.0.5/src/compiletest.rs:34:5: 34:22 help: add #![feature(thunk)] to the crate attributes to enable
compiletest_rs-0.0.5/src/procsrv.rs:16:5: 16:37 error: use of unstable library feature 'dynamic_lib': API has not been scrutinized and is highly likely to either disappear or change
compiletest_rs-0.0.5/src/procsrv.rs:16 use std::dynamic_lib::DynamicLibrary;
                                           ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
compiletest_rs-0.0.5/src/procsrv.rs:16:5: 16:37 help: add #![feature(dynamic_lib)] to the crate attributes to enable
compiletest_rs-0.0.5/src/procsrv.rs:21:20: 21:47 error: use of unstable library feature 'dynamic_lib': API has not been scrutinized and is highly likely to either disappear or change
compiletest_rs-0.0.5/src/procsrv.rs:21     let mut path = DynamicLibrary::search_path();
                                                          ^~~~~~~~~~~~~~~~~~~~~~~~~~~
compiletest_rs-0.0.5/src/procsrv.rs:21:20: 21:47 help: add #![feature(dynamic_lib)] to the crate attributes to enable
compiletest_rs-0.0.5/src/procsrv.rs:28:15: 28:37 error: use of unstable library feature 'dynamic_lib': API has not been scrutinized and is highly likely to either disappear or change
compiletest_rs-0.0.5/src/procsrv.rs:28     let var = DynamicLibrary::envvar();
                                                     ^~~~~~~~~~~~~~~~~~~~~~
compiletest_rs-0.0.5/src/procsrv.rs:28:15: 28:37 help: add #![feature(dynamic_lib)] to the crate attributes to enable
compiletest_rs-0.0.5/src/procsrv.rs:29:19: 29:46 error: use of unstable library feature 'dynamic_lib': API has not been scrutinized and is highly likely to either disappear or change
compiletest_rs-0.0.5/src/procsrv.rs:29     let newpath = DynamicLibrary::create_path(&path);
                                                         ^~~~~~~~~~~~~~~~~~~~~~~~~~~
compiletest_rs-0.0.5/src/procsrv.rs:29:19: 29:46 help: add #![feature(dynamic_lib)] to the crate attributes to enable
compiletest_rs-0.0.5/src/runtest.rs:1293:10: 1293:27 error: use of unstable library feature 'vec_push_all': likely to be replaced by a more optimized extend
compiletest_rs-0.0.5/src/runtest.rs:1293     args.push_all(&extras);
                                                  ^~~~~~~~~~~~~~~~~
compiletest_rs-0.0.5/src/runtest.rs:1293:10: 1293:27 help: add #![feature(vec_push_all)] to the crate attributes to enable
compiletest_rs-0.0.5/src/compiletest.rs:208:11: 208:16 error: use of unstable library feature 'thunk': use FnBox instead
compiletest_rs-0.0.5/src/compiletest.rs:208     }) as Thunk)
                                                      ^~~~~
compiletest_rs-0.0.5/src/compiletest.rs:208:11: 208:16 help: add #![feature(thunk)] to the crate attributes to enable
compiletest_rs-0.0.5/src/compiletest.rs:17:12: 17:20 error: unused or unknown feature, #[deny(unused_features)] on by default
compiletest_rs-0.0.5/src/compiletest.rs:17 #![feature(std_misc)]
                                                      ^~~~~~~~
compiletest_rs-0.0.5/src/compiletest.rs:14:12: 14:23 error: unused or unknown feature, #[deny(unused_features)] on by default
compiletest_rs-0.0.5/src/compiletest.rs:14 #![feature(collections)]
                                                      ^~~~~~~~~~~
compiletest_rs-0.0.5/src/compiletest.rs:34:5: 34:22 error: use of deprecated item: use FnBox instead, #[deny(deprecated)] on by default
compiletest_rs-0.0.5/src/compiletest.rs:34 use std::thunk::Thunk;
                                               ^~~~~~~~~~~~~~~~~
compiletest_rs-0.0.5/src/compiletest.rs:208:11: 208:16 error: use of deprecated item: use FnBox instead, #[deny(deprecated)] on by default
compiletest_rs-0.0.5/src/compiletest.rs:208     }) as Thunk)

No way to add multiple directories to library search path

Currently, there is only a single -L parameter given to rustc and it comes from the config.build_base variable. It would be nice to be able to have multiple inputs here. My specific use case is testing a procedural macro that's only defined on structs. So my compile-fail needs to be able to pull in my library and one other dependency to make use of the procedural macro.

I found that the library search path info was available to the process via the DYLD_LIBRARY_PATH, but it contains multiple paths separated by colons. I tried passing this value wrapped in a PathBuf to the config.build_base variable, but I ended up with the error

---- [compile-fail] compile-fail/enum.rs stdout ----                                                                                                                                                                                thread '[compile-fail] compile-fail/enum.rs' panicked at 'called `Result::unwrap()` on an `Err` value: JoinPathsError { inner: JoinPathsError }', src/libcore/result.rs:860
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
stack backtrace:
   0: std::sys::imp::backtrace::tracing::imp::unwind_backtrace
   1: std::panicking::default_hook::{{closure}}
   2: std::panicking::default_hook
   3: std::panicking::rust_panic_with_hook
   4: std::panicking::begin_panic
   5: std::panicking::begin_panic_fmt
   6: rust_begin_unwind
   7: core::panicking::panic_fmt
   8: core::result::unwrap_failed
   9: <core::result::Result<T, E>>::unwrap
  10: compiletest_rs::procsrv::add_target_env
  11: compiletest_rs::procsrv::run
  12: compiletest_rs::runtest::TestCx::program_output
  13: compiletest_rs::runtest::TestCx::compose_and_run
  14: compiletest_rs::runtest::TestCx::compose_and_run_compiler
  15: compiletest_rs::runtest::TestCx::compile_test
  16: compiletest_rs::runtest::TestCx::run_cfail_test
  17: compiletest_rs::runtest::TestCx::run_revision
  18: compiletest_rs::runtest::run
  19: compiletest_rs::make_test_closure::{{closure}}
  20: <F as test::FnBox<T>>::call_box
  21: <F as test::FnBox<T>>::call_box
  22: __rust_maybe_catch_panic

So my hacky solution currently is to find the particular library search path that ends with /deps and then set config.build_base to that one.

let dyld_paths = env::var("DYLD_LIBRARY_PATH").unwrap();
for path in dyld_paths.split(":").map(PathBuf::from) {
    if path.ends_with("deps") {
        config.build_base = path;
    }
}

Test that the error position is good

Hello.
Is it possible to test that a specific error is at the specified position.
For instance, I would like to be able to write something like:

// error-pattern: 14:13: 14:20 error: use of unsupported type name `&'a str` [E0412]

instead of:

// error-pattern: error: use of unsupported type name `&'a str` [E0412]

But it does not work.
Is there a way to do this?

If not, it would be very useful to test compiler plugins or lints that span a lot of errors to ensure that the errors are at the expected position.

Thanks.

How to handle conditional compilation?

I'm currently writing a compile-fail test, with the following code in it :

#[cfg(target_pointer_width = "64")]
    fn check_64() {
        let is : isize = -42;
        let us : usize = 42;
        is as f32; //~ERROR converting from isize to f32, which causes a loss of precision (isize is 64 bits wide, but f32's mantissa is only 23 bits wide)
        us as u32; //~ERROR casting usize to u32 may cause truncation of the value
        us as u64; // Should not trigger any lint
    }
#[cfg(target_pointer_width = "32")]
    fn check_32() {
        let is : isize = -42;
        let us : usize = 42;
        is as f32; //~ERROR converting from isize to f32, which causes a loss of precision (isize is 32 bits wide, but f32's mantissa is only 23 bits wide)
        us as u32; // Should not trigger any lint
        us as u64; // Should not trigger any lint
    }

This is part of the test case for a lint I'm writing for rust-clippy. Maybe this is misuse on my part (though I tried to make sure it isn't), but on my 64bit machine which only builds the check_64 function, the compile-fail test fails because no error is generated in the body of check_32, which is normal since it is not compiled. Here is the exact message :

---- [compile-fail] compile-fail/cast.rs stdout ----
error: expected error on line 52 not found: converting from isize to f32, which causes a loss of precision (isize is 32 bits wide, but f32's mantissa is only 23 bits wide)
status: exit code: 101
command: rustc tests/compile-fail/cast.rs -L /tmp --target=x86_64-unknown-linux-gnu -L /tmp/cast.stage3libaux -C prefer-dynamic -o /tmp/cast.stage3 -L target/debug/

Is there any way to overcome this?

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.