Move mini-macro to tests/ui/auxilary
changelog: none
Merges `/mini-macro` into `/tests/ui/auxilary/proc_macro_derive.rs`.
The mini-macro crate is an artifact of the distant past. A lot has changed (#2284) and it doesn't make sense as a top-level crate anymore. Especially since we can use the auxilary folder to accompolish the same thing.
Due to a performance regression that didn't show up in the original perf run
this reverts commit 9111b8ae9793f18179a1336417618fc07a9cac85, reversing
changes made to 9a700d2947f2d7f97a2c0dfca3117a8dcc255bdd.
Enable Vec's calloc optimization for Option<NonZero>
Someone on discord noticed that `vec![None::<NonZeroU32>; N]` wasn't getting the optimization, so here's a PR 🙃
We can certainly do this in the standard library because we know for sure this is ok, but I think it's also a necessary consequence of documented guarantees like those in https://doc.rust-lang.org/std/option/#representation and https://doc.rust-lang.org/core/num/struct.NonZeroU32.html
It feels weird to do this without adding a test, but I wasn't sure where that would belong. Is it worth adding codegen tests for these?
Fix missing_docs_in_private_items false negative
changelog: Fix [`missing_docs_in_private_items`] false negative when the item has any `#[name = "value"]` attribute
Closes#7247 (decided not to use the rustc method since it calls `Session::check_name`, which is for rustc only)
Fix allow on some statement lints
changelog: Fix `#[allow(..)]` over statements for [`needless_collect`], [`short_circuit_statement`] and [`unnecessary_operation`]
Fixes#7171Fixes#7202
Add avoid_breaking_exported_api config option
changelog: Add `avoid_breaking_exported_api` config option for [`enum_variant_names`], [`large_types_passed_by_value`], [`trivially_copy_pass_by_ref`], [`unnecessary_wraps`], [`upper_case_acronyms`] and [`wrong_self_convention`].
changelog: Deprecates [`pub_enum_variant_names`] and [`wrong_pub_self_convention`] as the non-pub variants are now configurable.
changelog: Fix various false negatives for `pub` items that are not exported from the crate.
A couple changes to late passes in order to use `cx.access_levels.is_exported` rather than `item.vis.kind.is_pub`.
I'm not sure how to better document the config option or lints that are (not) affected (see comments in #6806). Suggestions are welcome. cc `@rust-lang/clippy`
I added `/clippy.toml` to use the config internally and `/tests/clippy.toml` to maintain a default config in ui tests.
Closes#6806Closes#4504
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.
While stdlib implementations of the unchecked methods require unchecked
math, there is no reason to gate it behind this for external users. The
reasoning for a separate `step_trait_ext` feature is unclear, and as
such has been merged as well.
