Ignore untracked paths when running `rustfmt` on repository.
This is a step towards resolving #69291
(It might be the only step necessary at the moment; I'm not yet sure.)
Fail on multiple declarations of `main`.
Closes#67946.
Previously, when inserting the entry function, we only checked for
duplicate _definitions_ of `main`. However, it's possible to cause
problems even only having a duplicate _declaration_. For example,
shadowing `main` using an extern block isn't caught by the current
check, and causes an assertion failure down the line in in LLVM code.
r? @pnkfelix
Mark other variants as uninitialized after switch on discriminant
During drop elaboration, which builds the drop ladder that handles destruction during stack unwinding, we attempt to remove MIR `Drop` terminators that will never be reached in practice. This reduces the number of basic blocks that are passed to LLVM, which should improve performance. In #66753, a user pointed out that unreachable `Drop` terminators are common in functions like `Option::unwrap`, which move out of an `enum`. While discussing possible remedies for that issue, @eddyb suggested moving const-checking after drop elaboration. This would allow the former, which looks for `Drop` terminators and replicates a small amount of drop elaboration to determine whether a dropped local has been moved out, leverage the work done by the latter.
However, it turns out that drop elaboration is not as precise as it could be when it comes to eliminating useless drop terminators. For example, let's look at the code for `unwrap_or`.
```rust
fn unwrap_or<T>(opt: Option<T>, default: T) -> T {
match opt {
Some(inner) => inner,
None => default,
}
}
```
`opt` never needs to be dropped, since it is either moved out of (if it is `Some`) or has no drop glue (if it is `None`), and `default` only needs to be dropped if `opt` is `Some`. This is not reflected in the MIR we currently pass to codegen.
@eddyb also suggested the solution to this problem. When we switch on an enum discriminant, we should be marking all fields in other variants as definitely uninitialized. I implemented this on top of alongside a small optimization (split out into #68943) that suppresses drop terminators for enum variants with no fields (e.g. `Option::None`). This is the resulting MIR for `unwrap_or`.
In concert with #68943, this change speeds up many [optimized and debug builds](https://perf.rust-lang.org/compare.html?start=d55f3e9f1da631c636b54a7c22c1caccbe4bf0db&end=0077a7aa11ebc2462851676f9f464d5221b17d6a). We need to carefully investigate whether I have introduced any miscompilations before merging this. Code that never drops anything would be very fast indeed until memory is exhausted.
Simplify the signature of par_for_each_in
Given `T: IntoIterator`/`IntoParallelIterator`, `T::Item` is
unambiguous, so we don't need the explicit trait casting.
resolve: `lifetimes.rs` -> `late/lifetimes.rs`
Lifetime resolution should ideally be merged into the late resolution pass, at least for named lifetimes.
Let's move it closer to it for a start.
Backport only: avoid ICE on bad placeholder type
#69148 has a proper fix, but it is too big to backport.
This change avoids the ICE by actually emitting an appropriate error. The
output will be duplicated in some cases, but that's better than the
avoidable ICE.
r? @Centril
Generalized article_and_description
r? @matthewjasper
The logic of finding the right word and article to print seems to be repeated elsewhere... this is an experimental method to unify this logic...
Rollup of 5 pull requests
Successful merges:
- #68712 (Add methods to 'leak' RefCell borrows as references with the lifetime of the original reference)
- #69209 (Miscellaneous cleanup to formatting)
- #69381 (Allow getting `no_std` from the config file)
- #69434 (rustc_metadata: Use binary search from standard library)
- #69447 (Minor refactoring of statement parsing)
Failed merges:
r? @ghost
Allow getting `no_std` from the config file
Currently, it is only set correctly in the sanity checking implicit
default fallback code. Having a config file at all will for force
`no_std = false`.
Add methods to 'leak' RefCell borrows as references with the lifetime of the original reference
Usually, references to the interior are only created by the `Deref` and
`DerefMut` impl of the guards `Ref` and `RefMut`. Note that `RefCell`
already has to cope with leaks of such guards which, when it occurs,
effectively makes it impossible to ever acquire a mutable guard or any
guard for `Ref` and `RefMut` respectively. It is already safe to use
this to create a reference to the inner of the ref cell that lives as
long as the reference to the `RefCell` itself, e.g.
```rust
fn leak(r: &RefCell<usize>) -> Option<&usize> {
let guard = r.try_borrow().ok()?;
let leaked = Box::leak(Box::new(guard));
Some(&*leaked)
}
```
The newly added methods allow the same reference conversion without an
indirection over a leaked allocation. It's placed on the `Ref`/`RefMut` to
compose with both borrow and try_borrow directly.
Audit liballoc for leaks in `Drop` impls when user destructor panics
Inspired by https://github.com/rust-lang/rust/pull/67243 and https://github.com/rust-lang/rust/pull/67235, this audits and hopefully fixes the remaining `Drop` impls in liballoc for resource leaks in the presence of panics in destructors called by the affected `Drop` impl.
This does not touch `Hash{Map,Set}` since they live in hashbrown. They have similar issues though.
r? @KodrAus
Mark attributes consumed by `check_mod_attrs` as normal
Take advantage of the fact that `check_mod_attrs` marks attributes as
used and change their type to normal, so that any remaining uses will be
warned about by the unused attribute lint.
Deduplicate identifier printing a bit
https://github.com/rust-lang/rust/pull/67010 introduced a couple more subtly different ways to print an identifier.
This PR attempts to restore the order.
The most basic identifier printing interface is `Formatter`-based now, so `String`s are not allocated unless required.
r? @Mark-Simulacrum
Add primitive module to libcore
This re-exports the primitive types from libcore at `core::primitive` to allow
macro authors to have a reliable location to use them from.
Fixes#44865
