about summary refs log tree commit diff
path: root/src/rustllvm
AgeCommit message (Collapse)AuthorLines
2017-02-08Rollup merge of #38699 - japaric:lsan, r=alexcrichtonCorey Farwell-0/+9
LeakSanitizer, ThreadSanitizer, AddressSanitizer and MemorySanitizer support ``` $ cargo new --bin leak && cd $_ $ edit Cargo.toml && tail -n3 $_ ``` ``` toml [profile.dev] opt-level = 1 ``` ``` $ edit src/main.rs && cat $_ ``` ``` rust use std::mem; fn main() { let xs = vec![0, 1, 2, 3]; mem::forget(xs); } ``` ``` $ RUSTFLAGS="-Z sanitizer=leak" cargo run --target x86_64-unknown-linux-gnu; echo $? Finished dev [optimized + debuginfo] target(s) in 0.0 secs Running `target/debug/leak` ================================================================= ==10848==ERROR: LeakSanitizer: detected memory leaks Direct leak of 16 byte(s) in 1 object(s) allocated from: #0 0x557c3488db1f in __interceptor_malloc /shared/rust/checkouts/lsan/src/compiler-rt/lib/lsan/lsan_interceptors.cc:55 #1 0x557c34888aaa in alloc::heap::exchange_malloc::h68f3f8b376a0da42 /shared/rust/checkouts/lsan/src/liballoc/heap.rs:138 #2 0x557c34888afc in leak::main::hc56ab767de6d653a $PWD/src/main.rs:4 #3 0x557c348c0806 in __rust_maybe_catch_panic ($PWD/target/debug/leak+0x3d806) SUMMARY: LeakSanitizer: 16 byte(s) leaked in 1 allocation(s). 23 ``` ``` $ cargo new --bin racy && cd $_ $ edit src/main.rs && cat $_ ``` ``` rust use std::thread; static mut ANSWER: i32 = 0; fn main() { let t1 = thread::spawn(|| unsafe { ANSWER = 42 }); unsafe { ANSWER = 24; } t1.join().ok(); } ``` ``` $ RUSTFLAGS="-Z sanitizer=thread" cargo run --target x86_64-unknown-linux-gnu; echo $? ================== WARNING: ThreadSanitizer: data race (pid=12019) Write of size 4 at 0x562105989bb4 by thread T1: #0 racy::main::_$u7b$$u7b$closure$u7d$$u7d$::hbe13ea9e8ac73f7e $PWD/src/main.rs:6 (racy+0x000000010e3f) #1 _$LT$std..panic..AssertUnwindSafe$LT$F$GT$$u20$as$u20$core..ops..FnOnce$LT$$LP$$RP$$GT$$GT$::call_once::h2e466a92accacc78 /shared/rust/checkouts/lsan/src/libstd/panic.rs:296 (racy+0x000000010cc5) #2 std::panicking::try::do_call::h7f4d2b38069e4042 /shared/rust/checkouts/lsan/src/libstd/panicking.rs:460 (racy+0x00000000c8f2) #3 __rust_maybe_catch_panic <null> (racy+0x0000000b4e56) #4 std::panic::catch_unwind::h31ca45621ad66d5a /shared/rust/checkouts/lsan/src/libstd/panic.rs:361 (racy+0x00000000b517) #5 std::thread::Builder::spawn::_$u7b$$u7b$closure$u7d$$u7d$::hccfc37175dea0b01 /shared/rust/checkouts/lsan/src/libstd/thread/mod.rs:357 (racy+0x00000000c226) #6 _$LT$F$u20$as$u20$alloc..boxed..FnBox$LT$A$GT$$GT$::call_box::hd880bbf91561e033 /shared/rust/checkouts/lsan/src/liballoc/boxed.rs:605 (racy+0x00000000f27e) #7 std::sys::imp::thread::Thread::new::thread_start::hebdfc4b3d17afc85 <null> (racy+0x0000000abd40) Previous write of size 4 at 0x562105989bb4 by main thread: #0 racy::main::h23e6e5ca46d085c3 $PWD/src/main.rs:8 (racy+0x000000010d7c) #1 __rust_maybe_catch_panic <null> (racy+0x0000000b4e56) #2 __libc_start_main <null> (libc.so.6+0x000000020290) Location is global 'racy::ANSWER::h543d2b139f819b19' of size 4 at 0x562105989bb4 (racy+0x0000002f8bb4) Thread T1 (tid=12028, running) created by main thread at: #0 pthread_create /shared/rust/checkouts/lsan/src/compiler-rt/lib/tsan/rtl/tsan_interceptors.cc:902 (racy+0x00000001aedb) #1 std::sys::imp::thread::Thread::new::hce44187bf4a36222 <null> (racy+0x0000000ab9ae) #2 std::thread::spawn::he382608373eb667e /shared/rust/checkouts/lsan/src/libstd/thread/mod.rs:412 (racy+0x00000000b5aa) #3 racy::main::h23e6e5ca46d085c3 $PWD/src/main.rs:6 (racy+0x000000010d5c) #4 __rust_maybe_catch_panic <null> (racy+0x0000000b4e56) #5 __libc_start_main <null> (libc.so.6+0x000000020290) SUMMARY: ThreadSanitizer: data race $PWD/src/main.rs:6 in racy::main::_$u7b$$u7b$closure$u7d$$u7d$::hbe13ea9e8ac73f7e ================== ThreadSanitizer: reported 1 warnings 66 ``` ``` $ cargo new --bin oob && cd $_ $ edit src/main.rs && cat $_ ``` ``` rust fn main() { let xs = [0, 1, 2, 3]; let y = unsafe { *xs.as_ptr().offset(4) }; } ``` ``` $ RUSTFLAGS="-Z sanitizer=address" cargo run --target x86_64-unknown-linux-gnu; echo $? ================================================================= ==13328==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7fff29f3ecd0 at pc 0x55802dc6bf7e bp 0x7fff29f3ec90 sp 0x7fff29f3ec88 READ of size 4 at 0x7fff29f3ecd0 thread T0 #0 0x55802dc6bf7d in oob::main::h0adc7b67e5feb2e7 $PWD/src/main.rs:3 #1 0x55802dd60426 in __rust_maybe_catch_panic ($PWD/target/debug/oob+0xfe426) #2 0x55802dd58dd9 in std::rt::lang_start::hb2951fc8a59d62a7 ($PWD/target/debug/oob+0xf6dd9) #3 0x55802dc6c002 in main ($PWD/target/debug/oob+0xa002) #4 0x7fad8c3b3290 in __libc_start_main (/usr/lib/libc.so.6+0x20290) #5 0x55802dc6b719 in _start ($PWD/target/debug/oob+0x9719) Address 0x7fff29f3ecd0 is located in stack of thread T0 at offset 48 in frame #0 0x55802dc6bd5f in oob::main::h0adc7b67e5feb2e7 $PWD/src/main.rs:1 This frame has 1 object(s): [32, 48) 'xs' <== Memory access at offset 48 overflows this variable HINT: this may be a false positive if your program uses some custom stack unwind mechanism or swapcontext (longjmp and C++ exceptions *are* supported) SUMMARY: AddressSanitizer: stack-buffer-overflow $PWD/src/main.rs:3 in oob::main::h0adc7b67e5feb2e7 Shadow bytes around the buggy address: 0x1000653dfd40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x1000653dfd50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x1000653dfd60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x1000653dfd70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x1000653dfd80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 =>0x1000653dfd90: 00 00 00 00 f1 f1 f1 f1 00 00[f3]f3 00 00 00 00 0x1000653dfda0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x1000653dfdb0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x1000653dfdc0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x1000653dfdd0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x1000653dfde0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Shadow byte legend (one shadow byte represents 8 application bytes): Addressable: 00 Partially addressable: 01 02 03 04 05 06 07 Heap left redzone: fa Heap right redzone: fb Freed heap region: fd Stack left redzone: f1 Stack mid redzone: f2 Stack right redzone: f3 Stack partial redzone: f4 Stack after return: f5 Stack use after scope: f8 Global redzone: f9 Global init order: f6 Poisoned by user: f7 Container overflow: fc Array cookie: ac Intra object redzone: bb ASan internal: fe Left alloca redzone: ca Right alloca redzone: cb ==13328==ABORTING 1 ``` ``` $ cargo new --bin uninit && cd $_ $ edit src/main.rs && cat $_ ``` ``` rust use std::mem; fn main() { let xs: [u8; 4] = unsafe { mem::uninitialized() }; let y = xs[0] + xs[1]; } ``` ``` $ RUSTFLAGS="-Z sanitizer=memory" cargo run; echo $? ==30198==WARNING: MemorySanitizer: use-of-uninitialized-value #0 0x563f4b6867da in uninit::main::hc2731cd4f2ed48f8 $PWD/src/main.rs:5 #1 0x563f4b7033b6 in __rust_maybe_catch_panic ($PWD/target/debug/uninit+0x873b6) #2 0x563f4b6fbd69 in std::rt::lang_start::hb2951fc8a59d62a7 ($PWD/target/debug/uninit+0x7fd69) #3 0x563f4b6868a9 in main ($PWD/target/debug/uninit+0xa8a9) #4 0x7fe844354290 in __libc_start_main (/usr/lib/libc.so.6+0x20290) #5 0x563f4b6864f9 in _start ($PWD/target/debug/uninit+0xa4f9) SUMMARY: MemorySanitizer: use-of-uninitialized-value $PWD/src/main.rs:5 in uninit::main::hc2731cd4f2ed48f8 Exiting 77 ```
2017-02-08sanitizer supportJorge Aparicio-0/+9
2017-02-08Rollup merge of #39529 - dylanmckay:llvm-4.0-align32, r=alexcrichtonCorey Farwell-10/+10
[LLVM 4.0] Use 32-bits for alignment LLVM 4.0 changes this. This change is fine to make for LLVM 3.9 as we won't have alignments greater than 2^32-1.
2017-02-04Emit DW_AT_main_subprogramTom Tromey-0/+6
This changes rustc to emit DW_AT_main_subprogram on the "main" program. This lets gdb suitably stop at the user's main in response to "start" (rather than the library's main, which is what happens currently). Fixes #32620 r? michaelwoerister
2017-02-04[llvm] Use 32-bits for alignmentDylan McKay-10/+10
LLVM 4.0 changes this. This change is fine to make for LLVM 3.9 as we won't have alignments greater than 2^32-1.
2017-02-04Support a debug info API change for LLVM 4.0Dylan McKay-0/+4
Instead of directly creating a 'DIGlobalVariable', we now have to create a 'DIGlobalVariableExpression' which itself contains a reference to a 'DIGlobalVariable'. This is a straightforward change. In the future, we should rename 'DIGlobalVariable' in the FFI bindings, assuming we will only refer to 'DIGlobalVariableExpression' and not 'DIGlobalVariable'.
2017-01-26Remove unnecessary LLVMRustPersonalityFn bindingSimonas Kazlauskas-8/+0
LLVM Core C bindings provide this function for all the versions back to what we support (3.7), and helps to avoid this unnecessary builder->function transition every time. Also a negative diff.
2017-01-14Fix covered-switch-default warnings in RustWrapperRuud van Asseldonk-10/+4
These switch statements cover all possible values, so the default case is dead code (it contains an llvm_unreachable anyway), triggering a -Wcovered-switch-default warning. Moving the unreachable after the switch resolves these warnings. This keeps the build output clean.
2017-01-01Auto merge of #38745 - CannedYerins:llvm-code-style, r=rkruppebors-439/+442
Improve naming style in rustllvm. As per the LLVM style guide, use CamelCase for all locals and classes, and camelCase for all non-FFI functions. Also, make names of variables of commonly used types more consistent. Fixes #38688. r? @rkruppe
2017-01-01Merge branch 'master' into sparc64Seo Sanghyeon-1555/+1323
2016-12-31Auto merge of #38482 - est31:i128, r=eddybbors-0/+17
i128 and u128 support Brings i128 and u128 support to nightly rust, behind a feature flag. The goal of this PR is to do the bulk of the work for 128 bit integer support. Smaller but just as tricky features needed for stabilisation like 128 bit enum discriminants are left for future PRs. Rebased version of #37900, which in turn was a rebase + improvement of #35954 . Sadly I couldn't reopen #37900 due to github. There goes my premium position in the homu queue... [plugin-breaking-change] cc #35118 (tracking issue)
2016-12-31Improve naming style in rustllvm.Ian Kerins-439/+442
As per the LLVM style guide, use CamelCase for all locals and classes, and camelCase for all non-FFI functions. Also, make names of variables of commonly used types more consistent. Fixes #38688.
2016-12-30Switching from NULL to nullptr in src/rustllvm.karpinski-23/+23
2016-12-30Ran clang-format on src/rustllvm with llvm as the coding style.karpinski-1570/+1304
2016-12-30Fix rebase falloutSimonas Kazlauskas-0/+1
This commit includes manual merge conflict resolution changes from a rebase by @est31.
2016-12-30Add a way to retrieve constant value in 128 bitsSimonas Kazlauskas-0/+16
Fixes rebase fallout, makes code correct in presence of 128-bit constants. This commit includes manual merge conflict resolution changes from a rebase by @est31.
2016-12-29further enable the Sparc LLVM backendJonathan A. Kollasch-1/+8
2016-12-29Rollup merge of #38676 - rkruppe:llvm-check-success, r=alexcrichtonAlex Crichton-9/+26
Check *all* errors in LLVMRustArchiveIterator* API Incrementing the `Archive::child_iterator` fetches and validates the next child. This can trigger an error, which we previously checked on the *next* call to `LLVMRustArchiveIteratorNext()`. This means we ignore the last error if we stop iterating halfway through. This is harmless (we don't access the child, after all) but LLVM 4.0 calls `abort()` if *any* error goes unchecked, even a success value. This means that basically any rustc invocation that opens an archive and searches through it would die. The solution implemented here is to change the order of operations, such that advancing the iterator and fetching the newly-validated iterator happens in the same `Next()` call. This keeps the error handling behavior as before but ensures all `Error`s get checked.
2016-12-29Check *all* errors in LLVMRustArchiveIterator* APIRobin Kruppe-9/+26
Incrementing the `Archive::child_iterator` fetches and validates the next child. This can trigger an error, which we previously checked on the *next* call to `LLVMRustArchiveIteratorNext()`. This means we ignore the last error if we stop iterating halfway through. This is harmless (we don't access the child, after all) but LLVM 4.0 calls `abort()` if *any* error goes unchecked, even a success value. This means that basically any rustc invocation that opens an archive and searches through it would die. The solution implemented here is to change the order of operations, such that advancing the iterator and fetching the newly-validated iterator happens in the same `Next()` call. This keeps the error handling behavior as before but ensures all `Error`s get checked.
2016-12-26Auto merge of #38314 - japaric:do-not-delete-enable-llvm-backend, r=alexcrichtonbors-1/+1
initial SPARC support ### UPDATE Can now compile `no_std` executables with: ``` $ cargo new --bin app && cd $_ $ edit Cargo.toml && tail -n2 $_ [dependencies] core = { path = "/path/to/rust/src/libcore" } $ edit src/main.rs && cat $_ #![feature(lang_items)] #![no_std] #![no_main] #[no_mangle] pub fn _start() -> ! { loop {} } #[lang = "panic_fmt"] fn panic_fmt() -> ! { loop {} } $ edit sparc-none-elf.json && cat $_ { "arch": "sparc", "data-layout": "E-m:e-p:32:32-i64:64-f128:64-n32-S64", "executables": true, "llvm-target": "sparc", "os": "none", "panic-strategy": "abort", "target-endian": "big", "target-pointer-width": "32" } $ cargo rustc --target sparc-none-elf -- -C linker=sparc-unknown-elf-gcc -C link-args=-nostartfiles $ file target/sparc-none-elf/debug/app app: ELF 32-bit MSB executable, SPARC, version 1 (SYSV), statically linked, not stripped $ sparc-unknown-elf-readelf -h target/sparc-none-elf/debug/app ELF Header: Magic: 7f 45 4c 46 01 02 01 00 00 00 00 00 00 00 00 00 Class: ELF32 Data: 2's complement, big endian Version: 1 (current) OS/ABI: UNIX - System V ABI Version: 0 Type: EXEC (Executable file) Machine: Sparc Version: 0x1 Entry point address: 0x10074 Start of program headers: 52 (bytes into file) Start of section headers: 1188 (bytes into file) Flags: 0x0 Size of this header: 52 (bytes) Size of program headers: 32 (bytes) Number of program headers: 2 Size of section headers: 40 (bytes) Number of section headers: 14 Section header string table index: 11 $ sparc-unknown-elf-objdump -Cd target/sparc-none-elf/debug/app target/sparc-none-elf/debug/app: file format elf32-sparc Disassembly of section .text: 00010074 <_start>: 10074: 9d e3 bf 98 save %sp, -104, %sp 10078: 10 80 00 02 b 10080 <_start+0xc> 1007c: 01 00 00 00 nop 10080: 10 80 00 02 b 10088 <_start+0x14> 10084: 01 00 00 00 nop 10088: 10 80 00 00 b 10088 <_start+0x14> 1008c: 01 00 00 00 nop ``` --- Someone wants to attempt launching some Rust [into space](https://www.reddit.com/r/rust/comments/5h76oa/c_interop/) but their platform is based on the SPARCv8 architecture. Let's not block them by enabling LLVM's SPARC backend. Something very important that they'll also need is the "cabi" stuff as they'll be embedding some Rust code into a bigger C application (i.e. heavy use of `extern "C"`). The question there is what name(s) should we use for "target_arch" as the "cabi" implementation [varies according to that parameter](https://github.com/rust-lang/rust/blob/1.13.0/src/librustc_trans/abi.rs#L498-L523). AFAICT, SPARCv8 is a 32-bit architecture and SPARCv9 is a 64-bit architecture. And, LLVM uses `sparc`, `sparcv9` and `sparcel` for [the architecture triple](https://github.com/rust-lang/llvm/blob/ac1c94226e9fa17005ce7e2dd52dd6d1875f3137/include/llvm/ADT/Triple.h#L67-L69) so perhaps we should use `target_arch = "sparc"` (32-bit) and `target_arch = "sparcv9"` (64-bit) as well. r? @alexcrichton This PR only enables this LLVM backend when rustbuild is used. Do I also need to implement this for the old Makefile-based build system? Or are all our nightlies now being generated using rustbuild? cc @brson
2016-12-21Fixed fastcall not applying inreg attributes to arguments like the C/C++ ↵Ivan Molodetskikh-0/+3
fastcall.
2016-12-19touch src/rustllvm/llvm-auto-clean-triggerJorge Aparicio-1/+1
2016-12-16llvm: backport r280651Jorge Aparicio-1/+1
fixes #38406
2016-12-14Update LLVM global variable debug info API for 4.0Dylan McKay-5/+20
This teaches Rust about an LLVM 4.0 API change for creating debug info for global variables. This change was made in upstream LLVM patch https://reviews.llvm.org/D20147 This is almost 1:1 copy of how clang did it in http://reviews.llvm.org/D20415
2016-12-12[LLVM 4.0] Move debuginfo alignment argumentJake Goulding-8/+29
Alignment was removed from createBasicType and moved to - createGlobalVariable - createAutoVariable - createStaticMemberType (unused in Rust) - createTempGlobalVariableFwdDecl (unused in Rust) https://github.com/llvm-mirror/llvm/commit/e69c459a6e9756ca1ff3acb1dcfc434843aee80f
2016-12-11[LLVM 4.0] Explicitly call constructor of 'llvm::Error'Dylan McKay-0/+2
The implicit constructor has been deleted. We should use Error::success() instead. The constructor in the LLVM headers mentions that "success" should be used instead of the deleted constructor for clarity.
2016-12-11Auto merge of #38240 - pftbest:update_llvm, r=japaricbors-1/+1
LLVM: Update submodule to include patches for MSP430. Fixes #37829
2016-12-10Auto merge of #38223 - rkruppe:llvm-stringref-fixes, r=alexcrichtonbors-2/+5
printf type correctness The `%.*s` format specifier requires an int for the maximum size, but StringRef::size is a size_t cc @shepmaster
2016-12-09Auto merge of #38196 - rkruppe:llvm-archivewrapper-fwdcompat, r=alexcrichtonbors-0/+19
[LLVM 4.0] rustllvm archive support Error handling is being transitioned from ErrorOr<T> to Expected<T> which has a different API and requires explicitly handling all errors cc #37609
2016-12-08LLVM: update triggerVadzim Dambrouski-1/+1
2016-12-08Auto merge of #38156 - shepmaster:llvm-4.0-bitcode-reader-writer, r=alexcrichtonbors-2/+23
[LLVM 4.0] New bitcode headers and API /cc @michaelwoerister @rkruppe
2016-12-07printf type correctnessRobin Kruppe-2/+5
The %.*s format specifier requires an int for the maximum size, but StringRef::size is a size_t cc @shepmaster
2016-12-07mk: Switch rustbuild to the default build systemAlex Crichton-1/+1
This commit switches the default build system for Rust from the makefiles to rustbuild. The rustbuild build system has been in development for almost a year now and has become quite mature over time. This commit is an implementation of the proposal on [internals] which slates deletion of the makefiles on 2016-01-02. [internals]: https://internals.rust-lang.org/t/proposal-for-promoting-rustbuild-to-official-status/4368 This commit also updates various documentation in `README.md`, `CONTRIBUTING.md`, `src/bootstrap/README.md`, and throughout the source code of rustbuild itself. Closes #37858
2016-12-06[LLVM 4.0] rustllvm archive supportRobin Kruppe-0/+19
Error handling is being transitioned from ErrorOr<T> to Expected<T> which has a different API and requires explicitly handling all errors
2016-12-05Make LLVM symbol visibility FFI types more stable.Michael Woerister-0/+42
2016-12-05Auto merge of #38100 - nox:llvm, r=alexcrichtonbors-1/+1
Update llvm fork to 3ec14daffb4b8c0604df50b7fb0ab552f456e381
2016-12-04[LLVM 4.0] New bitcode headers and APIJake Goulding-2/+23
2016-12-02[LLVM 4.0] Support new DIFlags enumJake Goulding-0/+5
2016-12-02[LLVM] Introduce a stable representation of DIFlagsJake Goulding-13/+93
In LLVM 4.0, this enum becomes an actual type-safe enum, which breaks all of the interfaces. Introduce our own copy of the bitflags that we can then safely convert to the LLVM one.
2016-12-01Update llvm fork to 3ec14daffb4b8c0604df50b7fb0ab552f456e381Anthony Ramine-1/+1
2016-11-28Don't assume llvm::StringRef is null terminatedRobin Kruppe-11/+10
StringRefs have a length and their contents are not usually null-terminated. The solution is to either copy the string data (in rustc_llvm::diagnostic) or take the size into account (in LLVMRustPrintPasses). I couldn't trigger a bug caused by this (apparently all the strings returned in practice are actually null-terminated) but this is more correct and more future-proof.
2016-11-27Auto merge of #38027 - rkruppe:llvm-printpasses-fwdcompat, r=alexcrichtonbors-0/+7
[LLVM 4.0] LLVMRustPrintPasses Adapt `LLVMRustPrintPasses` to LLVM 4.0 preferring `StringRef` over `char *` cc #37609
2016-11-27Adapt LLVMRustPrintPasses to LLVM 4.0 preferring `StringRef` over `char *`Robin Kruppe-0/+7
2016-11-25Auto merge of #38000 - rkruppe:llvm-dinamespace-fwdcompat, r=alexcrichtonbors-1/+5
[LLVM 4.0] Pass new argument ExportSymbol to DIBuilder::createNameSpace cc #37609
2016-11-25Pass new argument ExportSymbol to DIBuilder::createNameSpaceRobin Kruppe-1/+5
2016-11-24Support LLVM 4.0 in OptimizationDiagnostic FFIRobin Kruppe-2/+7
- getMsg() changed to return std::string by-value. Fix: copy the data to a rust String during unpacking. - getPassName() changed to return StringRef
2016-11-21Restore compatibility with LLVM 3.7 and 3.8Seo Sanghyeon-10/+9
2016-11-20Auto merge of #37861 - shepmaster:llvm-4.0-inline-pass, r=alexcrichtonbors-0/+7
[LLVM 4.0] Update AlwaysInliner pass header and constructor
2016-11-19Auto merge of #37831 - rkruppe:llvm-attr-fwdcompat, r=eddybbors-45/+92
[LLVM 4.0] Use llvm::Attribute APIs instead of "raw value" APIs The latter will be removed in LLVM 4.0 (see https://github.com/llvm-mirror/llvm/commit/4a6fc8bacf11d8066da72cf8481467167877ed16). The librustc_llvm API remains mostly unchanged, except that llvm::Attribute is no longer a bitflag but represents only a *single* attribute. The ability to store many attributes in a small number of bits and modify them without interacting with LLVM is only used in rustc_trans::abi and closely related modules, and only attributes for function arguments are considered there. Thus rustc_trans::abi now has its own bit-packed representation of argument attributes, which are translated to rustc_llvm::Attribute when applying the attributes. cc #37609
2016-11-18[LLVM 4.0] Update AlwaysInliner pass header and constructorJake Goulding-0/+7
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-03-01 08:43:23 +0000