Commit Graph

359 Commits

Author SHA1 Message Date
bors
be91c35f34 Auto merge of #54380 - RalfJung:miri-snapshot, r=eddyb
move CTFE engine snapshot state out of miri engine into CTFE machine instance

It still lives in the `interpret` module as it needs access to all sorts of private stuff. Also rename a thing to make @eddyb happy :D

The goal was not to change any behavior.
2018-09-23 12:33:54 +00:00
bors
317ae05a7e Auto merge of #54325 - michaelwoerister:incr-thinlto-tests, r=alexcrichton
incr.comp.: Allow for more fine-grained testing of CGU reuse and use it to test incremental ThinLTO.

This adds some tests specifically targeted at incremental ThinLTO, plus the infrastructure for tracking the kind of cache hit/miss we had for a given CGU. @alexcrichton, let me know if you can think of any more tests to add. ThinLTO works rather reliably for small functions, so we should be able to test it in a robust way.

I think after this lands it might time for a "Help us test incremental ThinLTO" post on irlo.

r? @alexcrichton
2018-09-23 07:38:17 +00:00
bors
c6e3d7fa31 Auto merge of #53508 - japaric:maybe-uninit, r=RalfJung
Implement `MaybeUninit`

This PR:

- Adds `MaybeUninit` (see #53491) to `{core,std}::mem`.
- Makes `mem::{uninitialized,zeroed}` panic when they are used to instantiate an uninhabited type.
- Does *not* deprecate `mem::{uninitialized,zeroed}` just yet. As per https://github.com/rust-lang/rust/issues/53491#issuecomment-414147666, we should not deprecate them until `MaybeUninit` is stabilized.
- It replaces uses of `mem::{uninitialized,zeroed}` in core and alloc with `MaybeUninit`.

There are still several instances of `mem::{uninitialized,zeroed}` in `std` that *this* PR doesn't address.

r? @RalfJung
cc @eddyb you may want to look at the new panicking logic
2018-09-22 23:08:03 +00:00
bors
4591a245c7 Auto merge of #54188 - lqd:fallout-53695, r=nikomatsakis
NLL: disallow creation of immediately unusable variables

Fix #53695

Original description follows

----

This WIP PR is for discussing the impact of fixing #53695 by injecting a fake read in let patterns.

(Travis will fail, at least the `mir-opt` suite is failing in its current state)
2018-09-22 20:38:19 +00:00
Jorge Aparicio
bc5b567a32 move our check to reuse a previous computation 2018-09-22 21:01:21 +02:00
Jorge Aparicio
33c10eae90 improve panic message 2018-09-22 21:01:21 +02:00
Jorge Aparicio
ce6e6f9333 use is_uninhabited in more places 2018-09-22 21:01:21 +02:00
Jorge Aparicio
a6d011a986 adapt to change in Session API 2018-09-22 21:01:21 +02:00
Jorge Aparicio
96572cb5f8 panic when instantiating an uninhabited type via mem::{uninitialized,zeroed} 2018-09-22 21:01:21 +02:00
kennytm
13cea8e05d
Rollup merge of #54258 - alexcrichton:lld-fatal-warnings, r=eddyb
Enable fatal warnings for the wasm32 linker

Historically LLD has emitted warnings for various reasons but all the bugs have
since been fixed (yay!) and by enabling fatal warnings we should be able to head
off bugs like #53390 sooner.
2018-09-20 21:36:22 +08:00
kennytm
6f7602d49d
Rollup merge of #54233 - irinagpopa:llvm-3.9, r=tromey
Remove LLVM 3.9 workaround.
2018-09-20 21:36:19 +08:00
Ralf Jung
018d128325 rename evaluator -> interpreter to make eddyb happy 2018-09-20 10:36:25 +02:00
Michael Woerister
ca197323b9 incr.comp.: Allow for more fine-grained testing of CGU reuse and use it to test incremental ThinLTO. 2018-09-18 16:33:24 +02:00
Remy Rakic
f5e310530a Refactor 'ReadForMatch' into 'FakeRead' and add the cause of the fake read 2018-09-18 14:36:37 +02:00
Nicholas Nethercote
266e2d3d69 Merge indexed_set.rs into bitvec.rs, and rename it bit_set.rs.
Currently we have two files implementing bitsets (and 2D bit matrices).
This commit combines them into one, taking the best features from each.

This involves renaming a lot of things. The high level changes are as
follows.
- bitvec.rs              --> bit_set.rs
- indexed_set.rs         --> (removed)
- BitArray + IdxSet      --> BitSet (merged, see below)
- BitVector              --> GrowableBitSet
- {,Sparse,Hybrid}IdxSet --> {,Sparse,Hybrid}BitSet
- BitMatrix              --> BitMatrix
- SparseBitMatrix        --> SparseBitMatrix

The changes within the bitset types themselves are as follows.

```
OLD             OLD             NEW
BitArray<C>     IdxSet<T>       BitSet<T>
--------        ------          ------
grow            -               grow
new             -               (remove)
new_empty       new_empty       new_empty
new_filled      new_filled      new_filled
-               to_hybrid       to_hybrid
clear           clear           clear
set_up_to       set_up_to       set_up_to
clear_above     -               clear_above
count           -               count
contains(T)     contains(&T)    contains(T)
contains_all    -               superset
is_empty        -               is_empty
insert(T)       add(&T)         insert(T)
insert_all      -               insert_all()
remove(T)       remove(&T)      remove(T)
words           words           words
words_mut       words_mut       words_mut
-               overwrite       overwrite
merge           union           union
-               subtract        subtract
-               intersect       intersect
iter            iter            iter
```

In general, when choosing names I went with:
- names that are more obvious (e.g. `BitSet` over `IdxSet`).
- names that are more like the Rust libraries (e.g. `T` over `C`,
  `insert` over `add`);
- names that are more set-like (e.g. `union` over `merge`, `superset`
  over `contains_all`, `domain_size` over `num_bits`).

Also, using `T` for index arguments seems more sensible than `&T` --
even though the latter is standard in Rust collection types -- because
indices are always copyable. It also results in fewer `&` and `*`
sigils in practice.
2018-09-18 07:08:09 +10:00
Alex Crichton
42652565ee Enable fatal warnings for the wasm32 linker
Historically LLD has emitted warnings for various reasons but all the bugs have
since been fixed (yay!) and by enabling fatal warnings we should be able to head
off bugs like #53390 sooner.
2018-09-15 09:15:48 -07:00
Unknown
40e7667506 Remove LLVM 3.9 workaround. 2018-09-14 19:06:45 +03:00
kennytm
9c0f946fe2
Rollup merge of #54095 - kenta7777:kenta7777#53719, r=davidtwco
Rename all mentions of `nil` to `unit`

Fixes #53719.

Renamed keywords nil to unit.
2018-09-14 14:50:11 +08:00
kennytm
07dc4b3759
Rollup merge of #53950 - michaelwoerister:more-lto-cli, r=alexcrichton
Allow for opting out of ThinLTO and clean up LTO related cli flag handling.

It turns out that there currently is no way to explicitly disable ThinLTO (except for the nightly-only `-Zthinlto` flag). This PR extends `-C lto` to take `yes` and `no` in addition to `thin` and `fat`. It should be backwards compatible.

It also cleans up how LTO mode selection is handled.

Note that merging the PR in the current state would make the new values for `-C lto` available on the stable channel. I think that would be fine but maybe some team should vote on it.
2018-09-14 00:46:45 +08:00
kenta7777
26dbf56196 Merge branch 'master' into kenta7777#53719 2018-09-12 21:36:31 +09:00
bors
6810f5286b Auto merge of #53793 - toidiu:ak-stabalize, r=nikomatsakis
stabilize outlives requirements

https://github.com/rust-lang/rust/issues/44493

r? @nikomatsakis
2018-09-12 11:27:48 +00:00
kennytm
6b55f04725
Rollup merge of #52514 - DiamondLovesYou:amdgpu-fixes, r=eddyb
Fix a few AMDGPU related issues

* AMDGPU ignores `noinline` and sadly doesn't clear the attribute when it slaps `alwaysinline` on everything,
* an AMDGPU related load bit range metadata assertion,
* I didn't enable the `amdgpu` component in the `librustc_llvm` build script,
* Add AMDGPU call abi info.
2018-09-12 12:17:22 +08:00
toidiu
731f4efae5 stabalize infer outlives requirements (RFC 2093).
Co-authored-by: nikomatsakis
2018-09-11 11:40:04 -04:00
kenta7777
a0e7b6bf6b renamed is_nil to is_unit 2018-09-11 23:17:35 +09:00
kenta7777
10b2083a6d Revert "renamed is_nil to is_unit"
This reverts commit 6f685ffad4.
2018-09-11 22:18:49 +09:00
Niko Matsakis
dd3cc9669a add the AscribeUserType statement kind
Make it have the semantics of subtype.
2018-09-10 08:22:31 -04:00
kenta7777
5c3ba4aa4f renamed mk_nil to mk_unit 2018-09-10 11:07:13 +09:00
kenta7777
6f685ffad4 renamed is_nil to is_unit 2018-09-10 10:45:16 +09:00
bors
df6ba0c4ac Auto merge of #53998 - eddyb:issue-53728, r=oli-obk
rustc_codegen_llvm: don't assume offsets are always aligned.

Fixes #53728 by taking into account not just overall type alignment and the field's alignment when determining whether a field is aligned or not ("packed"), but also the field's offset within the type.

Previously, rustc assumed that the offset was always at least as aligned as `min(struct.align, field.align)`. However, there's no real reason to have that assumption, and it obviously can't always be true after we implement `#[repr(align(N), pack(K))]`. There's also a case today where that assumption is not true, involving niche discriminants in enums:

Suppose that we have the code in #53728:
```Rust
#[repr(u16)]
enum DeviceKind {
    Nil = 0,
}

#[repr(packed)]
struct DeviceInfo {
    endianness: u8,
    device_kind: DeviceKind,
}

struct Wrapper {
    device_info: DeviceInfo,
    data: u32
}
```

Observe the layout of `Option<Wrapper>`. It has an alignment of 4 because of the `u32`. `device_info.device_kind` is a good niche field to use, which means the enum ends up with this layout:
```
size = 8
align = 4
fields = [
    { offset=1, type=u16 } // discriminant, .<Some>.device_info.device_kind
]
```

And here we have an discriminant with alignment 2 (`u16`) but offset 1.
2018-09-09 08:54:29 +00:00
bors
b24330fb7d Auto merge of #53705 - ms2300:tmp, r=oli-obk
#53576 Renaming TyAnon -> TyOpaque

Fixes #53576
2018-09-08 14:16:37 +00:00
Niko Matsakis
5aee959e9f make field always private, add From impls 2018-09-07 11:37:46 -04:00
Eduard-Mihai Burtescu
b9e7574bf2 rustc_codegen_llvm: don't assume offsets are always aligned. 2018-09-06 20:56:20 +03:00
bors
6e0f1cc158 Auto merge of #53962 - michaelwoerister:close-thinlto-file-descriptors, r=alexcrichton
ThinLTO: Don't keep files open after mmaping them.

Fixes #53947.

r? @alexcrichton
2018-09-05 20:52:42 +00:00
ms2300
6c14360c32 Changing TyAnon -> TyOpaque and relevant functions 2018-09-05 13:01:16 -06:00
bors
d8af8b66d9 Auto merge of #53878 - alexcrichton:wasm-atomics-feature, r=eddyb
rustc: Prepare the `atomics` feature for wasm

This commit adds a few changes for atomic instructions on the
`wasm32-unknown-unknown` target. Atomic instructions are not yet stable in
WebAssembly itself but there are multiple implementations and LLVM has support
for the proposed instruction set, so let's work on exposing it!

Here there are a few inclusions:

* The `atomics` feature was whitelisted for LLVM, allowing code in Rust to
  enable/disable/gate on this.

* The `singlethread` option is turned off for wasm when the `atomics` feature is
  enabled. This means that by default wasm won't be lowering with atomics, but
  when atomics are enabled globally we'll turn off single-threaded mode to
  actually codegen atomics. This probably isn't what we'll want in the long term
  but for now it should work.

* Finally the maximum atomic width is increased to 64 to reflect the current
  wasm spec.
2018-09-05 13:19:19 +00:00
Michael Woerister
fc47a92336 ThinLTO: Don't keep files open after mmaping them (because it's not needed). 2018-09-05 13:52:58 +02:00
Michael Woerister
24093a6bdb Allow for opting out of ThinLTO and clean up LTO related cli flag handling. 2018-09-05 12:52:17 +02:00
bors
0f063aef62 Auto merge of #53926 - japaric:arm-features, r=alexcrichton
whitelist some ARM features

required for rust-lang-nursery/stdsimd#557

r? @gnzlbg or @alexcrichton
2018-09-03 20:59:09 +00:00
Jorge Aparicio
bac0eb2f37 whitelist some ARM features 2018-09-03 16:52:43 +02:00
Michael Woerister
21d05f64aa incr.ThinLTO: Do some cleanup and add some logging. 2018-09-03 13:26:46 +02:00
Alex Crichton
fc497d0026 rustc: Prepare the atomics feature for wasm
This commit adds a few changes for atomic instructions on the
`wasm32-unknown-unknown` target. Atomic instructions are not yet stable in
WebAssembly itself but there are multiple implementations and LLVM has support
for the proposed instruction set, so let's work on exposing it!

Here there are a few inclusions:

* The `atomics` feature was whitelisted for LLVM, allowing code in Rust to
  enable/disable/gate on this.

* The `singlethread` option is turned off for wasm when the `atomics` feature is
  enabled. This means that by default wasm won't be lowering with atomics, but
  when atomics are enabled globally we'll turn off single-threaded mode to
  actually codegen atomics. This probably isn't what we'll want in the long term
  but for now it should work.

* Finally the maximum atomic width is increased to 64 to reflect the current
  wasm spec.
2018-08-31 22:47:10 -07:00
Michael Woerister
abd5cc3364 Always add all modules to the global ThinLTO module analysis when compiling incrementally. 2018-08-31 15:22:52 +02:00
Michael Woerister
64a738d8ce Support local ThinLTO with incremental compilation. 2018-08-31 15:22:52 +02:00
Michael Woerister
72c1993b8e Make codegen not be a query (since it's not a real query anyway). 2018-08-31 15:22:52 +02:00
Michael Woerister
d97d1e192b Persist ThinLTO import data in incr. comp. session directory. 2018-08-31 15:22:52 +02:00
Michael Woerister
2e587df6e2 Provide a way of accessing the ThinLTO module import map in rustc. 2018-08-31 15:22:52 +02:00
Pietro Albini
ba832707cf
Rollup merge of #53472 - eddyb:fx-pls, r=pnkfelix
Use FxHash{Map,Set} instead of the default Hash{Map,Set} everywhere in rustc.

Most of the compiler uses the `Fx` hasher but some places ended up with the default one.
2018-08-30 20:15:29 +02:00
bors
9d69e81e9b Auto merge of #53642 - alexcrichton:fix-target-cpu-native, r=arielb1
Fix warnings about the `native` target-cpu

This fixes a regression from #53031 where specifying `-C target-cpu=native` is
printing a lot of warnings from LLVM about `native` being an unknown CPU. It
turns out that `native` is indeed an unknown CPU and we have to perform a
mapping to an actual CPU name, but this mapping is only performed in one
location rather than all locations we inform LLVM about the target CPU.

This commit centralizes the mapping of `native` to LLVM's value of the native
CPU, ensuring that all locations we inform LLVM about the `target-cpu` it's
never `native`.

Closes #53322
2018-08-29 02:08:02 +00:00
bors
f1d02c3073 Auto merge of #53671 - RalfJung:miri-refactor, r=oli-obk
Miri engine cleanup

* Unify the two maps in memory to store the allocation and its kind together.
* Share the handling of statics between CTFE and miri: The miri engine always
      uses "lazy" `AllocType::Static` when encountering a static.  Acessing that
      static invokes CTFE (no matter the machine).  The machine only has any
      influence when writing to a static, which CTFE outright rejects (but miri
      makes a copy-on-write).
* Add an `AllocId` to by-ref consts so miri can use them as operands without
      making copies.
* Move responsibilities around for the `eval_fn_call` machine hook: The hook
      just has to find the MIR (or entirely take care of everything); pushing the
      new stack frame is taken care of by the miri engine.
* Expose the intrinsics and lang items implemented by CTFE so miri does not
      have to reimplement them.
* Allow Machine to hook into foreign statics (used by miri to get rid of some other hacks).
* Clean up function calling.
* Switch const sanity check to work on operands, not mplaces.
* Move const_eval out of rustc_mir::interpret, to make sure that it does not access private implementation details.

In particular, we can finally make `eval_operand` take `&self`. :-)

Should be merged after https://github.com/rust-lang/rust/pull/53609, across which I will rebase.
2018-08-29 00:02:37 +00:00
Alex Crichton
1fd45a13de Fix warnings about the native target-cpu
This fixes a regression from #53031 where specifying `-C target-cpu=native` is
printing a lot of warnings from LLVM about `native` being an unknown CPU. It
turns out that `native` is indeed an unknown CPU and we have to perform a
mapping to an actual CPU name, but this mapping is only performed in one
location rather than all locations we inform LLVM about the target CPU.

This commit centralizes the mapping of `native` to LLVM's value of the native
CPU, ensuring that all locations we inform LLVM about the `target-cpu` it's
never `native`.

Closes #53322
2018-08-28 13:32:11 -07:00