Mara Bos [Sun, 17 Jan 2021 12:24:53 +0000 (12:24 +0000)]
Rollup merge of #81064 - Mark-Simulacrum:support-stage1-check, r=jyn514
Support non-stage0 check
Seems to work locally - a full stage 1 check succeeds, building std (because we can't get away with checking it), and then checking the compiler and other tools. This ran into the problem that a unconditional x.py check in stage 1 *both* checks and builds stage 1 std, and then has to clean up because for some reason the rmeta and rlib artifacts conflict (though I'm not actually entirely sure why, but it doesn't seem worth digging in in too much detail).
Ideally we wouldn't be building and checking like that but it's a minor worry as checking std is pretty fast and you can avoid it if you're aiming for speed by passing the compiler (e.g., compiler/rustc) explicitly.
Mara Bos [Sun, 17 Jan 2021 12:24:49 +0000 (12:24 +0000)]
Rollup merge of #80932 - jyn514:download-windows-llvm, r=Mark-Simulacrum
Allow downloading LLVM on Windows and MacOS
- 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
- Only special case MacOS when dynamic linking. Static linking works fine.
- 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.
- Bump version of `download-ci-llvm-stamp`
`src/llvm-project` hasn't changed, but the generated tarball has.
This works on both MacOS and Windows! :tada: :tada: Thanks to ```@nagisa,``` ```@halkcyon,``` ```@Lokathor,``` ```@jryans,``` and ```@poliorcetics``` for helping me test!
The `if-available` check now supports all tier 1 platforms. Although only x64 apple and x64 msvc have been tested, none of the changes here are Windows or Mac specific, and I expect this to work anywhere that LLVM artifacts are uploaded to CI (i.e. the `rust-dev` component exists).
## Windows
Note that if you have an old version of MSVC build tools you'll need to update them. VS Build Tools 2019 14.28 and later are known to work. With old tools, you may see an error like the following:
```
error LNK2001: unresolved external symbol __imp___std_init_once_complete
```
Mara Bos [Sun, 17 Jan 2021 12:24:47 +0000 (12:24 +0000)]
Rollup merge of #80765 - petrochenkov:traitsinscope, r=matthewjasper
resolve: Simplify collection of traits in scope
"Traits in scope" for a given location are collected by walking all scopes in type namespace, collecting traits in them and pruning traits that don't have an associated item with the given name and namespace.
Previously we tried to prune traits using some kind of hygienic resolution for associated items, but that was complex and likely incorrect, e.g. in #80762 correction to visibilites of trait items caused some traits to not be in scope anymore.
I previously had some comments and concerns about this in https://github.com/rust-lang/rust/pull/65351.
In this PR we are doing some much simpler pruning based on `Symbol` and `Namespace` comparisons, it should be enough to throw away 99.9% of unnecessary traits.
It is not necessary for pruning to be precise because for trait aliases, for example, we don't do any pruning at all, and precise hygienic resolution for associated items needs to be done in typeck anyway.
The somewhat unexpected effect is that trait imports introduced by macros 2.0 now bring traits into scope due to the removed hygienic check on associated item names.
I'm not sure whether it is desirable or not, but I think it's acceptable for now.
The old check was certainly incorrect because macros 2.0 did bring trait aliases into scope.
If doing this is not desirable, then we should come up with some other way to avoid bringing traits from macros 2.0 into scope, that would accommodate for trait aliases as well.
---
The PR also contains a couple of pure refactorings
- Scope walk is done by using `visit_scopes` instead of a hand-rolled version.
- Code is restructured to accomodate for rustdoc that also wants to query traits in scope, but doesn't want to filter them by associated items at all.
Mara Bos [Sun, 17 Jan 2021 12:24:44 +0000 (12:24 +0000)]
Rollup merge of #80635 - sexxi-goose:use-place-instead-of-symbol, r=nikomatsakis`
Improve diagnostics when closure doesn't meet trait bound
Improves the diagnostics when closure doesn't meet trait bound by modifying `TypeckResuts::closure_kind_origins` such that `hir::Place` is used instead of `Symbol`. Using `hir::Place` to describe which capture influenced the decision of selecting a trait a closure satisfies to (Fn/FnMut/FnOnce, Copy) allows us to show precise path in the diagnostics when `capture_disjoint_field` feature is enabled.
Resolution ensures that inert attributes cannot be used through imports like this, but built-in attributes don't go through initial resolution (only through resolution validation), so we have to keep some extra data (the built-in attribute name) to prevent it from happening.
Mara Bos [Sun, 17 Jan 2021 12:24:39 +0000 (12:24 +0000)]
Rollup merge of #79298 - lcnr:new-elysium, r=matthewjasper
correctly deal with late-bound lifetimes in anon consts
adds support for using late bound lifetimes of the parent context in anon consts.
```rust
#![feature(const_generics)]
const fn inner<'a>() -> usize where &'a (): Sized { 3 }
fn test<'a>() {
let _: [u8; inner::<'a>()];
}
```
The lifetime `'a` is late bound in `test` so it's not included in its generics but is instead dealt with separately in borrowck.
This didn't previously work for anon consts as they have to use the late bound lifetimes of their parent which has
to be explicitly handled.
r? ```@matthewjasper``` cc ```@varkor``` ```@eddyb```
bors [Sun, 17 Jan 2021 08:44:12 +0000 (08:44 +0000)]
Auto merge of #81083 - ssomers:btree_drainy_refactor_1, r=Mark-Simulacrum
BTreeMap: expose new_internal function and sanitize from_new_internal
`new_internal` is the functional core of the imperative `push_internal_level`, and `from_new_internal` can easily do a proper job instead of returning a half-baked node.
bors [Sun, 17 Jan 2021 05:43:55 +0000 (05:43 +0000)]
Auto merge of #78818 - scottmcm:as_rchunks, r=KodrAus
Add `as_rchunks` (and friends) to slices
`@est31` mentioned (https://github.com/rust-lang/rust/issues/76354#issuecomment-717027175) that, for completeness, there needed to be an `as_chunks`-like method that chunks from the end (with the remainder at the beginning) like `rchunks` does.
So here's a PR for `as_rchunks: &[T] -> (&[T], &[[T; N]])` and `as_rchunks_mut: &mut [T] -> (&mut [T], &mut [[T; N]])`.
But as I was doing this and copy-pasting `from_raw_parts` calls, I thought that I should extract that into an unsafe method. It started out a private helper, but it seemed like `as_chunks_unchecked` could be reasonable as a "real" method, so I added docs and made it public. Let me know if you think it doesn't pull its weight.
bors [Sun, 17 Jan 2021 02:48:07 +0000 (02:48 +0000)]
Auto merge of #80942 - c410-f3r:tests-tests-tests, r=petrochenkov
Move some tests to more reasonable directories - 2
All tests with a score equal or greater than 1.0 were moved to their respective directories by issuing
```bash
cat FILE | tr -s " " | tr -d '():' | sort -k3 | awk '$3 >= 1' | cut -d " " -f1-2 | sed 's;\\;/;g' | xargs -n2 git mv
```
**Observation**: The first column values is the only column with results greater zero
To attest the confidentiality of the model, some manual revision of at least of tests is needed and this process will be tracked in the following list:
* `src/test/ui/abi/issue-28676.rs` OK #28676
* `src/test/ui/array-slice-vec/issue-15730.rs` OK
* `src/test/ui/associated-types/issue-24338.rs` OK #54823
* `src/test/ui/associated-types/issue-48551.rs` Looks OK #48551
* `src/test/ui/associated-types/issue-50301.rs` Looks OK #63577
Scott McMurray [Sat, 16 Jan 2021 22:52:48 +0000 (14:52 -0800)]
Try ignore-debug in the codegen test
This fixed things the last time I had a problem like this. And plausibly will here too -- the check it's failing on is for the high bit being set in the length of the slice, which is a check that's only in a debug_assert.
bors [Sat, 16 Jan 2021 20:26:20 +0000 (20:26 +0000)]
Auto merge of #81089 - m-ou-se:rollup-z7iac6i, r=m-ou-se
Rollup of 17 pull requests
Successful merges:
- #78455 (Introduce {Ref, RefMut}::try_map for optional projections in RefCell)
- #80144 (Remove giant badge in README)
- #80614 (Explain why borrows can't be held across yield point in async blocks)
- #80670 (TrustedRandomAaccess specialization composes incorrectly for nested iter::Zips)
- #80681 (Clarify what the effects of a 'logic error' are)
- #80764 (Re-stabilize Weak::as_ptr and friends for unsized T)
- #80901 (Make `x.py --color always` apply to logging too)
- #80902 (Add a regression test for #76281)
- #80941 (Do not suggest invalid code in pattern with loop)
- #80968 (Stabilize the poll_map feature)
- #80971 (Put all feature gate tests under `feature-gates/`)
- #81021 (Remove doctree::Import)
- #81040 (doctest: Reset errors before dropping the parse session)
- #81060 (Add a regression test for #50041)
- #81065 (codegen_cranelift: Fix redundant semicolon warn)
- #81069 (Add sample code for Rc::new_cyclic)
- #81081 (Add test for #34792)
Mara Bos [Sat, 16 Jan 2021 17:30:10 +0000 (17:30 +0000)]
Rollup merge of #81040 - osa1:fix_80992, r=jyn514
doctest: Reset errors before dropping the parse session
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.
Mara Bos [Sat, 16 Jan 2021 17:29:56 +0000 (17:29 +0000)]
Rollup merge of #80764 - CAD97:weak-unsized-as-ptr-again, r=RalfJung
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.
Mara Bos [Sat, 16 Jan 2021 17:29:53 +0000 (17:29 +0000)]
Rollup merge of #80681 - ChrisJefferson:logic-error-doc, r=m-ou-se
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
Mara Bos [Sat, 16 Jan 2021 17:29:51 +0000 (17:29 +0000)]
Rollup merge of #80670 - the8472:fix-zip-trusted-random-access-composition, r=m-ou-se
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)
Mara Bos [Sat, 16 Jan 2021 17:29:45 +0000 (17:29 +0000)]
Rollup merge of #78455 - udoprog:refcell-opt-map, r=KodrAus
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:
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).
bors [Sat, 16 Jan 2021 17:28:32 +0000 (17:28 +0000)]
Auto merge of #80290 - RalfJung:less-intrinsic-write, r=lcnr
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).
doctest: Reset errors before dropping the parse session
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.
Joshua Nelson [Tue, 12 Jan 2021 01:28:17 +0000 (20:28 -0500)]
Allow downloading LLVM on Windows
- 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.
bors [Sat, 16 Jan 2021 00:13:26 +0000 (00:13 +0000)]
Auto merge of #81057 - GuillaumeGomez:rollup-yl2kqst, r=GuillaumeGomez
Rollup of 6 pull requests
Successful merges:
- #77693 (Add test for #59352)
- #80515 (Improve JS performance by storing length before comparing to it in loops)
- #81030 (Update mdbook)
- #81033 (Remove useless `clean::Variant` struct)
- #81049 (inline: Round word-size cost estimates up)
- #81054 (Drop a few unneeded borrows)
Guillaume Gomez [Fri, 15 Jan 2021 22:30:53 +0000 (23:30 +0100)]
Rollup merge of #80515 - GuillaumeGomez:js-for-loop-perf, r=Nemo157,jyn514
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 :smiley: ).
Guillaume Gomez [Fri, 15 Jan 2021 22:30:51 +0000 (23:30 +0100)]
Rollup merge of #77693 - bugadani:issue-59352, r=oli-obk
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.
bors [Fri, 15 Jan 2021 21:13:35 +0000 (21:13 +0000)]
Auto merge of #80602 - tgnottingham:cratemetadata_you_aint_special, r=michaelwoerister
Remove DepKind::CrateMetadata and pre-allocation of DepNodes
Remove much of the special-case handling around crate metadata
dependency tracking by replacing `DepKind::CrateMetadata` and the
pre-allocation of corresponding `DepNodes` with on-demand invocation
of the `crate_hash` query.
bors [Fri, 15 Jan 2021 12:26:09 +0000 (12:26 +0000)]
Auto merge of #80625 - jyn514:python-what-python, r=Mark-Simulacrum
Choose the version of python at runtime (portable version)
r? `@Mark-Simulacrum`
Fixed version of https://github.com/rust-lang/rust/pull/80585. The goal is to avoid giving 'error: python3 required' when downloading LLVM from CI and instead default to python3 where possible.
This has some minor overhead when you have `python` as python2, but almost nothing compared to actually running the build.
bors [Fri, 15 Jan 2021 09:27:21 +0000 (09:27 +0000)]
Auto merge of #81035 - JohnTitor:rollup-9m03awf, r=JohnTitor
Rollup of 5 pull requests
Successful merges:
- #80254 (Don't try to add nested predicate to Rustdoc auto-trait `ParamEnv`)
- #80834 (Remove unreachable panics from VecDeque::{front/back}[_mut])
- #80944 (Use Option::map_or instead of `.map(..).unwrap_or(..)`)
- #81008 (Don't ICE when computing a layout of a generator tainted by errors)
- #81023 (Remove doctree::Variant)
Yuki Okushi [Fri, 15 Jan 2021 09:26:11 +0000 (18:26 +0900)]
Rollup merge of #80834 - bugadani:vecdeque, r=oli-obk
Remove unreachable panics from VecDeque::{front/back}[_mut]
`VecDeque`'s `front`, `front_mut`, `back` and `back_mut` methods are implemented in terms of the index operator, which causes these functions to contain [unreachable panic calls](https://rust.godbolt.org/z/MTnq1o).
This PR reimplements these methods in terms of `get[_mut]` instead.
Yuki Okushi [Fri, 15 Jan 2021 09:26:04 +0000 (18:26 +0900)]
Rollup merge of #80254 - Aaron1011:rustdoc-auto-param-env, r=estebank
Don't try to add nested predicate to Rustdoc auto-trait `ParamEnv`
Fixes #80233
We already have logic in `evaluate_predicates` that tries to add
unimplemented predicates to our `ParamEnv`. Trying to add a predicate
that already holds can lead to errors later on, since projection
will prefer trait candidates from the `ParamEnv` to predicates from an
impl.
bors [Fri, 15 Jan 2021 02:11:37 +0000 (02:11 +0000)]
Auto merge of #81027 - Xanewok:update-rls, r=calebcartwright
Update RLS and Rustfmt
Fixes #80576
Updates Rustfmt to use `rustfmt-v1.4.31` branch. Both are updated (along with `racer`) in tandem to pull in the exact same version of rustc-ap-* libraries.
projects / rust.git / log