rustc_codegen_llvm: don't generate any type debuginfo for -Cdebuginfo=1.
Works towards #69074 by adding more checks for `DebugInfo::Full` in a few places in `rustc_codegen_llvm`, bringing us in line with what `clang -g1` generates (no debuginfo types, nor debuginfo for `static`s).
<hr/>
My local build's (`debuginfo-level=1`, `debug-assertions=1`) `librustc_driver-*.so` went from just over 1GiB (1019MiB) down to 402MiB.
It's still bad, but the `.debug_*` sections themselves (as reported by `objdump`) went from something like 853MiB down to 236MiB, i.e. roughly a 3.6x reduction.
<hr/>
Sadly, I don't think this is enough to justify *shipping* all of this debuginfo, but now it's more plausible that we could at least *build* with `debuginfo-level=1` *then* strip it.
That would give us real backtraces for e.g. ICEs during builds, but I don't know how often that's relevant.
We could also look into split DWARF, and maybe have a `rustc-debuginfo` component in `rustup`.
There's also the possibility of making it slimmer by omitting parameters to functions, or perhaps some deduplication (I think right now there is no DWARF reuse across CGUs? maybe ThinLTO helps?).
r? @michaelwoerister cc @rust-lang/wg-codegen @alexcrichton @Mark-Simulacrum
Previously, we threw away the `Span` associated with a definition's
identifier when we encoded crate metadata, causing us to lose location
and hygiene information.
We now store the identifier's `Span` in the crate metadata.
When we decode items from the metadata, we combine
the name and span back into an `Ident`.
This improves the output of several tests, which previously had messages
suppressed due to dummy spans.
This is a prerequisite for #68686, since throwing away a `Span` means
that we lose hygiene information.
resolve: Avoid "self-confirming" import resolutions in one more case
So the idea behind "blacklisted bindings" is that we must ignore some name definitions during resolution because otherwise they cause infinite cycles.
E.g. import
```rust
use my_crate;
```
would refer to itself (on 2018 edition) without this blacklisting, because `use my_crate;` is the first name in scope when we are resolving `my_crate` here.
In this PR we are doing this blacklisting for the case
```rust
use same::same;
```
, namely blacklisting the second `same` when resolving the first `same`.
This was previously forgotten.
Fixes https://github.com/rust-lang/rust/issues/62767
miri engine: turn error sanity checks into assertions
We had these as debug assertions so far to make sure our test suite is clean, but really these are conditions that should never arise and also @eddyb told me to turn non-performance-critical debug assertions into full assertions so here we go. ;)
I propose that we do a check-only crater run to make sure this does not actually happen in practice.
r? @oli-obk
#[track_caller] in traits
Per https://github.com/rust-lang/rust/issues/47809#issuecomment-572791760, this allows the `#[track_caller]` attribute on trait methods.
Includes tests for `#[track_caller]` with:
* "regular" trait impls
* default trait impls
* "blanket-tracked" trait impls, where the annotation is in the trait definition and is inherited by "regular" impls of the trait
Liberate `rustc_ast_lowering` from `rustc`
The whole point of this PR is the very last commit, in which we remove `rustc` as one of `rustc_ast_lowering`'s dependencies, thereby improving `./x.py` parallelism and working towards https://github.com/rust-lang/rust/issues/65031.
Noteworthy:
- From `rustc::arena` we move logic into `arena`, in particular `declare_arena!`. This is then used in `rustc_ast_lowering` so that lowering has its own separate arena.
- Some linting code is unfortunately moved to `rustc_session::lint` cause its used both in `rustc_lint` and `rustc_ast_lowering`, and this is their common dependency.
- `rustc_session::CrateDisambiguator` is moved into `rustc_ast` so that `rustc::hir::map::definitions` can be moved into `rustc_hir`, so that `rustc_ast_lowering` can stop referring to `rustc::hir`.
r? @Zoxc
This adds a missing `!config.obj_is_bitcode` condition to two places
that should have it.
As a result, when `obj_is_bitcode` and `no_integrated_as` are both true,
the compiler will no longer unnecessarily emit asm, convert it to an
object file, and then overwrite that object file with bitcode.
I find the code easier to read if the values in `config` are all used
directly, rather than a mix of `config` values and local variables. It
will also faciliate some of the following commits.
Also, use `config.bitcode_needed()` in one place.
perf(dep_graph): Avoid allocating a set on when the number reads are …
…small
`reserve_and_rehash` takes up 1.4% of the runtime on the `packed-simd`
benchmark which I believe is due to the number of reads are very low in
many cases (see https://github.com/rust-lang/rust/pull/50565 for
instance).
This avoids allocating the set until we start allocating the `reads`
`SmallVec` but it is possible that a lower limit might be better (not
tested since the improvement will be hard to spot either way).
With #70166 merged, `RangeInclusive` now derives `PartialEq` and `Eq`, implementing structural equality and as a side effect the range is now usable with const generics, closing #70155.
A test is added to avoid a change to the private fields or the equality implementation of the range from subtly reverting #70155.
Allow calculating the layout behind a pointer
There was some discussion around allowing this previously.
This does make the requirement for raw pointers to have valid metadata exposed as part of the std API (as a safety invariant, not validity invariant), though I think this is not strictly necessarily required as of current. cc @rust-lang/wg-unsafe-code-guidelines
Naming is hard; I picked the best "obvious" name I could come up with.
If it's agreed that this is actually a desired API surface, I'll file a tracking issue and update the attributes.
couple more clippy fixes (let_and_return, if_same_then_else)
* summarize if-else-code with identical blocks (clippy::if_same_then_else)
* don't create variable bindings just to return the bound value immediately (clippy::let_and_return)
