Reenable limited top-down MIR inlining
Reverts most of #105119 and uses an alternative strategy to prevent exponential blowup. Specifically, we allow doing top-down inlining up to depth at most five, and for at most one call site per nested body.
r? `@cjgillot`
Encode spans relative to the enclosing item -- enable on nightly
Follow-up to #84373 with the flag `-Zincremental-relative-spans` set by default.
This PR seeks to remove one of the main shortcomings of incremental: the handling of spans.
Changing the contents of a function may require redoing part of the compilation process for another function in another file because of span information is changed.
Within one file: all the spans in HIR change, so typechecking had to be re-done.
Between files: spans of associated types/consts/functions change, so type-based resolution needs to be re-done (hygiene information is stored in the span).
The flag `-Zincremental-relative-spans` encodes local spans relative to the span of an item, stored inside the `source_span` query.
Trap: stashed diagnostics are referenced by the "raw" span, so stealing them requires to remove the span's parent.
In order to avoid too much traffic in the span interner, span encoding uses the `ctxt_or_tag` field to encode:
- the parent when the `SyntaxContext` is 0;
- the `SyntaxContext` when the parent is `None`.
Even with this, the PR creates a lot of traffic to the Span interner, when a Span has both a LocalDefId parent and a non-root SyntaxContext. They appear in lowering, when we add a parent to all spans, including those which come from macros, and during inlining when we mark inlined spans.
The last commit changes how queries of `LocalDefId` manage their cache. I can put this in a separate PR if required.
Possible future directions:
- validate that all spans are marked in HIR validation;
- mark macro-expanded spans relative to the def-site and not the use-site.
Added link from Targets to Platform Support in the book
If you search the web for "rust targets", the first result is the [targets page](https://doc.rust-lang.org/nightly/rustc/targets/index.html). However, usually when searching for this I'm interested in seeing the available triples with host information, so I just added a link to the correct page.
The entire `Targets` chapter could probably be combined into one page, since its three subchapters each only have a tiny section (I'll do this if requested)
refactor: merge error code `E0465` into `E0464`
`E0465` is an undocumented and untested error code that is functionally identical to `E0464`. This PR merges `E0465` into `E0464`, thus documenting and testing another error code (#61137).
r? `@GuillaumeGomez` (not sure if you want to review this but it's relevant to my other PRs that you have reviewed)
Dont use `--merge-base` during bootstrap formatting subcommand
I use a development image with Ubuntu 20.04 LTS, which has git 2.25.
Recently, `./x.py test tidy --bless` regressed in #105702 because it uses the `--merge-base` option on `diff-index`, which was only introduced in git 2.30 (git/git@0f5a1d449b). Luckily, it can be replicated via two calls to `git merge-base` + `git diff-index`, so let's just use that.
Make tidy errors red
This makes it easier to see them (and makes people go owo).
I also changes the error codes check to not print too many things and use `tidy_error`.
r? ```@jyn514```
Revert "Implement allow-by-default `multiple_supertrait_upcastable` lint"
This is a clean revert of #105484.
I confirmed that reverting that PR fixes the regression reported in #106247. ~~I can't say I understand what this code is doing, but maybe it can be re-landed with a different implementation.~~ **Edit:** https://github.com/rust-lang/rust/issues/106247#issuecomment-1367174384 has an explanation of why #105484 ends up surfacing spurious `where_clause_object_safety` errors. The implementation of `where_clause_object_safety` assumes we only check whether a trait is object safe when somebody actually uses that trait with `dyn`. However the implementation of `multiple_supertrait_upcastable` added in the problematic PR involves checking *every* trait for whether it is object-safe.
FYI `@nbdd0121` `@compiler-errors`
CFI: Monomorphize transparent ADTs before typeid
Monomorphise `#[repr(transparent)]` parameterized ADTs before turning them into an Itanium mangled String.
`#[repr(transparent)]` ADTs currently use the single field to represent them in their CFI type ID to ensure that they are compatible. However, if that type involves a type parameter instantiated at the ADT level, as in `ManuallyDrop`, this will currently ICE as the `Parameter` type cannot be mangled. Since this happens at lowering time, it should always be concrete after substitution.
Fixes#106230
Add tidy check to deny merge commits
This will prevent users with the pre-push hook from pushing a merge commit.
Exceptions are added for subtree updates. These exceptions are a little hacky and may be non-exhaustive but can be extended in the future.
I added a link to `@jyn514's` blog post for the error case because that's the best resource to solve merge commits. But it would probably be better if it was integrated into https://rustc-dev-guide.rust-lang.org/git.html#no-merge-policy, then we could link that instead.
r? `@jyn514`
Before:
```
Testing ["rustc_interface"] stage0 (aarch64-unknown-linux-gnu -> aarch64-unknown-linux-gnu)
```
After:
```
Testing {rustc_interface} stage0 (aarch64-unknown-linux-gnu -> aarch64-unknown-linux-gnu)
```
Note there is a slight consistency between `build` and `test`: The
former doesn't print "compiler artifacts". It would be annoying to fix
and doesn't hurt anything, so I left it be.
```
; x t rustc_interface --stage 0 --dry-run
Testing {rustc_interface} stage0 (aarch64-unknown-linux-gnu -> aarch64-unknown-linux-gnu)
; x b rustc_interface --stage 0 --dry-run
Building {rustc_interface} stage0 compiler artifacts (aarch64-unknown-linux-gnu -> aarch64-unknown-linux-gnu)
```
This mostly reverts 468acca108, while still
fixing the problem it fixed by using an internal list-style-position. It
results in a slight change in the hover indicator, but nothing misleading.
rustdoc: remove redundant CSS `.source .content { overflow: visible }`
When added in 7669f04fb0 / #16066, the page itself was set to scroll. Now it's set so that the `example-wrap` is scrolling inside the page, so the overflow setting for the content is irrelevant.
