libunwind fix and cleanup
Fix:
1. "system-llvm-libunwind" now only skip build-script for linux target
2. workaround from https://github.com/rust-lang/rust/pull/65972 is not needed, upstream fix it in 68c50708d1 ( LLVM 11 )
3. remove code for MSCV and Apple in `compile()`, as they are not used
4. fix https://github.com/rust-lang/rust/issues/69222 , compile c files and cpp files in different config
5. fix conditional compilation for musl target.
6. fix that x86_64-fortanix-unknown-sgx don't link libunwind built in build-script into rlib
Add inline attr to CString::into_inner so it can optimize out NonNull checks
It seems that currently if you convert any of the standard library's container to a pointer and then to a NonNull pointer, all will optimize out the NULL check except `CString`(https://godbolt.org/z/YPKW9G5xn),
because for some reason `CString::into_inner` isn't inlined even though it's a private function that should compile into a simple `mov` instruction.
Adding a simple `#[inline]` attribute solves this, code example:
```rust
use std::ffi::CString;
use std::ptr::NonNull;
pub fn cstring_nonull(mut n: CString) -> NonNull<i8> {
NonNull::new(CString::into_raw(n)).unwrap()
}
```
assembly before:
```asm
__ZN3wat14cstring_nonull17h371c755bcad76294E:
.cfi_startproc
pushq %rbp
.cfi_def_cfa_offset 16
.cfi_offset %rbp, -16
movq %rsp, %rbp
.cfi_def_cfa_register %rbp
callq __ZN3std3ffi5c_str7CString10into_inner17h28ece07b276e2878E
testq %rax, %rax
je LBB0_2
popq %rbp
retq
LBB0_2:
leaq l___unnamed_1(%rip), %rdi
leaq l___unnamed_2(%rip), %rdx
movl $43, %esi
callq __ZN4core9panicking5panic17h92a83fa9085a8f73E
.cfi_endproc
.section __TEXT,__const
l___unnamed_1:
.ascii "called `Option::unwrap()` on a `None` value"
l___unnamed_3:
.ascii "wat.rs"
.section __DATA,__const
.p2align 3
l___unnamed_2:
.quad l___unnamed_3
.asciz "\006\000\000\000\000\000\000\000\006\000\000\000(\000\000"
```
Assembly after:
```asm
__ZN3wat14cstring_nonull17h9645eb9341fb25d7E:
.cfi_startproc
pushq %rbp
.cfi_def_cfa_offset 16
.cfi_offset %rbp, -16
movq %rsp, %rbp
.cfi_def_cfa_register %rbp
movq %rdi, %rax
popq %rbp
retq
.cfi_endproc
```
(Related discussion on zulip: https://rust-lang.zulipchat.com/#narrow/stream/219381-t-libs/topic/NonNull.20From.3CBox.3CT.3E.3E)
Remove Iterator #[rustc_on_unimplemented]s that no longer apply.
Now that `IntoIterator` is implemented for arrays, all the `rustc_on_unimplemented` for arrays of ranges (e.g. `for _ in [1..3] {}`) no longer apply, since they are now valid Rust.
Separated these from #85670, because we should discuss a potential new (clippy?) lint for these.
Until Rust 1.52, `for _ in [1..3] {}` produced:
```
error[E0277]: `[std::ops::Range<{integer}>; 1]` is not an iterator
--> src/main.rs:2:14
|
2 | for _ in [1..3] {}
| ^^^^^^ if you meant to iterate between two values, remove the square brackets
|
= help: the trait `std::iter::Iterator` is not implemented for `[std::ops::Range<{integer}>; 1]`
= note: `[start..end]` is an array of one `Range`; you might have meant to have a `Range` without the brackets: `start..end`
= note: required by `std::iter::IntoIterator::into_iter`
```
But in Rust 1.53 and later, it compiles fine. It iterates over the array by value, for one iteration with the element `1..3`.
This is probably a mistake, which is no longer caught. Should we have a lint for it? Should Clippy have a lint for it?
cc ```@estebank``` ```@flip1995```
cc https://github.com/rust-lang/rust/issues/84513
Update cc
Recent commits have improved `cc`'s finding of MSVC tools on Windows. In particular it should help to address these issues: #83043 and #43468
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
stabilize member constraints
Stabilizes the use of "member constraints" in solving `impl Trait` bindings. This is a step towards stabilizing a "MVP" of "named impl Trait".
# Member constraint stabilization report
| Info | |
| --- | --- |
| Tracking issue | [rust-lang/rust#61997](https://github.com/rust-lang/rust/issues/61997) |
| Implementation history | [rust-lang/rust#61775] |
| rustc-dev-guide coverage | [link](https://rustc-dev-guide.rust-lang.org/borrow_check/region_inference/member_constraints.html) |
| Complications | [rust-lang/rust#61773] |
[rust-lang/rust#61775]: https://github.com/rust-lang/rust/pull/61775
[rust-lang/rust#61773]: https://github.com/rust-lang/rust/issues/61773
## Background
Member constraints are an extension to our region solver that was introduced to make async fn region solving tractable. There are used in situations like the following:
```rust
fn foo<'a, 'b>(...) -> impl Trait<'a, 'b> { .. }
```
The problem here is that every region R in the hidden type must be equal to *either* `'a` *or* `'b` (or `'static`). This cannot be expressed simply via 'outlives constriants' like `R: 'a`. Therefore, we introduce a 'member constraint' `R member of ['a, 'b]`.
These constraints were introduced in [rust-lang/rust#61775]. At the time, we kept them feature gated and used them only for `impl Trait` return types that are derived from `async fn`. The intention, however, was always to support them in other contexts once we had time to gain more experience with them.
**In the time since their introduction, we have encountered no surprises or bugs due to these member constraints.** They are tested extensively as part of every async function that involves multiple unrelated lifetimes in its arguments.
## Tests
The behavior of member constraints is covered by the following tests:
* [`src/test/ui/async-await/multiple-lifetimes`](20e032e650/src/test/ui/async-await/multiple-lifetimes) -- tests using the async await, which are mostly already stabilized
* [`src/test/ui/impl-trait/multiple-lifetimes.rs`](20e032e650/src/test/ui/impl-trait/multiple-lifetimes.rs)
* [`src/test/ui/impl-trait/multiple-lifetimes/ordinary-bounds-unsuited.rs`](20e032e650/src/test/ui/impl-trait/multiple-lifetimes/ordinary-bounds-unsuited.rs)
* [`src/test/ui/async-await/multiple-lifetimes/ret-impl-trait-fg.rs`](20e032e650/src/test/ui/async-await/multiple-lifetimes/ret-impl-trait-fg.rs)
* [`src/test/ui/async-await/multiple-lifetimes/ret-impl-trait-one.rs`](20e032e650/src/test/ui/async-await/multiple-lifetimes/ret-impl-trait-one.rs)
These tests cover a number of scenarios:
* `-> implTrait<'a, 'b>` with unrelated lifetimes `'a` and `'b`, as described above
* `async fn` that returns an `impl Trait` like the previous case, which desugars to a kind of "nested" impl trait like `impl Future<Output = impl Trait<'a, 'b>>`
## Potential concerns
There is a potential interaction with `impl Trait` on local variables, described in [rust-lang/rust#61773]. The challenge is that if you have a program like:
```rust=
trait Foo<'_> { }
impl Foo<'_> for &u32 { }
fn bar() {
let x: impl Foo<'_> = &44; // let's call the region variable for `'_` `'1`
}
```
then we would wind up with `'0 member of ['1, 'static]`, where `'0` is the region variable in the hidden type (`&'0 u32`) and `'1` is the region variable in the bounds `Foo<'1>`. This is tricky because both `'0` and `'1` are being inferred -- so making them equal may have other repercussions.
That said, `impl Trait` in bindings are not stable, and the implementation is pretty far from stabilization. Moreover, the difficulty highlighted here is not due to the presence of member constraints -- it's inherent to the design of the language. In other words, stabilizing member constraints does not actually cause us to accept anything that would make this problem any harder.
So I don't see this as a blocker to stabilization of member constraints; it is potentially a blocker to stablization of `impl trait` in let bindings.
E0599 suggestions and elision of generic argument if no canditate is found
fixes#81576
changes: In error E0599 (method not found) generic argument are eluded if the method was not found anywhere. If the method was found in another inherent implementation suggest that it was found elsewhere.
Example
```rust
struct Wrapper<T>(T);
struct Wrapper2<T> {
x: T,
}
impl Wrapper2<i8> {
fn method(&self) {}
}
fn main() {
let wrapper = Wrapper(i32);
wrapper.method();
let wrapper2 = Wrapper2{x: i32};
wrapper2.method();
}
```
```
Error[E0599]: no method named `method` found for struct `Wrapper<_>` in the current scope
....
error[E0599]: no method named `method` found for struct `Wrapper2<i32>` in the current scope
...
= note: The method was found for Wrapper2<i8>.
```
I am not very happy with the ```no method named `test` found for struct `Vec<_, _>` in the current scope```. I think it might be better to show only one generic argument `Vec<_>` if there is a default one. But I haven't yet found a way to do that,
Optimize linkchecker and add report.
This makes three changes to the linkchecker:
* Adds a report displayed after it finishes.
* Improves the performance by caching all filesystem access. The linkchecker can take over a minute to run on some systems, and this should make it about 2-3 times faster.
* Added a few tests.
Add `TrustedRandomAccess` specialization for `Vec::extend()`
This should do roughly the same as the `TrustedLen` specialization but result in less IR by using `__iterator_get_unchecked`
instead of `Iterator::for_each`
Conflicting specializations are manually prioritized by grouping them under yet another helper trait.
Fix typo in core::array::IntoIter comment
Saw a small typo reading some internal comments and decided to just throw this up to fix it for future readers.
Remove num_as_ne_bytes feature
From the discussion in #76976, it is determined that eventual results of the safe transmute work as a more general mechanism will let these conversions happen in safe code without needing specialized methods.
Merging this PR closes#76976 and resolves#64464. Several T-libs members have raised their opinion that it doesn't pull its weight as a standalone method, and so we should not track it as a specific thing to add.
fix `matches!` and `assert_matches!` on edition 2021
Previously this code failed to compile on edition 2021. [(Playground)](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=53960f2f051f641777b9e458da747707)
```rust
fn main() {
matches!((), ());
}
```
```
Compiling playground v0.0.1 (/playground)
error: `$pattern:pat` may be followed by `|`, which is not allowed for `pat` fragments
|
= note: allowed there are: `=>`, `,`, `=`, `if` or `in`
error: aborting due to previous error
error: could not compile `playground`
To learn more, run the command again with --verbose.
```
Post-monomorphization errors traces MVP
This PR works towards better diagnostics for the errors encountered in #85155 and similar.
We can encounter post-monomorphization errors (PMEs) when collecting mono items. The current diagnostics are confusing for these cases when they happen in a dependency (but are acceptable when they happen in the local crate).
These kinds of errors will be more likely now that `stdarch` uses const generics for its intrinsics' immediate arguments, and validates these const arguments with a mechanism that triggers such PMEs.
(Not to mention that the errors happen during codegen, so only when building code that actually uses these code paths. Check builds don't trigger them, neither does unused code)
So in this PR, we detect these kinds of errors during the mono item graph walk: if any error happens while collecting a node or its neighbors, we print a diagnostic about the current collection step, so that the user has at least some context of which erroneous code and dependency triggered the error.
The diagnostics for issue #85155 now have this note showing the source of the erroneous const argument:
```
note: the above error was encountered while instantiating `fn std::arch::x86_64::_mm_blend_ps::<51_i32>`
--> issue-85155.rs:11:24
|
11 | let _blended = _mm_blend_ps(a, b, 0x33);
| ^^^^^^^^^^^^^^^^^^^^^^^^
error: aborting due to previous error
```
Note that #85155 is a reduced version of a case happening in the wild, to indirect users of the `rustfft` crate, as seen in https://github.com/ejmahler/RustFFT/issues/74. The crate had a few of these out-of-range immediates. Here's how the diagnostics in this PR would have looked on one of its examples before it was fixed:
<details>
```
error[E0080]: evaluation of constant value failed
--> ./stdarch/crates/core_arch/src/macros.rs:8:9
|
8 | assert!(IMM >= MIN && IMM <= MAX, "IMM value not in expected range");
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ the evaluated program panicked at 'IMM value not in expected range', ./stdarch/crates/core_arch/src/macros.rs:8:9
|
= note: this error originates in the macro `$crate::panic::panic_2015` (in Nightly builds, run with -Z macro-backtrace for more info)
note: the above error was encountered while instantiating `fn _mm_blend_ps::<51_i32>`
--> /tmp/RustFFT/src/avx/avx_vector.rs:1314:23
|
1314 | let blended = _mm_blend_ps(rows[0], rows[2], 0x33);
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
note: the above error was encountered while instantiating `fn _mm_permute_pd::<5_i32>`
--> /tmp/RustFFT/src/avx/avx_vector.rs:1859:9
|
1859 | _mm_permute_pd(self, 0x05)
| ^^^^^^^^^^^^^^^^^^^^^^^^^^
note: the above error was encountered while instantiating `fn _mm_permute_pd::<15_i32>`
--> /tmp/RustFFT/src/avx/avx_vector.rs:1863:32
|
1863 | (_mm_movedup_pd(self), _mm_permute_pd(self, 0x0F))
| ^^^^^^^^^^^^^^^^^^^^^^^^^^
error: aborting due to previous error
For more information about this error, try `rustc --explain E0080`.
error: could not compile `rustfft`
To learn more, run the command again with --verbose.
```
</details>
I've developed and discussed this with them, so maybe r? `@oli-obk` -- but feel free to redirect to someone else of course.
(I'm not sure we can say that this PR definitely closes issue 85155, as it's still unclear exactly which diagnostics and information would be interesting to report in such cases -- and we've discussed printing backtraces before. I have prototypes of some complete and therefore noisy backtraces I showed Oli, but we decided to not include them in this PR for now)
Disallow shadowing const parameters
This pull request fixes#85348. Trying to shadow a `const` parameter as follows:
```rust
fn foo<const N: i32>() {
let N @ _ = 0;
}
```
currently causes an ICE. With my changes, I get:
```
error[E0530]: let bindings cannot shadow const parameters
--> test.rs:2:9
|
1 | fn foo<const N: i32>() {
| - the const parameter `N` is defined here
2 | let N @ _ = 0;
| ^ cannot be named the same as a const parameter
error: aborting due to previous error
```
This is the same error you get when trying to shadow a constant:
```rust
const N: i32 = 0;
let N @ _ = 0;
```
```
error[E0530]: let bindings cannot shadow constants
--> src/lib.rs:3:5
|
2 | const N: i32 = 0;
| ----------------- the constant `N` is defined here
3 | let N @ _ = 0;
| ^ cannot be named the same as a constant
error: aborting due to previous error
```
The reason for disallowing shadowing in both cases is described [here](https://github.com/rust-lang/rust/issues/33118#issuecomment-233962221) (the comment there only talks about constants, but the same reasoning applies to `const` parameters).
Update cargo
7 commits in 070e459c2d8b79c5b2ac5218064e7603329c92ae..e931e4796b61de593aa1097649445e535c9c7ee0
2021-05-11 18:12:23 +0000 to 2021-05-24 16:17:27 +0000
- Add `cargo:rustc-link-arg-bin` flag. (rust-lang/cargo#9486)
- Add a cargo-doc.browser config option (rust-lang/cargo#9473)
- Fix bug when with resolver = "1" non-virtual package was allowing unknown features (rust-lang/cargo#9437)
- Add GitHub link to contributor guide. (rust-lang/cargo#9493)
- Add temporary fix for rustup on windows in CI. (rust-lang/cargo#9498)
- 3 typos and some capitalization (rust-lang/cargo#9495)
- fix 6 typos (rust-lang/cargo#9484)
Demote `ControlFlow::{from|into}_try` to `pub(crate)`
They have mediocre names and non-obvious semantics, so personally I don't think they're worth trying to stabilize, and thus might as well just be internal (they're used for convenience in iterator adapters), not something shown in the rustdocs.
I don't think anyone actually wanted to use them outside `core` -- they just got made public-but-unstable along with the whole type in https://github.com/rust-lang/rust/pull/76204 that promoted `LoopState` from an internal type to the exposed `ControlFlow` type.
cc https://github.com/rust-lang/rust/issues/75744, the tracking issue they mention.
cc https://github.com/rust-lang/rust/pull/85608, the PR where I'm proposing stabilizing the type.
Fix pointer provenance in <[T]>::copy_within
Previously the `self.as_mut_ptr()` invalidated the pointer created by the first `self.as_ptr()`. This also triggered miri when run with `-Zmiri-track-raw-pointers`
Fix bootstrap using host exe suffix for cargo
When attempting to cross compile rustc (for example, from Linux to Windows) and tell it to build cargo/tools, the following error occurs:
```
thread 'main' panicked at 'src.symlink_metadata() failed with No such file or directory (os error 2)', src/bootstrap/lib.rs:1196:24
```
Relevant part of stack trace:
<details>
```
2: bootstrap::Build::copy
at ./src/bootstrap/lib.rs:1196:24
3: <bootstrap::tool::ToolBuild as bootstrap::builder::Step>::run
at ./src/bootstrap/tool.rs:220:13
```
</details>
If I add `-vvv` (which seemed to be the recommended course for debugging a similar issue according to [zulip logs](https://zulip-archive.rust-lang.org/182449tcompilerhelp/19655failedtobootstrap.html)), it shows:
```
Copy ".../rust/build/x86_64-unknown-linux-gnu/stage2-tools/x86_64-pc-windows-gnu/release/cargo" to ".../rust/build/x86_64-unknown-linux-gnu/stage2-tools-bin/cargo"
```
and when taking a look at the contents of `build/x86_64-unknown-linux-gnu/stage2-tools/x86_64-pc-windows-gnu/release` it contains `cargo.exe`, but no `cargo`.
I tried to study the surrounding code to make sure this was the intended behavior and while I can't be 100% certain, it does seem that using the exe suffix for the `compiler.host` target instead of the `target` target won't have the desired behavior when cross-compiling to/from Windows.
doc: clarify Mutex::try_lock, etc. errors
Clarify error returns from Mutex::try_lock, RwLock::try_read,
RwLock::try_write to make it more obvious that both poisoning
and the lock being already locked are possible errors.
Avoid CJK legacy fonts in Windows
As metioned in #84035, the default serif CJK font in Windows is meh-looking.
To avoid this, we should use sans-serif font or provide CJK glyph supported font in `rustdoc.css`.
Bring back `x86_64-sun-solaris` target to rustup
Change #82216 removed now deprecated target `x86_64-sun-solaris` from CI, thus making it no longer possible to use `$ rustup target add x86_64-sun-solaris` to install given target (see #85098 for details). Since there should be a period of time between the deprecation and removal, this PR brings it back (while keeping the new one as well).
Please, correct me if I am wrong; my assumption that these Docker scripts are being used to build artifacts later used by `rustup` might be incorrect.
Closes#85098.
Weak's type parameter may dangle on drop
Way back in 34076bc0c9, #\[may_dangle\] was added to Rc\<T\> and Arc\<T\>'s Drop impls. That appears to have been because a test added in #28929 used Arc and Rc with dangling references at drop time. However, Weak was not covered by that test, and therefore no #\[may_dangle\] was forced to be added at the time.
As far as dropping, Weak has *even less need* to interact with the T than Rc and Arc do. Roughly speaking #\[may_dangle\] describes generic parameters that the outer type's Drop impl does not interact with except by possibly dropping them; no other interaction (such as trait method calls on the generic type) is permissible. It's clear this applies to Rc's and Arc's drop impl, which sometimes drop T but otherwise do not interact with one. It applies *even more* to Weak. Dropping a Weak cannot ever cause T's drop impl to run. Either there are strong references still in existence, in which case better not drop the T. Or there are no strong references still in existence, in which case the T would already have been dropped previously by the drop of the last strong count.
