Support raw-dylib link kind on ELF raw-dylib is a link kind that allows rustc to link against a library without having any library files present. This currently only exists on Windows. rustc will take all the symbols from raw-dylib link blocks and put them in an import library, where they can then be resolved by the linker. While import libraries don't exist on ELF, it would still be convenient to have this same functionality. Not having the libraries present at build-time can be convenient for several reasons, especially cross-compilation. With raw-dylib, code linking against a library can be cross-compiled without needing to have these libraries available on the build machine. If the libc crate makes use of this, it would allow cross-compilation without having any libc available on the build machine. This is not yet possible with this implementation, at least against libc's like glibc that use symbol versioning. The raw-dylib kind could be extended with support for symbol versioning in the future. This implementation is very experimental and I have not tested it very well. I have tested it for a toy example and the lz4-sys crate, where it was able to successfully link a binary despite not having a corresponding library at build-time. I was inspired by Björn's comments in https://internals.rust-lang.org/t/bundle-zig-cc-in-rustup-by-default/22096/27 Tracking issue: #135694 r? bjorn3 try-job: aarch64-apple try-job: x86_64-msvc-1 try-job: x86_64-msvc-2 try-job: test-various
UI Tests
This folder contains rustc's
UI tests.
Test Directives (Headers)
Typically, a UI test will have some test directives / headers which are special comments that tell compiletest how to build and interpret a test.
As part of an ongoing effort to rewrite compiletest
(see https://github.com/rust-lang/compiler-team/issues/536), a major
change proposal to change legacy compiletest-style headers // <directive>
to ui_test-style headers
//@ <directive> was accepted (see
https://github.com/rust-lang/compiler-team/issues/512.
An example directive is ignore-test. In legacy compiletest style, the header
would be written as
// ignore-test
but in ui_test style, the header would be written as
//@ ignore-test
compiletest is changed to accept only //@ directives for UI tests
(currently), and will reject and report an error if it encounters any
comments // <content> that may be parsed as a legacy compiletest-style
test header. To fix this, you should migrate to the ui_test-style header
//@ <content>.