mem-categorization, coherence fix
make mem-categorization use adjusted type for patterns: Fixes#49631
do not propagate `Err` when determing causal info: Fixes#48728
r? @eddyb
two-phase borrows: support multiple activations in one statement
The need for this has arisen since the introduction of two-phase borrows on
method autorefs in #49348. r'ing @pnkfelix to keep things off Niko's plate so he can make this redundant, and @pnkfelix is familiar with the code.
Fixes#49635Fixes#49662
r? @pnkfelix
In intercrate mode, if we determine that a particular `T: Trait` is
unknowable, we sometimes also go and get extra causal information. An
errant `?` was causing us to propagate an error found in that process
out as if `T: Trait` was not unknowable but rather not provable. This
led to an ICE.
Expand macros in `extern {}` blocks
This permits macro and proc-macro and attribute invocations (the latter only with the `proc_macro` feature of course) in `extern {}` blocks, gated behind a new `macros_in_extern` feature.
A tracking issue is now open at #49476closes#48747
Rollup of 25 pull requests
Successful merges:
- #49179 (Handle future deprecation annotations )
- #49512 (Add support for variant and types fields for intra links)
- #49515 (fix targetted value background)
- #49516 (Add missing anchor for union type fields)
- #49532 (Add test for rustdoc ignore test)
- #49533 (Add #[must_use] to a few standard library methods)
- #49540 (Fix miri Discriminant() for non-ADT)
- #49559 (Introduce Vec::resize_with method (see #41758))
- #49570 (avoid IdxSets containing garbage above the universe length)
- #49577 (Stabilize String::replace_range)
- #49599 (Fix typo)
- #49603 (Fix url for intra link provided method)
- #49607 (Stabilize iterator methods in 1.27)
- #49609 (run-pass/attr-stmt-expr: expand test cases)
- #49612 (Fix "since" version for getpid feature.)
- #49618 (Fix build error when compiling libcore for 16bit targets)
- #49619 (tweak core::fmt docs)
- #49637 (Stabilize parent_id())
- #49639 (Update Cargo)
- #49628 (Re-write the documentation index)
- #49594 (Add some performance guidance to std::fs and std::io docs)
- #49625 (miri: add public alloc_kind accessor)
- #49634 (Add a test for the fix to issue #43058)
- #49641 (Regression test for #46314)
- #49547 (Unignore borrowck test)
Failed merges:
Better document the implementors of Clone and Copy
There are two parts to this change. The first part is a change to the compiler and to the standard library (specifically, libcore) to allow implementations of `Clone` and `Copy` to be written for a subset of builtin types. By adding these implementations to libcore, they now show up in the documentation. This is a [breaking-change] for users of `#![no_core]`, because they will now have to supply their own copy of the implementations of `Clone` and `Copy` that were added in libcore.
The second part is purely a documentation change to document the other implementors of `Clone` and `Copy` that cannot be described in Rust code (yet) and are thus provided by the compiler.
Fixes#25893
Extend two-phase borrows to apply to method receiver autorefs
Fixes#48598 by permitting two-phase borrows on the autorefs created when functions and methods.
rustc: Forbid #[inline(always)] with #[target_feature]
Once a target feature is enabled for a function that means that it in general
can't be inlined into other functions which don't have that target feature
enabled. This can cause both safety and LLVM issues if we were to actually
inline it, so `#[inline(always)]` both can't be respected and would be an error
if we did so!
Today LLVM doesn't inline functions with different `#[target_feature]`
annotations, but it turns out that if one is tagged with `#[inline(always)]`
it'll override this and cause scary LLVM error to arise!
This commit fixes this issue by forbidding these two attributes to be used in
conjunction with one another.
Closesrust-lang-nursery/stdsimd#404
Once a target feature is enabled for a function that means that it in general
can't be inlined into other functions which don't have that target feature
enabled. This can cause both safety and LLVM issues if we were to actually
inline it, so `#[inline(always)]` both can't be respected and would be an error
if we did so!
Today LLVM doesn't inline functions with different `#[target_feature]`
annotations, but it turns out that if one is tagged with `#[inline(always)]`
it'll override this and cause scary LLVM error to arise!
This commit fixes this issue by forbidding these two attributes to be used in
conjunction with one another.
cc rust-lang-nursery/stdsimd#404
Add implementations of `Clone` and `Copy` for some primitive types to
libcore so that they show up in the documentation. The concerned types
are the following:
* All primitive signed and unsigned integer types (`usize`, `u8`, `u16`,
`u32`, `u64`, `u128`, `isize`, `i8`, `i16`, `i32`, `i64`, `i128`);
* All primitive floating point types (`f32`, `f64`)
* `bool`
* `char`
* `!`
* Raw pointers (`*const T` and `*mut T`)
* Shared references (`&'a T`)
These types already implemented `Clone` and `Copy`, but the
implementation was provided by the compiler. The compiler no longer
provides these implementations and instead tries to look them up as
normal trait implementations. The goal of this change is to make the
implementations appear in the generated documentation.
For `Copy` specifically, the compiler would reject an attempt to write
an `impl` for the primitive types listed above with error `E0206`; this
error no longer occurs for these types, but it will still occur for the
other types that used to raise that error.
The trait implementations are guarded with `#[cfg(not(stage0))]` because
they are invalid according to the stage0 compiler. When the stage0
compiler is updated to a revision that includes this change, the
attribute will have to be removed, otherwise the stage0 build will fail
because the types mentioned above no longer implement `Clone` or `Copy`.
For type variants that are variadic, such as tuples and function
pointers, and for array types, the `Clone` and `Copy` implementations
are still provided by the compiler, because the language is not
expressive enough yet to be able to write the appropriate
implementations in Rust.
The initial plan was to add `impl` blocks guarded by `#[cfg(dox)]` to
make them apply only when generating documentation, without having to
touch the compiler. However, rustdoc's usage of the compiler still
rejected those `impl` blocks.
This is a [breaking-change] for users of `#![no_core]`, because they
will now have to supply their own implementations of `Clone` and `Copy`
for the primitive types listed above. The easiest way to do that is to
simply copy the implementations from `src/libcore/clone.rs` and
`src/libcore/marker.rs`.
Fixes#25893
Stabilize the copy_closures and clone_closures features
In addition to the `Fn*` family of traits, closures now implement `Copy` (and similarly `Clone`) if all of the captures do.
Tracking issue: https://github.com/rust-lang/rust/issues/44490
Stabilize termination_trait, split out termination_trait_test
For #48453.
First time contribution, so I'd really appreciate any feedback on how this PR can be better.
Not sure exactly what kind of documentation update is needed. If there is no PR to update the reference, I can try doing that this week as I have time.
support elision in impl headers
You can now do things like:
```
impl MyTrait<'_> for &u32 { ... }
```
Each `'_` or elided lifetime is a fresh parameter. `'_` and elision are still not permitted in associated type values. (Plausibly we could support that if there is a single input lifetime.) The original lifetime elision RFC was a bit unclear on this point: [as documented here, I think this is the correct interpretation, both because it fits existing impls and it's most analogous to the behavior in fns](https://github.com/rust-lang/rust/issues/15872#issuecomment-338700138).
We do not support elision with deprecated forms:
```
impl MyTrait for std::cell::Ref<u32> { } // ERROR
```
Builds on the in-band lifetime stuff.
r? @cramertj
Fixes#15872
