Put all feature gate tests under `feature-gates/`
There was one directory that had only a single test and there was also a
test in the top-level directory. This moves both of them to
`feature-gates/`.
Add a regression test for #76281
This has been fixed between 1.47.0-nightly (663d2f5cd 2020-08-22) and 1.47.0-nightly (5180f3da5 2020-08-23). Maybe fixed by #73526?
Created `wasm` dir, it currently has only one test but I'll move some wasm-related tests there as a follow-up.
Closes#76281
Re-stabilize Weak::as_ptr and friends for unsized T
As per [T-lang consensus](https://hackmd.io/7r3_is6uTz-163fsOV8Vfg), this uses a branch to handle the dangling case. The discussed optimization of only doing the branch in the T: ?Sized case is left for a followup patch, as doing so is not trivial (as it requires specialization) and not _obviously_ better (as it requires using `wrapping_offset` rather than `offset` more).
<details><summary>Basically said optimization</summary>
Specialize on `T: Sized`:
```rust
fn as_ptr(&self) -> *const T {
if [ T is Sized ] || !is_dangling(ptr) {
(ptr as *mut T).set_ptr_value( (ptr as *mut u8).wrapping_offset(data_offset) )
} else {
ptr::null()
}
}
fn from_raw(*const T) -> Self {
if [ T is Sized ] || !ptr.is_null() {
let ptr = (ptr as *mut RcBox).set_ptr_value( (ptr as *mut u8).wrapping_offset(-data_offset) );
Weak { ptr }
} else {
Weak::new()
}
}
```
(but with more `set_ptr_value` to avoid `Sized` restrictions and maintain metadata.)
Written in this fashion, this is not a correctness-critical specialization (i.e. so long as `[ T is Sized ]` is false for unsized `T`, it can be `rand()` for sized `T` without breaking correctness), but it's still touchy, so I'd rather do it in another PR with separate review.
---
</details>
This effectively reverts #80422 and re-establishes #74160. T-libs [previously signed off](https://github.com/rust-lang/rust/pull/74160#issuecomment-660539373) on this stable API change in #74160.
Clarify what the effects of a 'logic error' are
This clarifies what a 'logic error' is (which is a term used to describe what happens if you put things in a hash table or btree and then use something like a refcell to break the internal ordering). This tries to be as vague as possible, as we don't really want to promise what happens, except "bad things, but not UB". This was discussed in #80657
TrustedRandomAaccess specialization composes incorrectly for nested iter::Zips
I found this while working on improvements for TRA.
After partially consuming a Zip adapter and then wrapping it into another Zip where the adapters use their `TrustedRandomAccess` specializations leads to the outer adapter returning elements which should have already been consumed.
If the optimizer gets tripped up by the addition this might affect performance for chained `zip()` iterators even when the inner one is not partially advanced but it would require more extensive fixes to `TrustedRandomAccess` to communicate those offsets earlier.
Included test fails on nightly, [playground link](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=24fa1edf8a104ff31f5a24830593b01f)
Introduce {Ref, RefMut}::try_map for optional projections in RefCell
This fills a usability gap of `RefCell` I've personally encountered to perform optional projections, mostly into collections such as `RefCell<Vec<T>>` or `RefCell<HashMap<U, T>>`:
> This kind of API was briefly featured under Open questions in #10514 back in 2013 (!)
```rust
let values = RefCell::new(vec![1, 2, 3, 4]);
let b = Ref::opt_map(values.borrow(), |vec| vec.get(2));
```
It primarily avoids this alternative approach to accomplish the same kind of projection which is both rather noisy and panicky:
```rust
let values = RefCell::new(vec![1, 2, 3, 4]);
let b = if values.get(2).is_some() {
Some(Ref::map(values.borrow(), |vec| vec.get(2).unwrap()))
} else {
None
};
```
### Open questions
The naming `opt_map` is preliminary. I'm not aware of prior art in std to lean on here, but this name should probably be improved if this functionality is desirable.
Since `opt_map` consumes the guard, and alternative syntax might be more appropriate which instead *tries* to perform the projection, allowing the original borrow to be recovered in case it fails:
```rust
pub fn try_map<U: ?Sized, F>(orig: Ref<'b, T>, f: F) -> Result<Ref<'b, U>, Self>
where
F: FnOnce(&T) -> Option<&U>;
```
This would be more in line with the `try_map` method [provided by parking lot](https://docs.rs/lock_api/0/lock_api/struct.RwLockWriteGuard.html#method.try_map).
implement ptr::write without dedicated intrinsic
This makes `ptr::write` more consistent with `ptr::write_unaligned`, `ptr::read`, `ptr::read_unaligned`, all of which are implemented in terms of `copy_nonoverlapping`.
This means we can also remove `move_val_init` implementations in codegen and Miri, and its special handling in the borrow checker.
Also see [this Zulip discussion](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/ptr.3A.3Aread.20vs.20ptr.3A.3Awrite).
This adds capability to configure the target's stack probe support in a
more precise manner than just on/off. In particular now we allow
choosing between always inline-asm, always call or either one of those
depending on the LLVM version on a per-target basis.
The first parse is to collect whether the code contains macros, has
`main`, and uses other crates. In that pass we ignore errors as those
will be reported when the test file is actually built.
For that we need to reset errors in the `Diagnostic` otherwise when
dropping it unhandled errors will be reported as compiler bugs.
Fixes#80992
- Don't ignore packaging `llvm/lib/` for `rust-dev` when LLVM is linked
statically
- Add `link-type.txt` so bootstrap knows whether llvm was linked
statically or dynamically
- Don't assume CI LLVM is linked dynamically in `bootstrap::config`
- Fall back to dynamic linking if `link-type.txt` doesn't exist
- Fix existing bug that split the output of `llvm-config` on lines, not spaces
- Enable building LLVM tests
This works around the following llvm bug:
```
llvm-config: error: component libraries and shared library
llvm-config: error: missing: /home/joshua/rustc2/build/x86_64-unknown-linux-gnu/llvm/build/lib/libgtest.a
llvm-config: error: missing: /home/joshua/rustc2/build/x86_64-unknown-linux-gnu/llvm/build/lib/libgtest_main.a
llvm-config: error: missing: /home/joshua/rustc2/build/x86_64-unknown-linux-gnu/llvm/build/lib/libLLVMTestingSupport.a
thread 'main' panicked at 'command did not execute successfully: "/home/joshua/rustc2/build/x86_64-unknown-linux-gnu/llvm/build/bin/llvm-config" "--libfiles"
```
I'm not sure why llvm-config thinks these are required, but to avoid
the error, this builds them anyway.
- Temporarily set windows as the try builder. This should be reverted
before merging.
- Bump version of `download-ci-llvm-stamp`
`src/llvm-project` hasn't changed, but the generated tarball has.
- Only special case MacOS when dynamic linking. Static linking works fine.
- Store `link-type.txt` to the top-level of the tarball
This allows writing the link type unconditionally. Previously, bootstrap
had to keep track of whether the file IO *would* succeed (it would fail
if `lib/` didn't exist), which was prone to bugs.
- Make `link-type.txt` required
Anyone downloading this from CI should be using a version of bootstrap
that matches the version of the uploaded artifacts. So a missing
link-type indicates a bug in x.py.
It's not an internal lint:
- It's not in the rustc::internal lint group
- It's on unconditionally, because it actually lints `staged_api`, not
the compiler
This fixes a bug where `#[deny(rustc::internal)]` would warn that
`rustc::internal` was an unknown lint.
Improve JS performance by storing length before comparing to it in loops
Since https://github.com/rust-lang/rust/pull/79052 is quite complicated to review, I suggested to split into smaller parts. This first part is mostly about saving the array length into a variable (I tried to not change anything else as much as possible 😃 ).
r? `@jyn514`
Add test for #59352
Issue #59352 reported an optimization regression with rustc 1.32.0+. That regression could be tracked to a change that caused a function to miss the size limit of llvm's inlining, which results in an unreachable panicing branch being generated.
Enabling mir inline solves the issue, but is currently only done for `mir-opt-level>=2`.
This PR adds a test that can serve as a regression test for #59352, if/when mir inlining gets mature enough for opt-level 1, or some other optimization can remove the panic.
