Do not visit attributes in `ItemLowerer`.
By default, AST visitors visit expressions that appear in key-value attributes.
Those expressions should not be lowered to HIR, as they do not correspond to actually compiled code.
Since an attribute cannot produce meaningful HIR, just skip them altogether.
Fixes https://github.com/rust-lang/rust/issues/81886
Fixes https://github.com/rust-lang/rust/issues/90873
r? `@michaelwoerister`
Print associated types on opaque `impl Trait` types
This PR generalizes #91021, printing associated types for all opaque `impl Trait` types instead of just special-casing for future.
before:
```
error[E0271]: type mismatch resolving `<impl Iterator as Iterator>::Item == u32`
```
after:
```
error[E0271]: type mismatch resolving `<impl Iterator<Item = usize> as Iterator>::Item == u32`
```
---
Questions:
1. I'm kinda lost in binders hell with this one. Is all of the `rebind`ing necessary?
2. Is there a map collection type that will give me a stable iteration order? Doesn't seem like TraitRef is Ord, so I can't just sort later..
3. I removed the logic that suppresses printing generator projection types. It creates outputs like this [gist](https://gist.github.com/compiler-errors/d6f12fb30079feb1ad1d5f1ab39a3a8d). Should I put that back?
4. I also added spaces between traits, `impl A+B` -> `impl A + B`. I quite like this change, but is there a good reason to keep it like that?
r? ````@estebank````
Link with default MACOSX_DEPLOYMENT_TARGET if not otherwise specified.
This PR sets the MACOSX_DEPLOYMENT_TARGET environment variable during the linking stage to our default, if it is not specified. This way it matches the deployment target we pass to llvm. If not set the the linker uses Xcode or Xcode commandline tools default which varies by version.
Fixes#90342, #91082.
Drive-by fixes to make Rust behave more like clang:
* Default to 11.0 deployment target for ARM64 which is the earliest version that had support for it.
* Set the llvm target to `arm64-apple-macosx<deployment target>` instead of `aarch64-apple-macosx<deployment target>`.
Various fixes for const_trait_impl
A few problems I found while making `Iterator` easier to const-implement.
1. More generous `~const Drop` check.
We check for nested fields with caller bounds.
For example, an ADT type with fields of types `A`, `B`, `C`, check if all of them are either:
- Bounded (`A: ~const Drop`, `B: Copy`)
- Known to be able to destruct at compile time (`C = i32`, `struct C(i32)`, `C = some_fn`)
2. Don't treat trait functions marked with `#[default_method_body_is_const]` as stable const fns when checking `const_for` and `const_try` feature gates.
I think anyone can review this, so no r? this time.
Tokenize emoji as if they were valid identifiers
In the lexer, consider emojis to be valid identifiers and reject
them later to avoid knock down parse errors.
Partially address #86102.
Restrict aarch64 outline atomics to glibc for now.
The introduced dependency on `getauxval` causes linking problems with musl, making compiling any binaries for `aarch64-unknown-linux-musl` impossible without workarounds such as using lld or adding liblibc.rlib again to the linker invocation, see #89626.
This is a workaround until libc>0.2.108 is merged.
Optimize live point computation
This refactors the live-point computation to lower per-MIR-instruction costs by operating on a largely per-block level. This doesn't fundamentally change the number of operations necessary, but it greatly improves the practical performance by aggregating bit manipulation into ranges rather than single-bit; this scales much better with larger blocks.
On the benchmark provided in #90445, with 100,000 array elements, walltime for a check build is improved from 143 seconds to 15.
I consider the tiny losses here acceptable given the many small wins on real world benchmarks and large wins on stress tests. The new code scales much better, but on some subset of inputs the slightly higher constant overheads decrease performance somewhat. Overall though, this is expected to be a big win for pathological cases (as illustrated by the test case motivating this work) and largely not material for non-pathological cases. I consider the new code somewhat easier to follow, too.
fix(doctest): detect extern crate items in statement doctests
This partially reverts #91026, because rustdoc needs to detect the extern statements, even when they appear inside implicit `main()`. It does not entirely revert it, so the old bug is still fixed, by duplicating some of the logic from `parse_mod` instead of trying to use it directly.
Fixes#91134
By default, AST visitors visit expressions that appear in key-value attributes.
Those expressions should not be lowered to HIR, as they do not correspond to actually compiled code.
Since an attribute cannot produce meaningful HIR, just skip them altogether.
Rollup of 6 pull requests
Successful merges:
- #90856 (Suggestion to wrap inner types using 'allocator_api' in tuple)
- #91103 (Inhibit clicks on summary's children)
- #91137 (Give people a single link they can click in the contributing guide)
- #91140 (Split inline const to two feature gates and mark expression position inline const complete)
- #91148 (Use `derive_default_enum` in the compiler)
- #91153 (kernel_copy: avoid panic on unexpected OS error)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Split inline const to two feature gates and mark expression position inline const complete
This PR splits inline const in pattern position into its own `#![feature(inline_const_pat)]` feature gate, and make the usage in expression position complete.
I think I have resolved most outstanding issues related to `inline_const` with #89561 and other PRs. The only thing left that I am aware of is #90150 and the lack of lifetime checks when inline const is used in pattern position (FIXME in #89561). Implementation-wise when used in pattern position it has to be lowered during MIR building while in expression position it's evaluated only when monomorphizing (just like normal consts), so it makes some sense to separate it into two feature gates so one can progress without being blocked by another.
``@rustbot`` label: T-compiler F-inline_const
Suggestion to wrap inner types using 'allocator_api' in tuple
This PR provides a suggestion to wrap the inner types in tuple when being along with 'allocator_api'.
Closes https://github.com/rust-lang/rust/issues/83250
```rust
fn main() {
let _vec: Vec<u8, _> = vec![]; //~ ERROR use of unstable library feature 'allocator_api'
}
```
```diff
error[E0658]: use of unstable library feature 'allocator_api'
--> $DIR/suggest-vec-allocator-api.rs:2:23
|
LL | let _vec: Vec<u8, _> = vec![];
- | ^
+ | ----^
+ | |
+ | help: consider wrapping the inner types in tuple: `(u8, _)`
|
= note: see issue #32838 <https://github.com/rust-lang/rust/issues/32838> for more information
= help: add `#![feature(allocator_api)]` to the crate attributes to enable
```
Mark places as initialized when mutably borrowed
Fixes the example in #90752, but does not handle some corner cases involving raw pointers and unsafe. See [this comment](https://github.com/rust-lang/rust/issues/90752#issuecomment-965822895) for more information, or the second test.
Although I talked about both `MaybeUninitializedPlaces` and `MaybeInitializedPlaces` in #90752, this PR only changes the latter. That's because "maybe uninitialized" is the conservative choice, and marking them as definitely initialized (`!maybe_uninitialized`) when a mutable borrow is created could lead to problems if `addr_of_mut` to an uninitialized local is allowed. Additionally, places cannot become uninitialized via a mutable reference, so if a place is definitely initialized, taking a mutable reference to it should not change that.
I think it's correct to ignore interior mutability as nbdd0121 suggests below. Their analysis doesn't work inside of `core::cell`, which *does* have access to `UnsafeCell`'s field, but that won't be an issue unless we explicitly instantiate one with an `enum` within that module.
r? `@wesleywiser`
Avoid generating empty closures for fieldless enum variants
For many enums, this avoids generating lots of tiny stubs that need to be codegen'd and then inlined and removed by LLVM. perf shows this to be a fairly small, but significant, win on rustc bootstrap time -- with minimal impact on runtime performance (which is at times even positive).
