rustbuild: Don't allow stable bootstrap from dev
I forgot to update the bootstrap compiler for the 1.23.0 release so let's make
sure it doesn't happen again!
Equivalent example for ? operator
The example with the ? operator in the documentation for try! macro was missing file.write_all.
Now all three examples are consistent.
Remove `T: Ord` bound from `BTreeSet::{is_empty, len}`
This change makes the API for `BTreeSet` more consistent with `BTreeMap`, where `BTreeMap::{is_empty, len}` don't require `T: Ord` either.
Also, it reduces the number of `impl`s for `BTreeSet`, making the generated documentation look much cleaner. Closes#47138.
cc @rust-lang/libs
Span::resolved_at and Span::located_at to combine behavior of two spans
Proc macro spans serve two mostly unrelated purposes: controlling name resolution and controlling error messages. It can be useful to mix the name resolution behavior of one span with the line/column error message locations of a different span.
In particular, consider the case of a trait brought into scope within the def_site of a custom derive. I want to invoke trait methods on the fields of the user's struct. If the field type does not implement the right trait, I want the error message to underline the corresponding struct field.
Generating the method call with the def_site span is not ideal -- it compiles and runs but error messages sadly always point to the derive attribute like we saw with Macros 1.1.
```
|
4 | #[derive(HeapSize)]
| ^^^^^^^^
```
Generating the method call with the same span as the struct field's ident or type is not correct -- it shows the right underlines but fails to resolve to the trait in scope at the def_site.
```
|
7 | bad: std:🧵:Thread,
| ^^^^^^^^^^^^^^^^^^^^^^^^
```
The correct span for the method call is one that combines the def_site's name resolution with the struct field's line/column.
```rust
field.span.resolved_at(Span::def_site())
// equivalently
Span::def_site().located_at(field.span)
```
Adding both because which one is more natural will depend on context.
Addresses https://github.com/rust-lang/rust/issues/38356#issuecomment-354947143. r? @jseyfried
Use the right TLS model for CloudABI.
CloudABI doesn't do dynamic linking. For this reason, there is no need
to handle any other TLS model than local-exec. CloudABI's C library
doesn't provide a __tls_get_addr() function to do Dynamic TLS.
By forcing local-exec to be used here, we ensure that we don't generate
function calls to __tls_get_addr().
Disable printing of error message on file descriptor 2 on CloudABI.
As CloudABI is a capability-based runtime environment, file descriptors
are the mechanism that grants rights to a process. These file
descriptors may be passed into processes on startup using a utility
called cloudabi-run. Unlike the POSIX shell, cloudabi-run does not
follow the UNIX model where file descriptors 0, 1 and 2 represent stdin,
stdout and stderr. There can be arbitrary many (or few) file descriptors
that can be provided. For this reason, CloudABI's C library also doesn't
define STD*_FILENO. liblibc should also not declare these.
Disable the code in liballoc_system that tries to print error messages
over file descriptor 2. For now, let's keep this function quiet. We'll
see if we can think of some other way to log this in the future.
Correct a few stability attributes
* The extra impls for `ManuallyDrop` were added in #44310 which was only stabilised in 1.22.0.
* The impls for `SliceIndex` were stabilised in #43373 but as `RangeInclusive` and `RangeToInclusive` are still unstable the impls should remain unstable.
* The `From` impls for atomic integers were added in #45610 but most atomic integers are still unstable.
* The `shared_from_slice2` impls were added in #45990 but they won't be stable until 1.24.0.
* The `Mutex` and `RwLock` impls were added in #46082 but won't be stable until 1.24.0.
Allow non-alphabetic underscores in camel case
Certain identifiers, such as `X86_64`, cannot currently be unambiguously represented in camel case (`X8664`, `X86_64`, `X8_664`, etc. are all transformed to the same identifier). This change relaxes the rules so that underscores are permitted between two non-alphabetic characters under `#[forbid(non_camel_case_types)]`. Fixes#34633 and fixes#41621.
CloudABI uses LLVM's libunwind for stack unwinding. There was a small
bug that went by unnoticed, namely that it was not built with -fno-rtti.
This caused it to (indirectly) depend on the entire C++ runtime.
Now that that issue has been resolved, it is also perfectly fine to make
use of this library for programming languages other than C++.
* Bump the release version to 1.25
* Bump the bootstrap compiler to the recent beta
* Allow using unstable rustdoc features on beta - this fix has been applied to
the beta branch but needed to go to the master branch as well.
Force appropriate extension when converting from int to ptr #43291Fixes#43291.
Looking for feedback if I've missed something and/or need to add more tests.
@eddyb @retep998 @nagisa @oli-obk
Reword reason for move note
On move errors, when encountering an enum variant, be more ambiguous and do not refer to the type on the cause note, to avoid referring to `(maybe as std::prelude::v1::Some).0`, and instead refer to `the value`.
Sidesteps part of the problem with #41962:
```
error[E0382]: use of partially moved value: `maybe`
--> file.rs:5:30
|
5 | if let Some(thing) = maybe {
| ----- ^^^^^ value used here after move
| |
| value moved here
= note: move occurs because the value has type `std::vec::Vec<bool>`, which does not implement the `Copy` trait
error[E0382]: use of moved value: `(maybe as std::prelude::v1::Some).0`
--> file.rs:5:21
|
5 | if let Some(thing) = maybe {
| ^^^^^ value moved here in previous iteration of loop
= note: move occurs because the value has type `std::vec::Vec<bool>`, which does not implement the `Copy` trait
error: aborting due to 2 previous errors
```
Previous discussion: #44360
r? @arielb1
NLL fixes
First, introduce pre-statement effects to dataflow to fix#46875. Edge dataflow effects might make that redundant, but I'm not sure of the best way to integrate them with liveness etc., and if this is a hack, this is one of the cleanest hacks I've seen.
And I want a small fix to avoid the torrent of bug reports.
Second, fix linking of projections to fix#46974
r? @pnkfelix
