incr.comp.: Fix two problems with HIR hashing.
Fixes https://github.com/rust-lang/rust/issues/45469.
This PR fixes two small problems:
* Overflow checks are always enabled in a constant context, so we need to hash spans of potentially overflowing operations. (Eventually I'd like to handle spans differently so we don't have to make HIR hashing know so much about things like this.)
* The HIR map collector had a bug where it would assign the `DepNode::Hir` instead of the corresponding `DepNode::HirBody` in some nested contexts.
r? @nikomatsakis
Fix duplicate display of error E0502
Ref. Repeated "mutable/immutable borrow" error messages #42106.
This PR modifies the return type of [`report_error_if_loan_conflicts_with_restriction`](0f0f5db465/src/librustc_borrowck/borrowck/check_loans.rs (L398-L403)) so the result can be checked in [`report_error_if_loans_conflict`](0f0f5db465/src/librustc_borrowck/borrowck/check_loans.rs (L377-L396)). This is done to prevent displaying a duplicate of the error message E0502 which is referenced in #42106.
The output of compiling:
```rust
fn do_something<T>(collection: &mut Vec<T>) {
let _a = &collection;
collection.swap(1, 2);
}
fn main() {}
```
is now
```bash
$ rustc src/test/compile-fail/issue-42106.rs
error[E0502]: cannot borrow `*collection` as mutable because `collection` is also borrowed as immutable
--> src/test/compile-fail/issue-42106.rs:13:5
|
12 | let _a = &collection;
| ---------- immutable borrow occurs here
13 | collection.swap(1, 2);
| ^^^^^^^^^^ mutable borrow occurs here
14 | }
| - immutable borrow ends here
error: aborting due to 2 previous errors
```
r? @estebank
Improve std::process module docs
Addresses part of #29370
I've changed the first `cat` example to a "Hello World" example involving echo, and I've also added another example showing how to pipe output. I'm still working on the module-level description.
For now, I'd like feedback on the examples.
r? @steveklabnik
Update the book for a fix to the print button
Fixes#45552.
Brings in recent improvements in the text that we've made recently as well.
r? @steveklabnik
ci: Upgrade Android SDK/NDK and refactor to use sdkmanager/avdmanager.
* SDK tools is upgraded to 27.0.0.
* Stopped using the deprecated `android` tool, instead use the recommended `sdkmanager` and `avdmanager`.
* NDK is upgrade to r15c.
The r15 series [dropped support for android-9](https://github.com/android-ndk/ndk/wiki/Changelog-r15) (2.3 / Gingerbread), the minimal supported version is now android-14 (4.0 / Ice Cream Sandwich).
r? @alexcrichton
(WIP, haven't confirmed if the change really works yet)
* SDK tools is upgraded to 27.0.0.
- Refactored to use `sdkmanager`/`avdmanager` instead of the deprecated
`android` tool.
* The Java version used by Android SDK is downgraded to OpenJDK-8, in order
to download the SDK through HTTPS.
* NDK is upgrade to r15c.
- Dropped support for android-9 (2.3 / Gingerbread), the minimal
supported version is now android-14 (4.0 / Ice Cream Sandwich).
- Changed the default Android compiler from GCC to clang.
- For details of change introduced by NDK r15, see
https://github.com/android-ndk/ndk/wiki/Changelog-r15.
Avoid repetition on “use of unstable library feature 'rustc_private'”
This PR fixes the error by only emitting it when the span contains a real file (is not inside a macro) - and making sure it's emitted only once per span.
The first check was needed because spans-within-macros seem to differ a lot and "fixing" them to the real location is not trivial (and the method that does this is private to another module). It also feels like there always will be an error on import, with the real file name, so not sure there's a point to re-emit the same error at macro use.
Fix#44953.
Implement RFC 1861: Extern types
A few notes :
- Type parameters are not supported. This was an unresolved question from the RFC. It is not clear how useful this feature is, and how variance should be treated. This can be added in a future PR.
- `size_of_val` / `align_of_val` can be called with extern types, and respectively return 0 and 1. This differs from the RFC, which specified that they should panic, but after discussion with @eddyb on IRC this seems like a better solution.
If/when a `DynSized` trait is added, this will be disallowed statically.
- Auto traits are not implemented by default, since the contents of extern types is unknown. This means extern types are `!Sync`, `!Send` and `!Freeze`. This seems like the correct behaviour to me.
Manual `unsafe impl Sync for Foo` is still possible.
- This PR allows extern type to be used as the tail of a struct, as described by the RFC :
```rust
extern {
type OpaqueTail;
}
#[repr(C)]
struct FfiStruct {
data: u8,
more_data: u32,
tail: OpaqueTail,
}
```
However this is undesirable, as the alignment of `tail` is unknown (the current PR assumes an alignment of 1). Unfortunately we can't prevent it in the general case as the tail could be a type parameter :
```rust
#[repr(C)]
struct FfiStruct<T: ?Sized> {
data: u8,
more_data: u32,
tail: T,
}
```
Adding a `DynSized` trait would solve this as well, by requiring tail fields to be bound by it.
- Despite being unsized, pointers to extern types are thin and can be casted from/to integers. However it is not possible to write a `null<T>() -> *const T` function which works with extern types, as I've explained here : https://github.com/rust-lang/rust/issues/43467#issuecomment-321678621
- Trait objects cannot be built from extern types. I intend to support it eventually, although how this interacts with `DynSized`/`size_of_val` is still unclear.
- The definition of `c_void` is unmodified
