Commit Graph

481 Commits

Author SHA1 Message Date
Santiago Pastorino
ba1e13fa66
Revert "structural_match: non-structural-match ty closures"
Reverts #73353
2021-07-18 09:30:10 -03:00
bors
c78ebb7bdc Auto merge of #87123 - RalfJung:miri-provenance-overhaul, r=oli-obk
CTFE/Miri engine Pointer type overhaul

This fixes the long-standing problem that we are using `Scalar` as a type to represent pointers that might be integer values (since they point to a ZST). The main problem is that with int-to-ptr casts, there are multiple ways to represent the same pointer as a `Scalar` and it is unclear if "normalization" (i.e., the cast) already happened or not. This leads to ugly methods like `force_mplace_ptr` and `force_op_ptr`.
Another problem this solves is that in Miri, it would make a lot more sense to have the `Pointer::offset` field represent the full absolute address (instead of being relative to the `AllocId`). This means we can do ptr-to-int casts without access to any machine state, and it means that the overflow checks on pointer arithmetic are (finally!) accurate.

To solve this, the `Pointer` type is made entirely parametric over the provenance, so that we can use `Pointer<AllocId>` inside `Scalar` but use `Pointer<Option<AllocId>>` when accessing memory (where `None` represents the case that we could not figure out an `AllocId`; in that case the `offset` is an absolute address). Moreover, the `Provenance` trait determines if a pointer with a given provenance can be cast to an integer by simply dropping the provenance.

I hope this can be read commit-by-commit, but the first commit does the bulk of the work. It introduces some FIXMEs that are resolved later.
Fixes https://github.com/rust-lang/miri/issues/841
Miri PR: https://github.com/rust-lang/miri/pull/1851
r? `@oli-obk`
2021-07-17 15:26:27 +00:00
bors
f502bd3abd Auto merge of #86761 - Alexhuszagh:master, r=estebank
Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm.

# Summary

Rust, although it implements a correct float parser, has major performance issues in float parsing. Even for common floats, the performance can be 3-10x [slower](https://arxiv.org/pdf/2101.11408.pdf) than external libraries such as [lexical](https://github.com/Alexhuszagh/rust-lexical) and [fast-float-rust](https://github.com/aldanor/fast-float-rust).

Recently, major advances in float-parsing algorithms have been developed by Daniel Lemire, along with others, and implement a fast, performant, and correct float parser, with speeds up to 1200 MiB/s on Apple's M1 architecture for the [canada](0e2b5d163d/data/canada.txt) dataset, 10x faster than Rust's 130 MiB/s.

In addition, [edge-cases](https://github.com/rust-lang/rust/issues/85234) in Rust's [dec2flt](868c702d0c/library/core/src/num/dec2flt) algorithm can lead to over a 1600x slowdown relative to efficient algorithms. This is due to the use of Clinger's correct, but slow [AlgorithmM and Bellepheron](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.45.4152&rep=rep1&type=pdf), which have been improved by faster big-integer algorithms and the Eisel-Lemire algorithm, respectively.

Finally, this algorithm provides substantial improvements in the number of floats the Rust core library can parse. Denormal floats with a large number of digits cannot be parsed, due to use of the `Big32x40`, which simply does not have enough digits to round a float correctly. Using a custom decimal class, with much simpler logic, we can parse all valid decimal strings of any digit count.

```rust
// Issue in Rust's dec2fly.
"2.47032822920623272088284396434110686182e-324".parse::<f64>();   // Err(ParseFloatError { kind: Invalid })
```

# Solution

This pull request implements the Eisel-Lemire algorithm, modified from [fast-float-rust](https://github.com/aldanor/fast-float-rust) (which is licensed under Apache 2.0/MIT), along with numerous modifications to make it more amenable to inclusion in the Rust core library. The following describes both features in fast-float-rust and improvements in fast-float-rust for inclusion in core.

**Documentation**

Extensive documentation has been added to ensure the code base may be maintained by others, which explains the algorithms as well as various associated constants and routines. For example, two seemingly magical constants include documentation to describe how they were derived as follows:

```rust
    // Round-to-even only happens for negative values of q
    // when q ≥ −4 in the 64-bit case and when q ≥ −17 in
    // the 32-bitcase.
    //
    // When q ≥ 0,we have that 5^q ≤ 2m+1. In the 64-bit case,we
    // have 5^q ≤ 2m+1 ≤ 2^54 or q ≤ 23. In the 32-bit case,we have
    // 5^q ≤ 2m+1 ≤ 2^25 or q ≤ 10.
    //
    // When q < 0, we have w ≥ (2m+1)×5^−q. We must have that w < 2^64
    // so (2m+1)×5^−q < 2^64. We have that 2m+1 > 2^53 (64-bit case)
    // or 2m+1 > 2^24 (32-bit case). Hence,we must have 2^53×5^−q < 2^64
    // (64-bit) and 2^24×5^−q < 2^64 (32-bit). Hence we have 5^−q < 2^11
    // or q ≥ −4 (64-bit case) and 5^−q < 2^40 or q ≥ −17 (32-bitcase).
    //
    // Thus we have that we only need to round ties to even when
    // we have that q ∈ [−4,23](in the 64-bit case) or q∈[−17,10]
    // (in the 32-bit case). In both cases,the power of five(5^|q|)
    // fits in a 64-bit word.
    const MIN_EXPONENT_ROUND_TO_EVEN: i32;
    const MAX_EXPONENT_ROUND_TO_EVEN: i32;
```

This ensures maintainability of the code base.

**Improvements for Disguised Fast-Path Cases**

The fast path in float parsing algorithms attempts to use native, machine floats to represent both the significant digits and the exponent, which is only possible if both can be exactly represented without rounding. In practice, this means that the significant digits must be 53-bits or less and the then exponent must be in the range `[-22, 22]` (for an f64). This is similar to the existing dec2flt implementation.

However, disguised fast-path cases exist, where there are few significant digits and an exponent above the valid range, such as `1.23e25`. In this case, powers-of-10 may be shifted from the exponent to the significant digits, discussed at length in https://github.com/rust-lang/rust/issues/85198.

**Digit Parsing Improvements**

Typically, integers are parsed from string 1-at-a-time, requiring unnecessary multiplications which can slow down parsing. An approach to parse 8 digits at a time using only 3 multiplications is described in length [here](https://johnnylee-sde.github.io/Fast-numeric-string-to-int/). This leads to significant performance improvements, and is implemented for both big and little-endian systems.

**Unsafe Changes**

Relative to fast-float-rust, this library makes less use of unsafe functionality and clearly documents it. This includes the refactoring and documentation of numerous unsafe methods undesirably marked as safe. The original code would look something like this, which is deceptively marked as safe for unsafe functionality.

```rust
impl AsciiStr {
    #[inline]
    pub fn step_by(&mut self, n: usize) -> &mut Self {
        unsafe { self.ptr = self.ptr.add(n) };
        self
    }
}

...

#[inline]
fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 {
    // the first character is 'e'/'E' and scientific mode is enabled
    let start = *s;
    s.step();
    ...
}
```

The new code clearly documents safety concerns, and does not mark unsafe functionality as safe, leading to better safety guarantees.

```rust
impl AsciiStr {
    /// Advance the view by n, advancing it in-place to (n..).
    pub unsafe fn step_by(&mut self, n: usize) -> &mut Self {
        // SAFETY: same as step_by, safe as long n is less than the buffer length
        self.ptr = unsafe { self.ptr.add(n) };
        self
    }
}

...

/// Parse the scientific notation component of a float.
fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 {
    let start = *s;
    // SAFETY: the first character is 'e'/'E' and scientific mode is enabled
    unsafe {
        s.step();
    }
    ...
}
```

This allows us to trivially demonstrate the new implementation of dec2flt is safe.

**Inline Annotations Have Been Removed**

In the previous implementation of dec2flt, inline annotations exist practically nowhere in the entire module. Therefore, these annotations have been removed, which mostly does not impact [performance](https://github.com/aldanor/fast-float-rust/issues/15#issuecomment-864485157).

**Fixed Correctness Tests**

Numerous compile errors in `src/etc/test-float-parse` were present, due to deprecation of `time.clock()`, as well as the crate dependencies with `rand`. The tests have therefore been reworked as a [crate](https://github.com/Alexhuszagh/rust/tree/master/src/etc/test-float-parse), and any errors in `runtests.py` have been patched.

**Undefined Behavior**

An implementation of `check_len` which relied on undefined behavior (in fast-float-rust) has been refactored, to ensure that the behavior is well-defined. The original code is as follows:

```rust
    #[inline]
    pub fn check_len(&self, n: usize) -> bool {
        unsafe { self.ptr.add(n) <= self.end }
    }
```

And the new implementation is as follows:

```rust
    /// Check if the slice at least `n` length.
    fn check_len(&self, n: usize) -> bool {
        n <= self.as_ref().len()
    }
```

Note that this has since been fixed in [fast-float-rust](https://github.com/aldanor/fast-float-rust/pull/29).

**Inferring Binary Exponents**

Rather than explicitly store binary exponents, this new implementation infers them from the decimal exponent, reducing the amount of static storage required. This removes the requirement to store [611 i16s](868c702d0c/library/core/src/num/dec2flt/table.rs (L8)).

# Code Size

The code size, for all optimizations, does not considerably change relative to before for stripped builds, however it is **significantly** smaller prior to stripping the resulting binaries. These binary sizes were calculated on x86_64-unknown-linux-gnu.

**new**

Using rustc version 1.55.0-dev.

opt-level|size|size(stripped)
|:-:|:-:|:-:|
0|400k|300K
1|396k|292K
2|392k|292K
3|392k|296K
s|396k|292K
z|396k|292K

**old**

Using rustc version 1.53.0-nightly.

opt-level|size|size(stripped)
|:-:|:-:|:-:|
0|3.2M|304K
1|3.2M|292K
2|3.1M|284K
3|3.1M|284K
s|3.1M|284K
z|3.1M|284K

# Correctness

The dec2flt implementation passes all of Rust's unittests and comprehensive float parsing tests, along with numerous other tests such as Nigel Toa's comprehensive float [tests](https://github.com/nigeltao/parse-number-fxx-test-data) and Hrvoje Abraham  [strtod_tests](https://github.com/ahrvoje/numerics/blob/master/strtod/strtod_tests.toml). Therefore, it is unlikely that this algorithm will incorrectly round parsed floats.

# Issues Addressed

This will fix and close the following issues:

- resolves #85198
- resolves #85214
- resolves #85234
- fixes #31407
- fixes #31109
- fixes #53015
- resolves #68396
- closes https://github.com/aldanor/fast-float-rust/issues/15
2021-07-17 12:56:22 +00:00
Alex Huszagh
8752b40369 Changed dec2flt to use the Eisel-Lemire algorithm.
Implementation is based off fast-float-rust, with a few notable changes.

- Some unsafe methods have been removed.
- Safe methods with inherently unsafe functionality have been removed.
- All unsafe functionality is documented and provably safe.
- Extensive documentation has been added for simpler maintenance.
- Inline annotations on internal routines has been removed.
- Fixed Python errors in src/etc/test-float-parse/runtests.py.
- Updated test-float-parse to be a library, to avoid missing rand dependency.
- Added regression tests for #31109 and #31407 in core tests.
- Added regression tests for #31109 and #31407 in ui tests.
- Use the existing slice primitive to simplify shared dec2flt methods
- Remove Miri ignores from dec2flt, due to faster parsing times.

- resolves #85198
- resolves #85214
- resolves #85234
- fixes #31407
- fixes #31109
- fixes #53015
- resolves #68396
- closes https://github.com/aldanor/fast-float-rust/issues/15
2021-07-17 00:30:34 -05:00
Ralf Jung
7c720ce612 get rid of incorrect erase_for_fmt 2021-07-16 10:09:56 +02:00
Cameron Steffen
1537cd4fb1 Remove refs from pat slices 2021-07-15 16:09:57 -05:00
Ralf Jung
626605cea0 consistently treat None-tagged pointers as ints; get rid of some deprecated Scalar methods 2021-07-14 18:17:49 +02:00
bors
1f0db5e0a3 Auto merge of #86665 - FabianWolff:layout-field-thir-unsafeck, r=oli-obk
Implement Mutation- and BorrowOfLayoutConstrainedField in thir-unsafeck

Since nobody has so far claimed Mutation- and BorrowOfLayoutConstrainedField in rust-lang/project-thir-unsafeck#7, I have taken the liberty of implementing them in thir-unsafeck.

r? `@LeSeulArtichaut`
2021-07-13 04:38:39 +00:00
Fabian Wolff
79f0743b6f Fix ICE with unsized type in const pattern 2021-07-11 19:16:26 +02:00
Fabian Wolff
b0888614f1 Implement Mutation- and BorrowOfLayoutConstrainedField in thir-unsafeck 2021-07-10 16:33:00 +02:00
Ralf Jung
5f0dd6db94 remove const_raw_ptr_to_usize_cast feature 2021-07-10 12:08:58 +02:00
bors
240ff4c4a0 Auto merge of #85263 - Smittyvb:thir-unsafeck-union-field, r=oli-obk
Check for union field accesses in THIR unsafeck

see also #85259, #83129, https://github.com/rust-lang/project-thir-unsafeck/issues/7

r? `@LeSeulArtichaut`
2021-07-09 20:56:07 +00:00
Smitty
b86ed4a425 panic when trying to destructure union as enum 2021-07-09 15:22:12 -04:00
Smitty
74d0d74dae Check for union field accesses in THIR unsafeck 2021-07-09 13:51:28 -04:00
lrh2000
cf5eda1b4d Add a query for CapturedPlace::to_symbol 2021-07-10 00:00:25 +08:00
lrh2000
cda90f5541 Store names of captured variables in optimized_mir
- Closures in external crates may get compiled in because of
  monomorphization. We should store names of captured variables
  in `optimized_mir`, so that they are written into the metadata
  file and we can use them to generate debuginfo.

- If there are breakpoints inside closures, the names of captured
  variables stored in `optimized_mir` can be used to print them.
  Now the name is more precise when disjoint fields are captured.
2021-07-09 23:09:48 +08:00
Fabian Wolff
d019c71df9 Fix double warning about illegal floating-point literal pattern 2021-07-05 18:10:34 +02:00
Aman Arora
10a37bf847 fixup! Editon 2021 enables precise capture 2021-06-27 21:46:55 -04:00
Aman Arora
b89ea96660 Editon 2021 enables precise capture 2021-06-27 21:44:33 -04:00
bors
f1e691da2e Auto merge of #86138 - FabianWolff:issue-85871, r=nikomatsakis
Check whether the closure's owner is an ADT in thir-unsafeck

This pull request fixes #85871. The code in `rustc_mir_build/src/check_unsafety.rs` incorrectly assumes that a closure's owner always has a body, but only functions, closures, and constants have bodies, whereas a closure can also appear inside a struct or enum:
```rust
struct S {
    arr: [(); match || 1 { _ => 42 }]
}

enum E {
    A([(); { || 1; 42 }])
}
```
This pull request fixes the resulting ICE by checking whether the closure's owner is an ADT and only deferring to `thir_check_unsafety(owner)` if it isn't.
2021-06-23 21:35:46 +00:00
Yuki Okushi
8ec4e7dfdd
Rollup merge of #86517 - camsteffen:unused-unsafe-async, r=LeSeulArtichaut
Fix `unused_unsafe` around `await`

Enables `unused_unsafe` lint for `unsafe { future.await }`.

The existing test for this is `unsafe { println!() }`, so I assume that `println!` used to contain compiler-generated unsafe but this is no longer true, and so the existing test is broken. I replaced the test with `unsafe { ...await }`. I believe `await` is currently the only instance of compiler-generated unsafe.

Reverts some parts of #85421, but the issue predates that PR.
2021-06-22 20:01:05 +09:00
Cameron Steffen
b07bb6d698 Fix unused_unsafe with compiler-generated unsafe 2021-06-21 17:25:45 -05:00
bors
150fad30ea Auto merge of #86460 - JohnTitor:use-static-in-pattern-err, r=oli-obk
Refactor `PatternError` structure

Now we emit the `StaticInPattern` error precisely.
Fixes #68395
r? `@oli-obk`
2021-06-19 19:46:02 +00:00
bors
9cf05f3614 Auto merge of #86378 - Smittyvb:thir-walker-pat, r=LeSeulArtichaut
Add pattern walking support to THIR walker

Suggested in https://github.com/rust-lang/rust/pull/85263#issuecomment-861906730, this splits off the support for pattern walking in THIR from #85263. This has no observable effect on THIR unsafety checking, since it is not currently possible to trigger unsafety from the THIR checker using the additional patterns or constants that are now walked. THIR patterns are walked in source code order.

r? `@LeSeulArtichaut`
2021-06-19 05:44:11 +00:00
Yuki Okushi
e44e65e888
Assert is_associated_const when resolving 2021-06-19 13:55:24 +09:00
Yuki Okushi
bc243a7f55
Refactor PatternError structure 2021-06-19 11:47:15 +09:00
bors
312b894cc1 Auto merge of #85421 - Smittyvb:rm_pushpop_unsafe, r=matthewjasper
Remove some last remants of {push,pop}_unsafe!

These macros have already been removed, but there was still some code handling these macros. That code is now removed.
2021-06-18 14:17:53 +00:00
Smitty
281dd6d6e0 Explicitly write out all fields 2021-06-17 10:17:35 -04:00
Smitty
1d5accabf1 simplify borrowing 2021-06-17 10:15:02 -04:00
Smitty
210e46bf24 Add pattern walking support to THIR walker 2021-06-16 16:36:43 -04:00
LeSeulArtichaut
5e802e5e97 Box ExprKind::Adt 2021-06-13 17:03:11 +02:00
Fabian Wolff
433c1aec21 Check whether the closure's owner has a body before deferring to it in thir-unsafeck 2021-06-08 22:09:35 +02:00
Smitty
45c55540a8 Remove some last remants of {push,pop}_unsafe!
These macros have already been removed, but there was still some code
handling these macros. That code is now removed.
2021-06-06 17:04:03 -04:00
marcusdunn
43d8854b56 removed unneeded brackets on import 2021-06-04 09:42:50 -07:00
marcusdunn
21dee3cbf8 removed conditional check on bindings_after_at and resulting dead code 2021-06-04 09:41:55 -07:00
Yuki Okushi
36f1ed6de2
Rollup merge of #85850 - bjorn3:less_feature_gates, r=jyn514
Remove unused feature gates

The first commit removes a usage of a feature gate, but I don't expect it to be controversial as the feature gate was only used to workaround a limitation of rust in the past. (closures never being `Clone`)

The second commit uses `#[allow_internal_unstable]` to avoid leaking the `trusted_step` feature gate usage from inside the index newtype macro. It didn't work for the `min_specialization` feature gate though.

The third commit removes (almost) all feature gates from the compiler that weren't used anyway.
2021-06-04 13:42:54 +09:00
bors
a93699f20a Auto merge of #85952 - JohnTitor:rollup-r00gu9q, r=JohnTitor
Rollup of 13 pull requests

Successful merges:

 - #83362 (Stabilize `vecdeque_binary_search`)
 - #85706 (Turn off frame pointer elimination on all Apple platforms. )
 - #85724 (Fix issue 85435 by restricting Fake Read precision)
 - #85852 (Clarify meaning of MachineApplicable suggestions.)
 - #85877 (Intra doc link-ify a reference to a function)
 - #85880 (convert assertion on rvalue::threadlocalref to delay bug)
 - #85896 (Add test for forward declared const param defaults)
 - #85897 (Update I-unsound label for triagebot)
 - #85900 (Use pattern matching instead of checking lengths explicitly)
 - #85911 (Avoid a clone of output_filenames.)
 - #85926 (Update cargo)
 - #85934 (Add `Ty::is_union` predicate)
 - #85935 (Validate type of locals used as indices)

Failed merges:

r? `@ghost`
`@rustbot` modify labels: rollup
2021-06-03 08:02:39 +00:00
Yuki Okushi
34f1275880
Rollup merge of #85724 - sexxi-goose:rox-fix-issue-85435, r=nikomatsakis
Fix issue 85435 by restricting Fake Read precision

This PR fixes the root bug of issue #85435 by restricting Fake Read precision in closures and removing the feature gate introduced in PR #85564. More info [here](https://github.com/rust-lang/rust/issues/85561#issuecomment-846223784) and [here](https://github.com/rust-lang/rust/issues/85561#issuecomment-847270533).

Closes #85561

r? ``@nikomatsakis``
2021-06-03 14:35:29 +09:00
bors
016e9b5e33 Auto merge of #84988 - alexcrichton:safe-target-feature-wasm, r=joshtriplett
rustc: Allow safe #[target_feature] on wasm

This commit updates the compiler's handling of the `#[target_feature]`
attribute when applied to functions on WebAssembly-based targets. The
compiler in general requires that any functions with `#[target_feature]`
are marked as `unsafe` as well, but this commit relaxes the restriction
for WebAssembly targets where the attribute can be applied to safe
functions as well.

The reason this is done is that the motivation for this feature of the
compiler is not applicable for WebAssembly targets. In general the
`#[target_feature]` attribute is used to enhance target CPU features
enabled beyond the basic level for the rest of the compilation. If done
improperly this means that your program could execute an instruction
that the CPU you happen to be running on does not understand. This is
considered undefined behavior where it is unknown what will happen (e.g.
it's not a deterministic `SIGILL`).

For WebAssembly, however, the target is different. It is not possible
for a running WebAssembly program to execute an instruction that the
engine does not understand. If this were the case then the program would
not have validated in the first place and would not run at all. Even if
this were allowed in some hypothetical future where engines have some
form of runtime feature detection (which they do not right now) any
implementation of such a feature would generate a trap if a module
attempts to execute an instruction the module does not understand. This
deterministic trap behavior would still not fall into the category of
undefined behavior because the trap is deterministic.

For these reasons the `#[target_feature]` attribute is now allowed on
safe functions, but only for WebAssembly targets. This notably enables
the wasm-SIMD intrinsics proposed for stabilization in #74372 to be
marked as safe generally instead of today where they're all `unsafe` due
to the historical implementation of `#[target_feature]` in the compiler.
2021-06-03 05:12:31 +00:00
bjorn3
312f964478 Remove unused feature gates 2021-05-31 13:55:43 +02:00
bors
9a72afa7dd Auto merge of #83772 - jhpratt:revamp-step-trait, r=Mark-Simulacrum
Make `Step` trait safe to implement

This PR makes a few modifications to the `Step` trait that I believe better position it for stabilization in the short term. In particular,

1. `unsafe trait TrustedStep` is introduced, indicating that the implementation of `Step` for a given type upholds all stated invariants (which have remained unchanged). This is gated behind a new `trusted_step` feature, as stabilization is realistically blocked on min_specialization.
2. The `Step` trait is internally specialized on the `TrustedStep` trait, which avoids a serious performance regression.
3. `TrustedLen` is implemented for `T: TrustedStep` as the latter's invariants subsume the former's.
4. The `Step` trait is no longer `unsafe`, as the invariants must not be relied upon by unsafe code (unless the type implements `TrustedStep`).
5. `TrustedStep` is implemented for all types that implement `Step` in the standard library and compiler.
6. The `step_trait_ext` feature is merged into the `step_trait` feature. I was unable to find any reasoning for the features being split; the `_unchecked` methods need not necessarily be stabilized at the same time, but I think it is useful to have them under the same feature flag.

All existing implementations of `Step` will be broken, as it is not possible to `unsafe impl` a safe trait. Given this trait only exists on nightly, I feel this breakage is acceptable. The blanket `impl<T: Step> TrustedLen for T` will likely cause some minor breakage, but this should be covered by the equivalent impl for `TrustedStep`.

Hopefully these changes are sufficient to place `Step` in decent position for stabilization, which would allow user-defined types to be used with `a..b` syntax.
2021-05-30 01:21:39 +00:00
Alex Crichton
7fed92b3a4 rustc: Allow safe #[target_feature] on wasm
This commit updates the compiler's handling of the `#[target_feature]`
attribute when applied to functions on WebAssembly-based targets. The
compiler in general requires that any functions with `#[target_feature]`
are marked as `unsafe` as well, but this commit relaxes the restriction
for WebAssembly targets where the attribute can be applied to safe
functions as well.

The reason this is done is that the motivation for this feature of the
compiler is not applicable for WebAssembly targets. In general the
`#[target_feature]` attribute is used to enhance target CPU features
enabled beyond the basic level for the rest of the compilation. If done
improperly this means that your program could execute an instruction
that the CPU you happen to be running on does not understand. This is
considered undefined behavior where it is unknown what will happen (e.g.
it's not a deterministic `SIGILL`).

For WebAssembly, however, the target is different. It is not possible
for a running WebAssembly program to execute an instruction that the
engine does not understand. If this were the case then the program would
not have validated in the first place and would not run at all. Even if
this were allowed in some hypothetical future where engines have some
form of runtime feature detection (which they do not right now) any
implementation of such a feature would generate a trap if a module
attempts to execute an instruction the module does not understand. This
deterministic trap behavior would still not fall into the category of
undefined behavior because the trap is deterministic.

For these reasons the `#[target_feature]` attribute is now allowed on
safe functions, but only for WebAssembly targets. This notably enables
the wasm-SIMD intrinsics proposed for stabilization in #74372 to be
marked as safe generally instead of today where they're all `unsafe` due
to the historical implementation of `#[target_feature]` in the compiler.
2021-05-28 12:57:35 -07:00
Roxane
382338fe75 Remove feature gate 2021-05-27 17:58:35 -04:00
LeSeulArtichaut
6c4f40dee1 Make closures inherit their parent's "safety context" 2021-05-27 16:50:48 +02:00
Dylan DPC
9d4a6449db
Rollup merge of #85564 - pnkfelix:issue-85435-readd-capture-disjoint-fields-gate, r=nikomatsakis
readd capture disjoint fields gate

This readds a feature gate guard that was added in PR #83521. (Basically, there were unintended consequences to the code exposed by removing the feature gate guard.)

The root bug still remains to be resolved, as discussed in issue #85561. This is just a band-aid suitable for a beta backport.

Cc issue #85435

Note that the latter issue is unfixed until we backport this (or another fix) to 1.53 beta
2021-05-27 03:02:08 +02:00
Jacob Pratt
bc2f0fb5a9
Specialize implementations
Implementations in stdlib are now optimized as they were before.
2021-05-26 18:07:09 -04:00
LeSeulArtichaut
f7916b4c9e Fix unused_unsafe in THIR unsafeck 2021-05-25 20:11:29 +02:00
LeSeulArtichaut
b0835410bb Handle unsafe_op_in_unsafe_fn properly in THIR unsafeck 2021-05-25 20:11:29 +02:00
Guillaume Gomez
ad72247833
Rollup merge of #85605 - ptrojahn:closure_struct, r=matthewjasper
Replace Local::new(1) with CAPTURE_STRUCT_LOCAL
2021-05-25 13:05:14 +02:00
bors
a7890c7952 Auto merge of #84985 - pietroalbini:bootstrap-1.54, r=Mark-Simulacrum
Bump bootstrap compiler to beta 1.53.0

This PR bumps the bootstrap compiler to version 1.53.0 beta, as part of our usual release process (this was supposed to be Wednesday's step, but creating the beta release took longer than expected).

The PR also includes the "Bootstrap: skip rustdoc fingerprint for building docs" commit, see the reasoning [on Zulip](https://zulip-archive.rust-lang.org/241545trelease/88450153betabootstrap.html).

r? `@Mark-Simulacrum`
2021-05-25 05:48:00 +00:00
bors
d568d63b1f Auto merge of #85273 - LeSeulArtichaut:thir-query, r=nikomatsakis
Make building THIR a stealable query

This PR creates a stealable `thir_body` query so that we can build the THIR only once for THIR unsafeck and MIR build.

Blocked on #83842.
r? `@nikomatsakis`
2021-05-25 03:07:03 +00:00
Pietro Albini
9e22b844dd remove cfg(bootstrap) 2021-05-24 11:07:48 -04:00
LeSeulArtichaut
af3d9a3aa3 Make thir_check_unsafety itself responsible for checking gate 2021-05-24 15:09:33 +02:00
LeSeulArtichaut
13e7b237fd Add comments about stealing THIR in mir_build 2021-05-24 15:05:20 +02:00
LeSeulArtichaut
3559565e07 Replace more "NULL" with "null" 2021-05-24 12:59:33 +02:00
Paul Trojahn
0a80cc4d83 Replace Local::new(1) with CAPTURE_STRUCT_LOCAL 2021-05-23 18:36:23 +02:00
Ralf Jung
585141b219 support creating mutable allocations from byte slices 2021-05-23 12:37:16 +02:00
LeSeulArtichaut
3f31044d90 Handle typeck errors properly 2021-05-22 16:21:36 +02:00
LeSeulArtichaut
6dfdea9800 Make the THIR unsafeck use the thir_body query 2021-05-22 16:21:33 +02:00
LeSeulArtichaut
6f64eb1fe6 Make THIR building a stealable query 2021-05-22 14:36:22 +02:00
LeSeulArtichaut
bd80018159 Move THIR structure definitions to rustc_middle 2021-05-22 14:36:22 +02:00
Felix S. Klock II
1f130fbff8 Revert portion of PR #83521 that injected issue #85435 (and thus exposed underlying issue #85561). 2021-05-21 14:55:09 -04:00
LeSeulArtichaut
0e1afc4501 Check for use of mutable/extern statics in THIR unsafeck 2021-05-21 19:51:53 +02:00
LeSeulArtichaut
6b327aaa08 Check for ptr-to-int casts in const functions in THIR unsafeck 2021-05-21 18:31:44 +02:00
LeSeulArtichaut
592fecbafb Check for initialization of layout-restricted types 2021-05-21 18:29:51 +02:00
LeSeulArtichaut
d7787bbaef Check for calls to functions with #[target_feature] in THIR unsafeck 2021-05-20 00:06:32 +02:00
LeSeulArtichaut
27fe959c2c Check for raw pointer dereference in THIR unsafeck 2021-05-20 00:01:05 +02:00
bors
f94942d842 Auto merge of #83842 - LeSeulArtichaut:thir-vec, r=nikomatsakis
Store THIR in `IndexVec`s instead of an `Arena`

This is a necessary step to store the THIR in a query: #85273. See [relevant discussion on Zulip](https://rust-lang.zulipchat.com/#narrow/stream/278509-project-thir-unsafeck/topic/THIR-dependent.20queries.20design).

r? `@ghost` cc `@cjgillot` `@nikomatsakis`
2021-05-19 18:41:23 +00:00
LeSeulArtichaut
7093a21e27 Adapt the THIR visitor to the vec-stored THIR 2021-05-19 16:03:41 +02:00
LeSeulArtichaut
dc3eabd487 Store THIR in IndexVecs instead of an Arena 2021-05-19 16:03:35 +02:00
LeSeulArtichaut
62044b2fab Remove remnants of BorrowOfPackedField 2021-05-17 19:32:58 +02:00
Smitty
116bc6dd76 Check for inline assembly in THIR unsafeck 2021-05-14 09:03:30 -04:00
bors
69b352ef77 Auto merge of #85233 - FabianWolff:issue-85227, r=petrochenkov
Improve error message for non-exhaustive matches on non-exhaustive enums

This pull request fixes #85227. For an enum marked with `#[non_exhaustive]` and not defined in the current crate, the error message for non-exhaustive matches now mentions the fact that the enum is marked as non-exhaustive:
```
error[E0004]: non-exhaustive patterns: `_` not covered
  --> main.rs:12:11
   |
12 |     match e {
   |           ^ pattern `_` not covered
   |
   = help: ensure that all possible cases are being handled, possibly by adding wildcards or more match arms
   = note: the matched value is of type `E`, which is marked as non-exhaustive
```
2021-05-14 06:53:45 +00:00
bors
754d17121d Auto merge of #85195 - Mark-Simulacrum:variant-by-idx, r=petrochenkov
Store VariantIdx to distinguish enum variants

This saves ~24% of the instructions on the match-stress-enum benchmark, but I'm not 100% sure that this is OK - if we ever compare two constructors across enums (e.g., a Result and an Option), then this is obviously insufficient; I can experiment with continuing to store the DefId for comparison purposes in that case.
2021-05-14 00:59:01 +00:00
Fabian Wolff
57291b8c5e Improve error message for non-exhaustive matches on non-exhaustive enums 2021-05-12 19:25:12 +02:00
Mark Rousskov
e400595190 Store VariantIdx to distinguish enum variants
This saves ~24% of the instructions on the match-stress-enum benchmark.
2021-05-11 15:44:56 -04:00
LeSeulArtichaut
985fb4caa0 Add helper for switching safety contexts 2021-05-11 20:35:44 +02:00
LeSeulArtichaut
29780f43e2 Introduce the (WIP) THIR unsafety checker 2021-05-11 15:33:00 +02:00
LeSeulArtichaut
d956122f7e [WIP] Create a Visitor for the THIR 2021-05-11 15:33:00 +02:00
bors
b56b175c6c Auto merge of #84310 - RalfJung:const-fn-feature-flags, r=oli-obk
further split up const_fn feature flag

This continues the work on splitting up `const_fn` into separate feature flags:
* `const_fn_trait_bound` for `const fn` with trait bounds
* `const_fn_unsize` for unsizing coercions in `const fn` (looks like only `dyn` unsizing is still guarded here)

I don't know if there are even any things left that `const_fn` guards... at least libcore and liballoc do not need it any more.

`@oli-obk` are you currently able to do reviews?
2021-04-24 23:16:03 +00:00
bors
b2c20b51ed Auto merge of #84295 - richkadel:continue-coverage, r=tmandry
Add coverage to continue statements

`continue` statements were missing coverage. This was particularly
noticeable in a match pattern that contained only a `continue`
statement, leaving the branch appear uncounted. This PR addresses the
problem and adds tests to prove it.

r? `@tmandry`
cc: `@wesleywiser`
2021-04-20 03:08:24 +00:00
klensy
f43ee8ebf6 fix few typos 2021-04-19 15:57:08 +03:00
Ralf Jung
bd9556956a fix feature use in rustc libs 2021-04-18 22:05:45 +02:00
Rich Kadel
d1d7fb1ae5 Only generate dummy assign when instrumenting coverage
And make the LocalDecl internal, to avoid needing to declare storage.
(For multiple `continue` stateuemtns, it must also be mutable.)
2021-04-18 12:09:14 -07:00
Rich Kadel
448e52d97c Add coverage to continue statements
`continue` statements were missing coverage. This was particularly
noticeable in a match pattern that contained only a `continue`
statement, leaving the branch appear uncounted. This PR addresses the
problem and adds tests to prove it.
2021-04-18 03:11:25 -07:00
katelyn a. martin
3e16d233d8 move new c abi abort behavior behind feature gate
### Background

    In #76570, new ABI strings including `C-unwind` were introduced.
    Their behavior is specified in RFC 2945 [1].

    However, it was reported in the #ffi-unwind stream of the Rust
    community Zulip that this had altered the way that `extern "C"`
    functions behaved even when the `c_unwind` feature gate was not
    active. [2]

 ### Overview

    This makes a small patch to
    `rustc_mir_build::build::should_abort_on_panic`, so that the same
    behavior from before is in place when the `c_unwind` gate is not
    active.

    `rustc_middle::ty::layout::fn_can_unwind` is not touched, as the
    visible behavior should not differ before/after #76570. [3]

 ### Footnotes

 [1]: https://github.com/rust-lang/rfcs/blob/master/text/2945-c-unwind-abi.md
 [2]: https://rust-lang.zulipchat.com/#narrow/stream/210922-project-ffi-unwind/topic/Is.20unwinding.20through.20extern.20C.20UB.3F/near/230112325
 [3]: https://github.com/rust-lang/rust/pull/76570/files#diff-b0320c2b8868f325d83c027fc5d71732636e9763551e35895488f30fe057c6e9L2599-R2617
2021-04-13 09:55:21 -04:00
Alex Crichton
482a3d06c3 rustc: Add a new wasm ABI
This commit implements the idea of a new ABI for the WebAssembly target,
one called `"wasm"`. This ABI is entirely of my own invention
and has no current precedent, but I think that the addition of this ABI
might help solve a number of issues with the WebAssembly targets.

When `wasm32-unknown-unknown` was first added to Rust I naively
"implemented an abi" for the target. I then went to write `wasm-bindgen`
which accidentally relied on details of this ABI. Turns out the ABI
definition didn't match C, which is causing issues for C/Rust interop.
Currently the compiler has a "wasm32 bindgen compat" ABI which is the
original implementation I added, and it's purely there for, well,
`wasm-bindgen`.

Another issue with the WebAssembly target is that it's not clear to me
when and if the default C ABI will change to account for WebAssembly's
multi-value feature (a feature that allows functions to return multiple
values). Even if this does happen, though, it seems like the C ABI will
be guided based on the performance of WebAssembly code and will likely
not match even what the current wasm-bindgen-compat ABI is today. This
leaves a hole in Rust's expressivity in binding WebAssembly where given
a particular import type, Rust may not be able to import that signature
with an updated C ABI for multi-value.

To fix these issues I had the idea of a new ABI for WebAssembly, one
called `wasm`. The definition of this ABI is "what you write
maps straight to wasm". The goal here is that whatever you write down in
the parameter list or in the return values goes straight into the
function's signature in the WebAssembly file. This special ABI is for
intentionally matching the ABI of an imported function from the
environment or exporting a function with the right signature.

With the addition of a new ABI, this enables rustc to:

* Eventually remove the "wasm-bindgen compat hack". Once this
  ABI is stable wasm-bindgen can switch to using it everywhere.
  Afterwards the wasm32-unknown-unknown target can have its default ABI
  updated to match C.

* Expose the ability to precisely match an ABI signature for a
  WebAssembly function, regardless of what the C ABI that clang chooses
  turns out to be.

* Continue to evolve the definition of the default C ABI to match what
  clang does on all targets, since the purpose of that ABI will be
  explicitly matching C rather than generating particular function
  imports/exports.

Naturally this is implemented as an unstable feature initially, but it
would be nice for this to get stabilized (if it works) in the near-ish
future to remove the wasm32-unknown-unknown incompatibility with the C
ABI. Doing this, however, requires the feature to be on stable because
wasm-bindgen works with stable Rust.
2021-04-08 08:03:18 -07:00
Dylan DPC
b81c6cdb57
Rollup merge of #83916 - Amanieu:asm_anonconst, r=petrochenkov
Use AnonConst for asm! constants

This replaces the old system which used explicit promotion. See #83169 for more background.

The syntax for `const` operands is still the same as before: `const <expr>`.

Fixes #83169

Because the implementation is heavily based on inline consts, we suffer from the same issues:
- We lose the ability to use expressions derived from generics. See the deleted tests in `src/test/ui/asm/const.rs`.
- We are hitting the same ICEs as inline consts, for example #78174. It is unlikely that we will be able to stabilize this before inline consts are stabilized.
2021-04-07 13:07:14 +02:00
Amanieu d'Antras
32be124e30 Use AnonConst for asm! constants 2021-04-06 12:35:41 +01:00
Roxane
0a97eee8df Reduce size of statements 2021-04-02 19:11:50 -04:00
Roxane
2fb1fb7634 Fix diagnostic issue when using FakeReads in closures 2021-04-02 19:11:50 -04:00
bors
0978a9eb99 Auto merge of #83207 - oli-obk:valtree2, r=lcnr
normalize mir::Constant differently from ty::Const in preparation for valtrees

Valtrees are unable to represent many kind of constant values (this is on purpose). For constants that are used at runtime, we do not need a valtree representation and can thus use a different form of evaluation. In order to make this explicit and less fragile, I added a `fold_constant` method to `TypeFolder` and implemented it for normalization. Normalization can now, when it wants to eagerly evaluate a constant, normalize `mir::Constant` directly into a `mir::ConstantKind::Val` instead of relying on the `ty::Const` evaluation.

In the future we can get rid of the `ty::Const` in there entirely and add our own `Unevaluated` variant to `mir::ConstantKind`. This would allow us to remove the `promoted` field from `ty::ConstKind::Unevaluated`, as promoteds can never occur in the type system.

cc `@rust-lang/wg-const-eval`

r? `@lcnr`
2021-04-02 10:28:12 +00:00
bors
d1065e6cef Auto merge of #83663 - AngelicosPhosphoros:simplify_binary_and_to_get_better_asm, r=nagisa
Simplify logical operations CFG

This is basically same commit as e38e954a0d which was reverted later in 676953fde9
In both cases, this changes weren't benchmarked.
e38e954a0d leads to missed optimization described in [this issue](https://github.com/rust-lang/rust/issues/62993)
676953fde9 leads to missed optimization described in [this issue](https://github.com/rust-lang/rust/issues/83623)
2021-04-02 00:48:31 +00:00
AngelicosPhosphoros
4464cc2256 Simplify logical operations CFG
This is basically same commit as e38e954a0d which was reverted later in 676953fde9
In both cases, this changes weren't benchmarked.
e38e954a0d leads to missed optimization described in [this issue](https://github.com/rust-lang/rust/issues/62993)
676953fde9 leads to missed optimization described in [this issue](https://github.com/rust-lang/rust/issues/83623)

Also it changes some src/test/run-make-fulldeps/coverage-spanview/expected_mir_dump* files automatically.
2021-04-01 18:34:11 +03:00
Jack Huey
6d5efa9f04 Add var to BoundRegion. Add query to get bound vars for applicable items. 2021-03-31 10:16:37 -04:00
Oli Scherer
5b6ddd5026 Convert a closure into a method 2021-03-29 12:30:55 +00:00
Josh Stone
72ebebe474 Use iter::zip in compiler/ 2021-03-26 09:32:31 -07:00
bors
5d04957a4b Auto merge of #79278 - mark-i-m:stabilize-or-pattern, r=nikomatsakis
Stabilize or_patterns (RFC 2535, 2530, 2175)

closes #54883

This PR stabilizes the or_patterns feature in Rust 1.53.

This is blocked on the following (in order):
- [x] The crater run in https://github.com/rust-lang/rust/pull/78935#issuecomment-731564021
- [x] The resolution of the unresolved questions and a second crater run (https://github.com/rust-lang/rust/pull/78935#issuecomment-735412705)
    - It looks like we will need to pursue some sort of edition-based transition for `:pat`.
- [x] Nomination and discussion by T-lang
- [x] Implement new behavior for `:pat` based on consensus (https://github.com/rust-lang/rust/pull/80100).
- [ ] An FCP on stabilization

EDIT: Stabilization report is in https://github.com/rust-lang/rust/pull/79278#issuecomment-772815177
2021-03-22 19:48:27 +00:00
lcnr
43ebac119b extract ConstKind::Unevaluated into a struct 2021-03-20 17:21:44 +01:00
mark
db5629adcb stabilize or_patterns 2021-03-19 19:45:32 -05:00
Jennifer Wills
52dba13e41 Replace closures_captures and upvar_capture with closure_min_captures
make changes to liveness to use closure_min_captures

use different span

borrow check uses new structures

rename to CapturedPlace

stop using upvar_capture in regionck

remove the bridge

cleanup from rebase + remove the upvar_capture reference from mutability_errors.rs

remove line from livenes test

make our unused var checking more consistent

update tests

adding more warnings to the tests

move is_ancestor_or_same_capture to rustc_middle/ty

update names to reflect the closures

add FIXME

check that all captures are immutable borrows before returning

add surrounding if statement like the original

move var out of the loop and rename

Co-authored-by: Logan Mosier <logmosier@gmail.com>
Co-authored-by: Roxane Fruytier <roxane.fruytier@hotmail.com>
2021-03-18 20:45:49 -04:00
bors
b4adc21c4f Auto merge of #83188 - petrochenkov:field, r=lcnr
ast/hir: Rename field-related structures

I always forget what `ast::Field` and `ast::StructField` mean despite working with AST for long time, so this PR changes the naming to less confusing and more consistent.

- `StructField` -> `FieldDef` ("field definition")
- `Field` -> `ExprField` ("expression field", not "field expression")
- `FieldPat` -> `PatField` ("pattern field", not "field pattern")

Various visiting and other methods working with the fields are renamed correspondingly too.

The second commit reduces the size of `ExprKind` by boxing fields of `ExprKind::Struct` in preparation for https://github.com/rust-lang/rust/pull/80080.
2021-03-17 16:49:46 +00:00
bors
e655fb6221 Auto merge of #82936 - oli-obk:valtree, r=RalfJung,lcnr,matthewjasper
Implement (but don't use) valtree and refactor in preparation of use

This PR does not cause any functional change. It refactors various things that are needed to make valtrees possible. This refactoring got big enough that I decided I'd want it reviewed as a PR instead of trying to make one huge PR with all the changes.

cc `@rust-lang/wg-const-eval` on the following commits:

* 2027184 implement valtree
* eeecea9 fallible Scalar -> ScalarInt
* 042f663 ScalarInt convenience methods

cc `@eddyb` on ef04a6d

cc `@rust-lang/wg-mir-opt` for cf1700c (`mir::Constant` can now represent either a `ConstValue` or a `ty::Const`, and it is totally possible to have two different representations for the same value)
2021-03-16 22:42:56 +00:00
bors
f5d8117c33 Auto merge of #82536 - sexxi-goose:handle-patterns-take-2, r=nikomatsakis
2229: Handle patterns within closures correctly when `capture_disjoint_fields` is enabled

This PR fixes several issues related to handling patterns within closures when `capture_disjoint_fields` is enabled.
1. Matching is always considered a use of the place, even with `_` patterns
2. Compiler ICE when capturing fields in closures through `let` assignments

To do so, we

- Introduced new Fake Reads
- Delayed use of `Place` in favor of `PlaceBuilder`
- Ensured that `PlaceBuilder` can be resolved before attempting to extract `Place` in any of the pattern matching code

Closes rust-lang/project-rfc-2229/issues/27
Closes rust-lang/project-rfc-2229/issues/24
r? `@nikomatsakis`
2021-03-16 19:19:06 +00:00
Vadim Petrochenkov
b25d3ba781 ast/hir: Rename field-related structures
StructField -> FieldDef ("field definition")
Field -> ExprField ("expression field", not "field expression")
FieldPat -> PatField ("pattern field", not "field pattern")

Also rename visiting and other methods working on them.
2021-03-16 11:41:24 +03:00
Roxane
189d206522 Fix error after rebase 2021-03-15 13:16:18 -04:00
Roxane
22eaffe71a Add comments with examples and tests 2021-03-15 13:16:04 -04:00
Roxane
74fc64303f Only borrow place for matching under specific conditions 2021-03-14 19:42:00 -04:00
Roxane
685a4c6b6b Use the correct FakeReadCause 2021-03-14 19:28:57 -04:00
Roxane
d4f8729c89 Delay use of Place in favor of PlaceBuilder 2021-03-14 17:07:58 -04:00
Roxane
ec10b71d42 Introduce new fake reads 2021-03-14 16:31:26 -04:00
Ömer Sinan Ağacan
14038c7df2 Remove duplicate asserts, replace eq assert with assert_eq 2021-03-14 17:06:18 +03:00
Yuki Okushi
0d9a6edb50
Rollup merge of #82789 - csmoe:issue-82772, r=estebank
Get with field index from pattern slice instead of directly indexing

Closes #82772
r? ``@estebank``

https://github.com/rust-lang/rust/pull/82789#issuecomment-796921977
> ``@estebank`` So the real cause is we only generate single pattern for Box here
615b03aeaa/compiler/rustc_mir_build/src/thir/pattern/deconstruct_pat.rs (L1130-L1132)
But in the replacing function, it tries to index on the 1-length pattern slice with field 1, thus out of bounds.
615b03aeaa/compiler/rustc_mir_build/src/thir/pattern/deconstruct_pat.rs (L1346)
2021-03-14 13:07:31 +09:00
Oli Scherer
11ddd22510 Run rustfmt 2021-03-12 13:46:39 +00:00
Oli Scherer
3127a9c60f Prepare mir::Constant for ty::Const only supporting valtrees 2021-03-12 12:43:54 +00:00
Oli Scherer
d5eec653c0 Use the explicit error constant instead of fake dummies 2021-03-12 12:25:08 +00:00
Yuki Okushi
14846d945d
Rollup merge of #83018 - oli-obk:float_check, r=davidtwco
Reintroduce accidentally deleted assertions.

These were removed in https://github.com/rust-lang/rust/pull/50198
2021-03-12 08:55:22 +09:00
LeSeulArtichaut
2a34428253 Make THIR data structures public 2021-03-11 19:42:39 +01:00
csmoe
77fb6a0f32 fix: check before index into generated patterns 2021-03-12 01:54:08 +08:00
bors
61365c0625 Auto merge of #82495 - LeSeulArtichaut:eager-thir, r=oli-obk
Eagerly construct bodies of THIR

With this PR:
 - the THIR is no longer constructed lazily, but is entirely built before being passed to the MIR Builder
 - the THIR is now allocated in arenas instead of `Box`es

However, this PR doesn't make any changes to the way patterns are constructed: they are still boxed, and exhaustiveness checking is unchanged.

Implements MCP rust-lang/compiler-team#409.
Closes rust-lang/project-thir-unsafeck#1.
r? `@ghost` cc `@nikomatsakis` `@oli-obk`
2021-03-11 15:34:01 +00:00
Oli Scherer
c69b108d2a Reintroduce accidentally deleted assertions.
These were removed in https://github.com/rust-lang/rust/pull/50198
2021-03-11 14:56:03 +00:00
bors
17a07d71bf Auto merge of #76570 - cratelyn:implement-rfc-2945-c-unwind-abi, r=Amanieu
Implement RFC 2945: "C-unwind" ABI

## Implement RFC 2945: "C-unwind" ABI

This branch implements [RFC 2945]. The tracking issue for this RFC is #74990.

The feature gate for the issue is `#![feature(c_unwind)]`.

This RFC was created as part of the ffi-unwind project group tracked at rust-lang/lang-team#19.

### Changes

Further details will be provided in commit messages, but a high-level overview
of the changes follows:

* A boolean `unwind` payload is added to the `C`, `System`, `Stdcall`,
and `Thiscall` variants, marking whether unwinding across FFI boundaries is
acceptable. The cases where each of these variants' `unwind` member is true
correspond with the `C-unwind`, `system-unwind`, `stdcall-unwind`, and
`thiscall-unwind` ABI strings introduced in RFC 2945 [3].

* This commit adds a `c_unwind` feature gate for the new ABI strings.
Tests for this feature gate are included in `src/test/ui/c-unwind/`, which
ensure that this feature gate works correctly for each of the new ABIs.
A new language features entry in the unstable book is added as well.

* We adjust the `rustc_middle::ty::layout::fn_can_unwind` function,
used to compute whether or not a `FnAbi` object represents a function that
should be able to unwind when `panic=unwind` is in use.

* Changes are also made to
`rustc_mir_build::build::should_abort_on_panic` so that the function ABI is
used to determind whether it should abort, assuming that the `panic=unwind`
strategy is being used, and no explicit unwind attribute was provided.

[RFC 2945]: https://github.com/rust-lang/rfcs/blob/master/text/2945-c-unwind-abi.md
2021-03-10 16:44:04 +00:00
katelyn a. martin
05bf037fec address pr review comments
### Add debug assertion to check `AbiDatas` ordering

    This makes a small alteration to `Abi::index`, so that we include a
    debug assertion to check that the index we are returning corresponds
    with the same abi in our data array.

    This will help prevent ordering bugs in the future, which can
    manifest in rather strange errors.

 ### Using exhaustive ABI matches

    This slightly modifies the changes from our previous commits,
    favoring exhaustive matches in place of `_ => ...` fall-through
    arms.

    This should help with maintenance in the future, when additional
    ABI's are added, or when existing ABI's are modified.

 ### List all `-unwind` ABI's in unstable book

    This updates the `c-unwind` page in the unstable book to list _all_
    of the other ABI strings that are introduced by this feature gate.

    Now, all of the ABI's specified by RFC 2945 are shown.

Co-authored-by: Amanieu d'Antras <amanieu@gmail.com>
Co-authored-by: Niko Matsakis <niko@alum.mit.edu>
2021-03-09 14:40:33 -05:00
katelyn a. martin
0f33e9f281 implement unwinding abi's (RFC 2945)
### Changes

    This commit implements unwind ABI's, specified in RFC 2945.

    We adjust the `rustc_middle::ty::layout::fn_can_unwind` function,
    used to compute whether or not a `FnAbi` object represents a
    function that should be able to unwind when `panic=unwind` is in
    use.

    Changes are also made to
    `rustc_mir_build::build::should_abort_on_panic` so that the
    function ABI is used to determind whether it should abort, assuming
    that the `panic=unwind` strategy is being used, and no explicit
    unwind attribute was provided.

 ### Tests

    Unit tests, checking that the behavior is correct for `C-unwind`,
    `stdcall-unwind`, `system-unwind`, and `thiscall-unwind`, are
    included. These alternative `unwind` ABI strings are specified in
    RFC 2945, in the "_Other `unwind` ABI strings_" section.

    Additionally, a test case is included to assert that the LLVM IR
    generated for an external function defined with the `C-unwind` ABI
    will be appropriately labeled with the `nounwind` LLVM attribute
    when the `panic=abort` compilation flag is used.

 ### Ignore Directives

    This commit uses `ignore-*` directives in two of our `*-unwind` ABI
    test cases.

    Specifically, the `stdcall-unwind` and `thiscall-unwind` test cases
    ignore architectures that do not support `stdcall` and `thiscall`,
    respectively.

    These directives are cribbed from
    `src/test/ui/c-variadic/variadic-ffi-1.rs` for `stdcall`, and
    `src/test/ui/extern/extern-thiscall.rs` for `thiscall`.
2021-03-09 14:38:29 -05:00
LeSeulArtichaut
d6c737adb5 Take into account ExprKind::Scope when calculating span of temporary 2021-03-09 20:15:03 +01:00
LeSeulArtichaut
5f38c839ad Prevent stack overflow when building THIR 2021-03-09 20:15:01 +01:00
LeSeulArtichaut
cd049ef9ea Remove useless references/dereferences 2021-03-09 20:15:01 +01:00
LeSeulArtichaut
c2c4322891 Make arena allocation for the THIR work 2021-03-09 20:14:42 +01:00
LeSeulArtichaut
a9f4dfc8fa Remove Clone impl for thir::Expr 2021-03-09 20:13:59 +01:00
LeSeulArtichaut
2a2b4d7257 Pull thir::Cx out of the MIR Builder 2021-03-09 20:13:58 +01:00
LeSeulArtichaut
60def4de5e [WIP] Eagerly construct bodies of THIR 2021-03-09 20:12:41 +01:00
Camille GILLOT
8e816056a5 Do not store attrs in FnKind. 2021-03-09 19:09:33 +01:00
Mara Bos
bb9542b016
Rollup merge of #82841 - hvdijk:x32, r=joshtriplett
Change x64 size checks to not apply to x32.

Rust contains various size checks conditional on target_arch = "x86_64", but these checks were never intended to apply to x86_64-unknown-linux-gnux32. Add target_pointer_width = "64" to the conditions.
2021-03-09 09:05:24 +00:00
bors
27885a94c6 Auto merge of #82727 - oli-obk:shrinkmem, r=pnkfelix
Test the effect of shrinking the size of Rvalue by 16 bytes

r? `@ghost`
2021-03-08 08:39:24 +00:00
Harald van Dijk
95e096d623
Change x64 size checks to not apply to x32.
Rust contains various size checks conditional on target_arch = "x86_64",
but these checks were never intended to apply to
x86_64-unknown-linux-gnux32. Add target_pointer_width = "64" to the
conditions.
2021-03-06 16:02:48 +00:00
Mara
e6a6df5daa
Rollup merge of #80723 - rylev:noop-lint-pass, r=estebank
Implement NOOP_METHOD_CALL lint

Implements the beginnings of https://github.com/rust-lang/lang-team/issues/67 - a lint for detecting noop method calls (e.g, calling `<&T as Clone>::clone()` when `T: !Clone`).

This PR does not fully realize the vision and has a few limitations that need to be addressed either before merging or in subsequent PRs:
* [ ] No UFCS support
* [ ] The warning message is pretty plain
* [ ] Doesn't work for `ToOwned`

The implementation uses [`Instance::resolve`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/instance/struct.Instance.html#method.resolve) which is normally later in the compiler. It seems that there are some invariants that this function relies on that we try our best to respect. For instance, it expects substitutions to have happened, which haven't yet performed, but we check first for `needs_subst` to ensure we're dealing with a monomorphic type.

Thank you to ```@davidtwco,``` ```@Aaron1011,``` and ```@wesleywiser``` for helping me at various points through out this PR ❤️.
2021-03-05 10:57:14 +01:00
Oli Scherer
9a2362e5a9 Shrink the size of Rvalue by 16 bytes 2021-03-05 09:33:01 +00:00
Ryan Levick
a6d926d80d Fix tests 2021-03-03 11:22:44 +01:00
Dániel Buga
b97eb23cd0 Box generator-related Body fields 2021-03-01 08:32:49 +01:00
bors
11f838d64a Auto merge of #81978 - tmiasko:head-ctor, r=Mark-Simulacrum
Inline hot part of PatStack::head_ctor

When building rustc with `-Codegen-units=1` this inline hint ensures
that obtaining already initialized head constructor does not involve
a function call overhead and reduces the instruction count in
match-stress-enum-check full benchmark from 11.9G to 9.8G.

It shouldn't have significant impact on the currently default
configuration where it reflects existing inlining decisions.
2021-02-22 21:45:50 +00:00
Camelid
5d2a2a1caa Add explanations and suggestions to irrefutable_let_patterns lint 2021-02-18 16:21:16 -08:00
Dylan DPC
b3d3251271
Rollup merge of #82215 - TaKO8Ki:replace-if-let-while-let, r=varkor
Replace if-let and while-let with `if let` and `while let`

This pull request replaces if-let and while-let with `if let` and `while let`.

closes https://github.com/rust-lang/rust/issues/82205
2021-02-18 16:57:37 +01:00
Tomasz Miąsko
a3659bbe6c Inline hot part of PatStack::head_ctor
When building rustc with `-Codegen-units=1` this inline hint ensures
that obtaining already initialized head constructor does not involve
a function call overhead and reduces the instruction count in
match-stress-enum-check full benchmark from 11.9G to 9.8G.

It shouldn't have significant impact on the currently default
configuration where it reflects existing inlining decisions.
2021-02-18 00:00:00 +00:00
Takayuki Maeda
0f04875d2e replace if-let and while-let with if let and while let 2021-02-17 19:26:38 +09:00
Tomasz Miąsko
64b5b75e65 Use !Sync std::lazy::OnceCell in usefulness checking
The `rustc_data_structures::sync::OnceCell` is thread-safe when building
a parallel compiler. This is unnecessary for the purposes of pattern
usefulness checking. Use `!Sync` `std::lazy::OnceCell` instead.
2021-02-15 00:00:00 +00:00
Dylan DPC
c8dacf95ae
Rollup merge of #82029 - tmiasko:debug, r=matthewjasper
Use debug log level for developer oriented logs

The information logged here is of limited general interest, while at the
same times makes it impractical to simply enable logging and share the
resulting logs due to the amount of the output produced.

Reduce log level from info to debug for developer oriented information.

For example, when building cargo, this reduces the amount of logs
generated by `RUSTC_LOG=info cargo build` from 265 MB to 79 MB.

Continuation of changes from 81350.
2021-02-14 16:54:52 +01:00
klensy
93c8ebe022 bumped smallvec deps 2021-02-14 18:03:11 +03:00
Tomasz Miąsko
361dcd5ca7 Use debug log level for developer oriented logs
The information logged here is of limited general interest, while at the
same times makes it impractical to simply enable logging and share the
resulting logs due to the amount of the output produced.

Reduce log level from info to debug for developer oriented information.

For example, when building cargo, this reduces the amount of logs
generated by `RUSTC_LOG=info cargo build` from 265 MB to 79 MB.

Continuation of changes from 81350.
2021-02-13 00:00:00 +00:00
bors
26e5bcd220 Auto merge of #81350 - tmiasko:instrument-debug, r=lcnr
Reduce log level used by tracing instrumentation from info to debug

Restore log level to debug to avoid make info log level overly verbose (the uses of instrument attribute modified there, were for the most part a replacement for `debug!`;  one use was novel).
2021-02-11 13:44:00 +00:00
Ömer Sinan Ağacan
c4e3558b8c Rename HIR UnOp variants
This renames the variants in HIR UnOp from

    enum UnOp {
        UnDeref,
        UnNot,
        UnNeg,
    }

to

    enum UnOp {
        Deref,
        Not,
        Neg,
    }

Motivations:

- This is more consistent with the rest of the code base where most enum
  variants don't have a prefix.

- These variants are never used without the `UnOp` prefix so the extra
  `Un` prefix doesn't help with readability. E.g. we don't have any
  `UnDeref`s in the code, we only have `UnOp::UnDeref`.

- MIR `UnOp` type variants don't have a prefix so this is more
  consistent with MIR types.

- "un" prefix reads like "inverse" or "reverse", so as a beginner in
  rustc code base when I see "UnDeref" what comes to my mind is
  something like "&*" instead of just "*".
2021-02-09 11:39:20 +03:00