Commit graph

225 commits

Author SHA1 Message Date
Tim Neumann
2c9c8dc5f4 rustllvm: use LLVMMetadataRef 2017-07-21 14:31:46 +02:00
Marco Castelluccio
ecba8d6a23 Merge branch 'profiling' of github.com:whitequark/rust into profiling 2017-06-04 15:54:39 +01:00
Ariel Ben-Yehuda
7b295eea42 add NullOp::SizeOf and BinOp::Offset 2017-05-28 10:43:24 +03:00
whitequark
42754ce710 Add profiling support, through the rustc -Z profile flag.
When -Z profile is passed, the GCDAProfiling LLVM pass is added
to the pipeline, which uses debug information to instrument the IR.
After compiling with -Z profile, the $(OUT_DIR)/$(CRATE_NAME).gcno
file is created, containing initial profiling information.
After running the program built, the $(OUT_DIR)/$(CRATE_NAME).gcda
file is created, containing branch counters.

The created *.gcno and *.gcda files can be processed using
the "llvm-cov gcov" and "lcov" tools. The profiling data LLVM
generates does not faithfully follow the GCC's format for *.gcno
and *.gcda files, and so it will probably not work with other tools
(such as gcov itself) that consume these files.
2017-05-01 09:16:20 +00:00
A.J. Gardner
9240054b3e Expose LLVM appendModuleInlineAsm 2017-04-12 19:12:49 -05:00
Tim Neumann
95bd7f2e01 add missing global metadata 2017-03-16 21:10:04 +01:00
Tim Neumann
222ca3c4a5 clang-format 2017-03-16 21:03:22 +01:00
Tim Neumann
449219ab2b isolate llvm 4.0 code path 2017-03-16 21:01:05 +01:00
bors
05a7f25cc4 Auto merge of #39456 - nagisa:mir-switchint-everywhere, r=nikomatsakis
[MIR] SwitchInt Everywhere

Something I've been meaning to do for a very long while. This PR essentially gets rid of 3 kinds of conditional branching and only keeps the most general one - `SwitchInt`. Primary benefits are such that dealing with MIR now does not involve dealing with 3 different ways to do conditional control flow. On the other hand, constructing a `SwitchInt` currently requires more code than what previously was necessary to build an equivalent `If` terminator. Something trivially "fixable" with some constructor methods somewhere (MIR needs stuff like that badly in general).

Some timings (tl;dr: slightly faster^1 (unexpected), but also uses slightly more memory at peak (expected)):

^1: Not sure if the speed benefits are because of LLVM liking the generated code better or the compiler itself getting compiled better. Either way, its a net benefit. The CORE and SYNTAX timings done for compilation without optimisation.

```
AFTER:
Building stage1 std artifacts (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu)
    Finished release [optimized] target(s) in 31.50 secs
    Finished release [optimized] target(s) in 31.42 secs
Building stage1 compiler artifacts (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu)
    Finished release [optimized] target(s) in 439.56 secs
    Finished release [optimized] target(s) in 435.15 secs

CORE: 99% (24.81 real, 0.13 kernel, 24.57 user); 358536k resident
CORE: 99% (24.56 real, 0.15 kernel, 24.36 user); 359168k resident
SYNTAX: 99% (49.98 real, 0.48 kernel, 49.42 user); 653416k resident
SYNTAX: 99% (50.07 real, 0.58 kernel, 49.43 user); 653604k resident

BEFORE:
Building stage1 std artifacts (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu)
    Finished release [optimized] target(s) in 31.84 secs
Building stage1 compiler artifacts (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu)
    Finished release [optimized] target(s) in 451.17 secs

CORE: 99% (24.66 real, 0.20 kernel, 24.38 user); 351096k resident
CORE: 99% (24.36 real, 0.17 kernel, 24.18 user); 352284k resident
SYNTAX: 99% (52.24 real, 0.56 kernel, 51.66 user); 645544k resident
SYNTAX: 99% (51.55 real, 0.48 kernel, 50.99 user); 646428k resident
```

cc @nikomatsakis @eddyb
2017-02-13 02:32:09 +00:00
Matt Ickstadt
68fff62542 [LLVM 4.0] Fix CreateCompileUnit 2017-02-11 15:15:28 -06:00
Simonas Kazlauskas
f3bd723101 Fix intcast, use it where appropriate 2017-02-10 19:47:09 +02:00
bors
4053276354 Auto merge of #38109 - tromey:main-subprogram, r=michaelwoerister
Emit DW_AT_main_subprogram

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-09 17:09:50 +00:00
Corey Farwell
3053494a9a Rollup merge of #38699 - japaric:lsan, r=alexcrichton
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:🧵: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:👿🧵:Thread:🆕: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:👿🧵:Thread:🆕:hce44187bf4a36222 <null> (racy+0x0000000ab9ae)
    #2 std:🧵: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-08 23:55:43 -05:00
Jorge Aparicio
9af6aa3889 sanitizer support 2017-02-08 18:51:43 -05:00
Corey Farwell
7709c4d2b9 Rollup merge of #39529 - dylanmckay:llvm-4.0-align32, r=alexcrichton
[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-08 10:19:49 -05:00
Tom Tromey
b037c5211b Emit DW_AT_main_subprogram
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 23:19:39 -07:00
Dylan McKay
b4e6f70eda [llvm] 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-04 23:51:10 +13:00
Dylan McKay
768c6c081e Support a debug info API change for LLVM 4.0
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-02-04 23:22:05 +13:00
Simonas Kazlauskas
1363cdaec9 Remove unnecessary LLVMRustPersonalityFn binding
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-26 23:49:17 +02:00
Ruud van Asseldonk
004f18d9fb Fix covered-switch-default warnings in RustWrapper
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-14 15:38:12 +01:00
bors
ac5cd3bd43 Auto merge of #38745 - CannedYerins:llvm-code-style, r=rkruppe
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-01 11:58:02 +00:00
bors
38bd207626 Auto merge of #38482 - est31:i128, r=eddyb
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-31 18:54:31 +00:00
Ian Kerins
e6f97114ca 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.
2016-12-31 13:20:30 -05:00
karpinski
72ebc02f13 Switching from NULL to nullptr in src/rustllvm. 2016-12-30 16:37:05 +01:00
karpinski
c72d859e4f Ran clang-format on src/rustllvm with llvm as the coding style. 2016-12-30 16:36:50 +01:00
Simonas Kazlauskas
7a3704c500 Fix rebase fallout
This commit includes manual merge conflict resolution changes from a rebase by @est31.
2016-12-30 15:17:27 +01:00
Simonas Kazlauskas
9aad2d551e Add a way to retrieve constant value in 128 bits
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-30 15:17:26 +01:00
Ivan Molodetskikh
c461cdfdf6
Fixed fastcall not applying inreg attributes to arguments like the C/C++ fastcall. 2016-12-21 21:44:40 +03:00
Dylan McKay
e080804f72 Update LLVM global variable debug info API for 4.0
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-14 21:39:13 +13:00
Jake Goulding
5bce12c95f [LLVM 4.0] Move debuginfo alignment argument
Alignment was removed from createBasicType and moved to

- createGlobalVariable
- createAutoVariable
- createStaticMemberType (unused in Rust)
- createTempGlobalVariableFwdDecl (unused in Rust)

e69c459a6e
2016-12-12 09:00:04 -05:00
bors
47ffafcdcd Auto merge of #38156 - shepmaster:llvm-4.0-bitcode-reader-writer, r=alexcrichton
[LLVM 4.0] New bitcode headers and API

/cc @michaelwoerister @rkruppe
2016-12-08 11:45:26 +00:00
Michael Woerister
d1a6d47f94 Make LLVM symbol visibility FFI types more stable. 2016-12-05 11:05:25 -05:00
Jake Goulding
d5f6125fb3 [LLVM 4.0] New bitcode headers and API 2016-12-04 11:14:08 -05:00
Jake Goulding
757a9cea3f [LLVM 4.0] Support new DIFlags enum 2016-12-02 21:14:06 -05:00
Jake Goulding
dbdd60e6d7 [LLVM] Introduce a stable representation of DIFlags
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-02 21:13:31 -05:00
Robin Kruppe
85dc08e525 Don't assume llvm::StringRef is null terminated
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-28 17:33:13 +01:00
bors
2217bd771c Auto merge of #38000 - rkruppe:llvm-dinamespace-fwdcompat, r=alexcrichton
[LLVM 4.0] Pass new argument ExportSymbol to DIBuilder::createNameSpace

cc #37609
2016-11-25 16:57:37 -06:00
Robin Kruppe
2e6d49de07 Pass new argument ExportSymbol to DIBuilder::createNameSpace 2016-11-25 17:23:25 +01:00
Robin Kruppe
730400167a Support LLVM 4.0 in OptimizationDiagnostic FFI
- 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-24 17:33:47 +01:00
Seo Sanghyeon
c45f3dee10 Restore compatibility with LLVM 3.7 and 3.8 2016-11-21 20:30:05 +09:00
Robin Kruppe
30daedf603 Use llvm::Attribute API instead of "raw value" APIs, which will be removed in LLVM 4.0.
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.
2016-11-17 21:12:26 +01:00
Michael Woerister
db4a9b3446 debuginfo: Remove some outdated stuff from LLVM DIBuilder binding. 2016-10-14 14:56:33 -04:00
Jake Goulding
e6e117c33a Extend preprocessor LLVM version checks to support LLVM 4.x
This doesn't actually do anything for LLVM 4.x yet, but sets the stage.
2016-09-26 13:40:29 -04:00
Matt Ickstadt
b9a8c1a063 Fix incorrect LLVM Linkage enum
The `Linkage` enum in librustc_llvm got out of sync with the version in LLVM and it caused two variants of the #[linkage=""] attribute to break.

This adds the functions `LLVMRustGetLinkage` and `LLVMRustSetLinkage` which convert between the Rust Linkage enum and the LLVM one, which should stop this from breaking every time LLVM changes it.

Fixes #33992
2016-09-04 16:12:01 -05:00
Vadim Chugunov
cf6461168f Fix debug line info for macro expansions.
Macro expansions produce code tagged with debug locations that are completely different from the surrounding expressions.  This wrecks havoc on debugger's ability the step over source lines.

In order to have a good line stepping behavior in debugger, we overwrite debug locations of macro expansions with that of the outermost expansion site.
2016-08-25 00:40:42 -07:00
Ariel Ben-Yehuda
3041a97b1a finish type-auditing rustllvm 2016-08-03 15:08:47 +03:00
Ariel Ben-Yehuda
d091ef802f begin auditing the C++ types in RustWrapper 2016-08-03 15:08:47 +03:00
Jan-Erik Rediger
7420874a97 [LLVM-3.9] Rename custom methods to Rust-specific ones 2016-07-29 10:29:44 +02:00
Jake Goulding
4f01329e0e Reflect supporting only LLVM 3.7+ in the LLVM wrappers 2016-06-09 15:59:26 -04:00
Björn Steinbrink
22f4587586 Use weak_odr linkage when reusing definitions across codegen units
When reuing a definition across codegen units, we obviously cannot use
internal linkage, but using external linkage means that we can end up
with multiple conflicting definitions of a single symbol across
multiple crates. Since the definitions should all be equal
semantically, we can use weak_odr linkage to resolve the situation.

Fixes #32518
2016-03-29 16:44:54 +02:00