Implement Unsized Rvalues
This PR is the first step to implement RFC1909: unsized rvalues (#48055).
## Implemented
- `Sized` is removed for arguments and local bindings. (under `#![feature(unsized_locals)]`)
- Unsized locations are allowed in MIR
- Unsized places and operands are correctly translated at codegen
## Not implemented in this PR
- Additional `Sized` checks:
- tuple struct constructor (accidentally compiles now)
- closure arguments at closure generation (accidentally compiles now)
- upvars (ICEs now)
- Generating vtable for `fn method(self)` (ICEs now)
- VLAs: `[e; n]` where `n` isn't const
- Reduce unnecessary allocations
## Current status
- [x] Fix `__rust_probestack` (rust-lang-nursery/compiler-builtins#244)
- [x] Get the fix merged
- [x] `#![feature(unsized_locals)]`
- [x] Give it a tracking issue number
- [x] Lift sized checks in typeck and MIR-borrowck
- [ ] <del>Forbid `A(unsized-expr)`</del> will be another PR
- [x] Minimum working codegen
- [x] Add more examples and fill in unimplemented codegen paths
- [ ] <del>Loosen object-safety rules (will be another PR)</del>
- [ ] <del>Implement `Box<FnOnce>` (will be another PR)</del>
- [ ] <del>Reduce temporaries (will be another PR)</del>
debug_assert to ensure that from_raw_parts is only used properly aligned
This does not help nearly as much as I would hope because everybody uses the distributed libstd which is compiled without debug assertions. For this reason, I am not sure if this is even worth it. OTOH, this would have caught the misalignment fixed by https://github.com/rust-lang/rust/issues/42789 *if* there had been any tests actually using ZSTs with alignment >1 (we have a CI runner which has debug assertions in libstd enabled), and it seems to currently [fail in the rg testsuite](https://ci.appveyor.com/project/rust-lang/rust/build/1.0.8403/job/v7dfdcgn8ay5j6sb). So maybe it is worth it, after all.
I have seen the attribute `#[rustc_inherit_overflow_checks]` in some places, does that make it so that the *caller's* debug status is relevant? Is there a similar attribute for `debug_assert!`? That could even subsume `rustc_inherit_overflow_checks`: Something like `rustc_inherit_debug_flag` could affect *all* places that change the generated code depending on whether we are in debug or release mode. In fact, given that we have to keep around the MIR for generic functions anyway, is there ever a reason *not* to handle the debug flag that way? I guess currently we apply debug flags like `cfg` so this is dropped early during the MIR pipeline?
EDIT: I learned from @eddyb that because of how `debug_assert!` works, this is not realistic. Well, we could still have it for the rustc CI runs and then maybe, eventually, when libstd gets compiled client-side and there is both a debug and a release build... then this will also benefit users.^^
The paragraph described a case where we can't optimize away repetitive
dynamic stack allocation. However, as arielb1 pointed out, it can
actually optimizable by dynamically delaying the stack unwinding.
std: stop backtracing when the frames are full
This is a defensive measure to mitigate the infinite unwind loop seen in #53372. That case will still repeatedly unwind `__rust_try`, but now it will at least stop when `cx.frames` is full.
r? @alexcrichton
[NLL] Returns are interesting for free regions
Based on #53088 - creating now to get feedback.
Closes#51175
* Make assigning to the return type interesting.
* Use "returning this value" instead of "return" in error messages.
* Prefer one of the explanations that we have a name for to a generic interesting cause in some cases.
* Treat causes that involve the destination of a call like assignments.
Non-naive implementation of `VecDeque.append`
Replaces the old, simple implementation with a more manual (and **unsafe** 😱) one. I've added 1 more test and verified that it covers all 6 code paths in the function.
This new implementation was about 60% faster than the old naive one when I tried benchmarking it.
Set more llvm function attributes for __rust_try
This shim is generated elsewhere in the compiler so this commit adds support to
ensure it goes through similar paths as the rest of the compiler to set llvm
function attributes like target features.
cc #53372
Make some ported cfail tests robust w.r.t. NLL
Updated the most glaring instances of weak tests w.r.t. NLL that came from #53196.
See also the bulletpoint list on #53351.
Rollup of 11 pull requests
Successful merges:
- #52858 (Implement Iterator::size_hint for Elaborator.)
- #53321 (Fix usage of `wasm_target_feature`)
- #53326 ([nll] add regression test for issue #27868)
- #53347 (rustc_resolve: don't allow paths starting with `::crate`.)
- #53349 ([nll] add tests for #48697 and #30104)
- #53357 (Pretty print btreemap for GDB)
- #53358 (`{to,from}_{ne,le,be}_bytes` for unsigned integer types)
- #53406 (Do not suggest conversion method that is already there)
- #53407 (make more ported compile fail tests more robust w.r.t. NLL)
- #53413 (Warn that `#![feature(rust_2018_preview)]` is implied when the edition is set to Rust 2018.)
- #53434 (wasm: Remove --strip-debug argument to LLD)
Failed merges:
r? @ghost
wasm: Remove --strip-debug argument to LLD
Originally added in #52887 this commit disables passing `--strip-debug` to LLD
when optimized. This bring back the original bug of emitting broken debuginfo
but currently it *also* strips the `name` section which makes it very difficult
to inspect the final binary. A real fix is happening at
https://reviews.llvm.org/D50729 and we can reevaluate once we've updated LLD to
have that commit.
make more ported compile fail tests more robust w.r.t. NLL
This is similar to PR #53369, except it covers a disjoint (and much smaller) set of tests that I needed to look at more carefully before being 100% certain they were the same kind of issue.
[nll] add tests for #48697 and #30104
Adds tests for the following issues:
- #48697 ``[NLL] ICE: unexpected region for local data with reference to closure``
- #30104 ``Destructuring boxes into multiple mutable references seems broken``
r? @nikomatsakis
[nll] add regression test for issue #27868
Adds a test for #27868 ``Inconsistent evaluation order for assignment operations``
apart of #47366 ``tracking issue for bugs fixed by the MIR borrow checker or NLL``
r? @nikomatsakis
Fix usage of `wasm_target_feature`
Currently usage results in:
```
error: internal compiler error: librustc_typeck/collect.rs:1928: unknown target feature gate wasm_target_feature
thread 'main' panicked at 'Box<Any>', librustc_errors/lib.rs:579:9
note: Run with `RUST_BACKTRACE=1` for a backtrace.
error: aborting due to previous error
note: the compiler unexpectedly panicked. this is a bug.
note: we would appreciate a bug report: https://github.com/rust-lang/rust/blob/master/CONTRIBUTING.md#bug-reports
note: rustc 1.30.0-nightly (d5a448b3f 2018-08-13) running on x86_64-unknown-linux-gnu
note: compiler flags: -C debuginfo=2 -C linker=/tmp/lld-shim -C incremental --crate-type lib
note: some of the compiler flags provided by cargo are hidden
error: Could not compile `coresimd`.
To learn more, run the command again with --verbose.
```
and hopefully this should fix the ICE!
Add crate build test for `thumb*` targets. [IRR-2018-embedded]
## Summary
This PR adds `run-make` test that compiles `cortex-m` crate for all supported `thumb*-none-*` targets using `cargo` and stage2 `rustc`.
- Supported `thumb*-none-*` targets:
- thumbv6m-none-eabi (Bare Cortex-M0, M0+, M1)
- thumbv7em-none-eabi (Bare Cortex-M4, M7)
- thumbv7em-none-eabihf (Bare Cortex-M4F, M7F, FPU, hardfloat)
- thumbv7m-none-eabi (Bare Cortex-M3)
## How to run & Example output
I tested locally and all targets succeeded like below:
```
./x.py clean
./x.py test --target thumbv6m-none-eabi,thumbv7em-none-eabi,thumbv7em-none-eabihf,thumbv7m-none-eabi src/test/run-make
```
```
Check compiletest suite=run-make mode=run-make (x86_64-unknown-linux-gnu -> thumbv6m-none-eabi)
running 5 tests
.....
test result: ok. 5 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out
```
## How to re-run
Remove `stamp` file for the test run.
```
rm build/x86_64-unknown-linux-gnu/test/run-make/thumb-none-cortex-m/stamp
```
Then run `test`
```
./x.py test --target thumbv6m-none-eabi,thumbv7em-none-eabi,thumbv7em-none-eabihf,thumbv7m-none-eabi src/test/run-make
(snip)
running 5 tests
iiii.
test result: ok. 1 passed; 0 failed; 4 ignored; 0 measured; 0 filtered out
```
## Artifacts
You can examine the artifacts under the directory below:
```
sekineh@sekineh-VirtualBox:~/rustme10$ ls -l build/x86_64-unknown-linux-gnu/test/run-make/thumb-none-cortex-m/thumb-none-cortex-m/
total 4
drwxrwxr-x 7 sekineh sekineh 4096 8月 14 22:40 cortex-m
```
where `build/x86_64-unknown-linux-gnu/test/run-make/thumb-none-cortex-m/thumb-none-cortex-m/` is came from TMPDIR variable.
## Other notes
For `test.rs` modification, I used the same logic as:
- d8b3c830fb/src/bootstrap/dist.rs (L652-L657)
```
if builder.no_std(target) == Some(true) {
// the `test` doesn't compile for no-std targets
builder.ensure(compile::Std { compiler, target });
} else {
builder.ensure(compile::Test { compiler, target });
}
```
It is a useful snippet when adding `no_std` support to `src/bootstrap` code.
CC @kennytm @jamesmunns @nerdyvaishali
compile-fail-fulldeps/proc-macro/proc-macro-attributes.rs - resolution change for derive helper attributes with the same name as derive itself
run-pass/macro-comma-support.rs - indeterminate resolutions for macros in expression positions
ui/issues/issue-49074.rs - diagnostics regression, not enough recovery to report the second error
ui/object-lifetime/object-lifetime-default.stderr - unstable diagnostics?
