Skip to content

Speed up integration tests (move building expectations) #216

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

Merged
merged 1 commit into from
Nov 6, 2016

Conversation

jeanphilippeD
Copy link
Contributor

@jeanphilippeD jeanphilippeD commented Nov 5, 2016

Speed up running 'cargo test':
-Before: 2'17s
-After: 30s

Update to use new path:
Makefile, .travis.yml, CONTRIBUTING.md, tests/tests.rs

Delete unused expectation that fail to compile:
tests/expectations/moar_bitfields.rs
tests/expectations/variadic_template_args.rs

@highfive
Copy link

highfive commented Nov 5, 2016

warning Warning warning

  • These commits modify unsafe code. Please review it carefully!

@emilio
Copy link
Contributor

emilio commented Nov 5, 2016

This looks good, but needs documentation, and being added to CI.

Speed up running 'cargo test':
-Before: 2'17s
-After: 30s

Update to use new path:
Makefile, .travis.yml, CONTRIBUTING.md, tests/tests.rs

Delete unused expectation that fail to compile:
tests/expectations/moar_bitfields.rs
tests/expectations/variadic_template_args.rs

For every 'cargo test' run, the bindgen output where built.
We already test that the bindgen output match expectations/*.rs,
so there is no need to check it build unless the expectation is updated.

Move tests/expectations/*.rs to tests/expectations/tests/*.rs and make
tests/expectations a new dev-dependency package. This allow running:
 - cargo test -p tests_expectations

In addition to the speed up, we also get a clean output for the build
and test run. In particular, a number of warnings are generated that should
probably be silenced, and eventually enforced modifying travis to build:
 - RUSTFLAGS='-D warnings' cargo test -p tests_expectations

The benefit of having it as a new package is that it avoid polluting
the 'cargo test' output that should focus on bindgen.
@jeanphilippeD jeanphilippeD force-pushed the test_move_to_subpackage branch from 497ae94 to 2866ab5 Compare November 5, 2016 14:14
@jeanphilippeD
Copy link
Contributor Author

Thank you very much for your review.

I've updated all the places I found that mentioned expectations.
$ cargo test -p tests_expectations shows up in the travis job output.

@emilio
Copy link
Contributor

emilio commented Nov 6, 2016

@bors-servo r+

Looks good, thanks!

@bors-servo
Copy link

📌 Commit 2866ab5 has been approved by emilio

@bors-servo
Copy link

⌛ Testing commit 2866ab5 with merge eaa674e...

bors-servo pushed a commit that referenced this pull request Nov 6, 2016
Speed up integration tests (move building expectations)

Speed up running 'cargo test':
-Before: 2'17s
-After: 30s

Update to use new path:
Makefile, .travis.yml, CONTRIBUTING.md, tests/tests.rs

Delete unused expectation that fail to compile:
tests/expectations/moar_bitfields.rs
tests/expectations/variadic_template_args.rs
@bors-servo
Copy link

☀️ Test successful - status-travis

@bors-servo bors-servo merged commit 2866ab5 into rust-lang:master Nov 6, 2016
@jdub
Copy link
Contributor

jdub commented Nov 6, 2016

Hmm, I'm working on #204, and having trouble running these tests on Windows. I've made sure Rust's gcc.exe and ld.exe are in my PATH ahead of msys2's mingw ones, but it can't link with gcc.

https://gist.github.com/jdub/66752599b85d73b15d12a7d7fd985959

Works fine on Linux. And this is a cool change!

@jeanphilippeD
Copy link
Contributor Author

Hello,
My understanding is rustbindgen_py before would have done:

$ rustc --test pathToGeneratedRust/class_with_typedef.rs -o tempFile
$ tempFile  # execute the tempFile

Is it different when using cargo test?
It seems for whatever reason here, the linker on windows does not discard unused functions symbols here.

Does the link error occurs as well when you do:

$ rustc --test tests/expectations/tests/class_with_typedef.rs
$ ./class_with_typedef.exe

@jdub
Copy link
Contributor

jdub commented Nov 6, 2016

Yeah, same error. Don't worry too much -- none of this was expected to work on Windows, and it's almost certainly an installation problem. Thanks.

btw, between your changes and mine, we've reduced test suite time (excluding build) on my machine from about 21s to 2s. 😆 😆 😆

D:\GitHub\rust-bindgen\libbindgen [logless-library ≡]> rustc --test .\tests\expectations\tests\class_with_typedef.rs
warning: type `C_MyInt` should have a camel case name such as `CMyint`, #[warn(non_camel_case_types)] on by default
  --> .\tests\expectations\tests\class_with_typedef.rs:17:1
   |
17 | pub type C_MyInt = ::std::os::raw::c_int;
   | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

warning: type `C_Lookup` should have a camel case name such as `CLookup`, #[warn(non_camel_case_types)] on by default
  --> .\tests\expectations\tests\class_with_typedef.rs:18:1
   |
18 | pub type C_Lookup = *const ::std::os::raw::c_char;
   | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

error: linking with `gcc` failed: exit code: 1
  |
  = note: "gcc" "-Wl,--enable-long-section-names" "-fno-use-linker-plugin" "-Wl,--nxcompat" "-nostdlib" "-m64" "C:\\Users\\jdub\\.multirust\\toolchains\\stable-x86_64-pc-windows-gnu\\lib\\rustlib\\x86_64-pc-windows-gnu\\lib\\crt2.o" "C:\\Users\\jdub\\.multirust\\toolchains\\stable-x86_64-pc-windows-gnu\\lib\\rustlib\\x86_64-pc-windows-gnu\\lib\\rsbegin.o" "-L" "C:\\Users\\jdub\\.multirust\\toolchains\\stable-x86_64-pc-windows-gnu\\lib\\rustlib\\x86_64-pc-windows-gnu\\lib" "class_with_typedef.0.o" "-o" "class_with_typedef.exe" "-Wl,--gc-sections" "-nodefaultlibs" "-L" "C:\\Users\\jdub\\.multirust\\toolchains\\stable-x86_64-pc-windows-gnu\\lib\\rustlib\\x86_64-pc-windows-gnu\\lib" "-Wl,-Bstatic" "-Wl,-Bdynamic" "C:\\Users\\jdub\\.multirust\\toolchains\\stable-x86_64-pc-windows-gnu\\lib\\rustlib\\x86_64-pc-windows-gnu\\lib\\libtest-5c6cf767.rlib" "C:\\Users\\jdub\\.multirust\\toolchains\\stable-x86_64-pc-windows-gnu\\lib\\rustlib\\x86_64-pc-windows-gnu\\lib\\libgetopts-5c6cf767.rlib" "C:\\Users\\jdub\\.multirust\\toolchains\\stable-x86_64-pc-windows-gnu\\lib\\rustlib\\x86_64-pc-windows-gnu\\lib\\libterm-5c6cf767.rlib" "C:\\Users\\jdub\\.multirust\\toolchains\\stable-x86_64-pc-windows-gnu\\lib\\rustlib\\x86_64-pc-windows-gnu\\lib\\libstd-5c6cf767.rlib" "C:\\Users\\jdub\\.multirust\\toolchains\\stable-x86_64-pc-windows-gnu\\lib\\rustlib\\x86_64-pc-windows-gnu\\lib\\libpanic_unwind-5c6cf767.rlib" "C:\\Users\\jdub\\.multirust\\toolchains\\stable-x86_64-pc-windows-gnu\\lib\\rustlib\\x86_64-pc-windows-gnu\\lib\\libunwind-5c6cf767.rlib" "C:\\Users\\jdub\\.multirust\\toolchains\\stable-x86_64-pc-windows-gnu\\lib\\rustlib\\x86_64-pc-windows-gnu\\lib\\librand-5c6cf767.rlib" "C:\\Users\\jdub\\.multirust\\toolchains\\stable-x86_64-pc-windows-gnu\\lib\\rustlib\\x86_64-pc-windows-gnu\\lib\\libcollections-5c6cf767.rlib" "C:\\Users\\jdub\\.multirust\\toolchains\\stable-x86_64-pc-windows-gnu\\lib\\rustlib\\x86_64-pc-windows-gnu\\lib\\librustc_unicode-5c6cf767.rlib" "C:\\Users\\jdub\\.multirust\\toolchains\\stable-x86_64-pc-windows-gnu\\lib\\rustlib\\x86_64-pc-windows-gnu\\lib\\liblibc-5c6cf767.rlib" "C:\\Users\\jdub\\.multirust\\toolchains\\stable-x86_64-pc-windows-gnu\\lib\\rustlib\\x86_64-pc-windows-gnu\\lib\\liballoc-5c6cf767.rlib" "C:\\Users\\jdub\\.multirust\\toolchains\\stable-x86_64-pc-windows-gnu\\lib\\rustlib\\x86_64-pc-windows-gnu\\lib\\liballoc_system-5c6cf767.rlib" "C:\\Users\\jdub\\.multirust\\toolchains\\stable-x86_64-pc-windows-gnu\\lib\\rustlib\\x86_64-pc-windows-gnu\\lib\\libcore-5c6cf767.rlib" "-l" "kernel32" "-l" "ws2_32" "-l" "userenv" "-l" "shell32" "-l" "advapi32" "-l" "gcc_eh" "-l" "compiler-rt" "-lmingwex" "-lmingw32" "-lgcc" "-lmsvcrt" "-luser32" "-lkernel32" "C:\\Users\\jdub\\.multirust\\toolchains\\stable-x86_64-pc-windows-gnu\\lib\\rustlib\\x86_64-pc-windows-gnu\\lib\\rsend.o"
  = note: class_with_typedef.0.o:(.text+0x12f9): undefined reference to `C::method(int)'
class_with_typedef.0.o:(.text+0x132b): undefined reference to `C::methodRef(int&)'
class_with_typedef.0.o:(.text+0x135b): undefined reference to `C::complexMethodRef(char const*&)'
class_with_typedef.0.o:(.text+0x1389): undefined reference to `C::anotherMethod(int)'
ld: class_with_typedef.0.o: bad reloc address 0x18 in section `.xdata'
ld: final link failed: Invalid operation


error: aborting due to previous error

D:\GitHub\rust-bindgen\libbindgen [logless-library ≡ +2 ~0 -0 !]> which gcc
/c/Users/jdub/.multirust/toolchains/stable-x86_64-pc-windows-gnu/lib/rustlib/x86_64-pc-windows-gnu/bin/gcc

@emilio
Copy link
Contributor

emilio commented Nov 6, 2016

I bet it's not an installation problem, but that rustc may not be performing dead code elimination, which is what could cause those linker errors.

EDIT: gcc which is the linker you're using, not rustc directly, of course.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants