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`
Abolish `QueryVTable` in favour of more assoc items on `QueryConfig`
This may introduce additional mono _but_ may help const fold things better and especially may help not constructing a `QueryVTable` anymore which is cheap but not free.
This may introduce additional mono _but_ may help const fold things
better and especially may help not constructing a `QueryVTable` anymore
which is cheap but not free.
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.
Document read_line gotchas
1. The "You do not need to clear the buffer before appending" advice is ambiguous, because it depends what you use this function for. For a rather common case of reading individual lines in a loop, it _is_ necessary to clear the buffer.
2. The docs warn about a DoS risk. I've added a hint how to mitigate unbounded memory growth.
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)
Only deduplicate stack traces for good path bugs
Fixes#106267
Restores backtraces for `bug!` and `delay_span_bug` after #106056. Only `delay_good_path_bug` needed its backtraces to be deduplicated, since it spits out the backtrace where it was created when it's being emitted.
Before:
```
error: internal compiler error: /home/ubuntu/rust2/compiler/rustc_middle/src/ty/relate.rs:638:13: var types encountered in super_relate_consts: Const { ty: usize, kind: Infer(Var(_#0c)) } Const { ty: usize, kind: Param(N/#1) }
note: the compiler unexpectedly panicked. this is a bug.
note: we would appreciate a bug report: https://github.com/rust-lang/rust/issues/new?labels=C-bug%2C+I-ICE%2C+T-compiler&template=ice.md
note: rustc 1.68.0-dev running on x86_64-unknown-linux-gnu
query stack during panic:
#0 [typeck] type-checking `<impl at /home/ubuntu/test.rs:7:1: 7:34>::trigger`
#1 [typeck_item_bodies] type-checking all item bodies
#2 [analysis] running analysis passes on this crate
end of query stack
error: aborting due to 2 previous errors
```
Hmm... that's a little bare.
After:
```
error: internal compiler error: /home/ubuntu/rust2/compiler/rustc_middle/src/ty/relate.rs:638:13: var types encountered in super_relate_consts: Const { ty: usize, kind: Infer(Var(_#0c)) } Const { ty: usize, kind: Param(N/#1) }
thread 'rustc' panicked at 'Box<dyn Any>', /home/ubuntu/rust2/compiler/rustc_errors/src/lib.rs:1599:9
stack backtrace:
0: 0x7ffb5b41bdd1 - std::backtrace_rs::backtrace::libunwind::trace::h26056f81198c6594
at /home/ubuntu/rust2/library/std/src/../../backtrace/src/backtrace/libunwind.rs:93:5
1: 0x7ffb5b41bdd1 - std::backtrace_rs::backtrace::trace_unsynchronized::hacfb345a0c6d5bb1
at /home/ubuntu/rust2/library/std/src/../../backtrace/src/backtrace/mod.rs:66:5
2: 0x7ffb5b41bdd1 - std::sys_common::backtrace::_print_fmt::h18ea6016ac8030f3
at /home/ubuntu/rust2/library/std/src/sys_common/backtrace.rs:65:5
3: 0x7ffb5b41bdd1 - <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt::he35dde201d0c2d09
at /home/ubuntu/rust2/library/std/src/sys_common/backtrace.rs:44:22
4: 0x7ffb5b4a0308 - core::fmt::write::h094ad263467a053c
at /home/ubuntu/rust2/library/core/src/fmt/mod.rs:1208:17
5: 0x7ffb5b43caf1 - std::io::Write::write_fmt::hd47b4e2324b4d9b7
at /home/ubuntu/rust2/library/std/src/io/mod.rs:1682:15
6: 0x7ffb5b41bbfa - std::sys_common::backtrace::_print::h43044162653a17fc
at /home/ubuntu/rust2/library/std/src/sys_common/backtrace.rs:47:5
7: 0x7ffb5b41bbfa - std::sys_common::backtrace::print::hc8605da258fa5aeb
at /home/ubuntu/rust2/library/std/src/sys_common/backtrace.rs:34:9
8: 0x7ffb5b3ffb87 - std::panicking::default_hook::{{closure}}::h9e37f23f75122a15
9: 0x7ffb5b3ff97b - std::panicking::default_hook::h602873a063f84da2
at /home/ubuntu/rust2/library/std/src/panicking.rs:286:9
10: 0x7ffb5be192b2 - <alloc[48d7b30605060536]::boxed::Box<dyn for<'a, 'b> core[672e3947e150d6c6]::ops::function::Fn<(&'a core[672e3947e150d6c6]::panic::panic_info::PanicInfo<'b>,), Output = ()> + core[672e3947e150d6c6]::marker::Send + core[672e3947e150d6c6]::marker::Sync> as core[672e3947e150d6c6]::ops::function::Fn<(&core[672e3947e150d6c6]::panic::panic_info::PanicInfo,)>>::call
at /home/ubuntu/rust2/library/alloc/src/boxed.rs:2002:9
11: 0x7ffb5be192b2 - rustc_driver[f5b6d32d8905ecdd]::DEFAULT_HOOK::{closure#0}::{closure#0}
at /home/ubuntu/rust2/compiler/rustc_driver/src/lib.rs:1204:17
12: 0x7ffb5b4000d3 - <alloc::boxed::Box<F,A> as core::ops::function::Fn<Args>>::call::hfd13333ca953ae8e
at /home/ubuntu/rust2/library/alloc/src/boxed.rs:2002:9
13: 0x7ffb5b4000d3 - std::panicking::rust_panic_with_hook::h45753e10264ebe7e
at /home/ubuntu/rust2/library/std/src/panicking.rs:692:13
14: 0x7ffb5e8b3a63 - std[3330b4673efabfce]::panicking::begin_panic::<rustc_errors[1b15f4e7e49d1fd5]::ExplicitBug>::{closure#0}
[... FRAMES INTENTIONALLY OMITTED BECAUSE GITHUB GOT ANGRY ...]
186: 0x7ffb5bea5554 - <std[3330b4673efabfce]:🧵:Builder>::spawn_unchecked_::<rustc_interface[947706ead88047d0]::util::run_in_thread_pool_with_globals<rustc_interface[947706ead88047d0]::interface::run_compiler<core[672e3947e150d6c6]::result::Result<(), rustc_errors[1b15f4e7e49d1fd5]::ErrorGuaranteed>, rustc_driver[f5b6d32d8905ecdd]::run_compiler::{closure#1}>::{closure#0}, core[672e3947e150d6c6]::result::Result<(), rustc_errors[1b15f4e7e49d1fd5]::ErrorGuaranteed>>::{closure#0}::{closure#0}, core[672e3947e150d6c6]::result::Result<(), rustc_errors[1b15f4e7e49d1fd5]::ErrorGuaranteed>>::{closure#1}
at /home/ubuntu/rust2/library/std/src/thread/mod.rs:549:30
187: 0x7ffb5bea5554 - <<std[3330b4673efabfce]:🧵:Builder>::spawn_unchecked_<rustc_interface[947706ead88047d0]::util::run_in_thread_pool_with_globals<rustc_interface[947706ead88047d0]::interface::run_compiler<core[672e3947e150d6c6]::result::Result<(), rustc_errors[1b15f4e7e49d1fd5]::ErrorGuaranteed>, rustc_driver[f5b6d32d8905ecdd]::run_compiler::{closure#1}>::{closure#0}, core[672e3947e150d6c6]::result::Result<(), rustc_errors[1b15f4e7e49d1fd5]::ErrorGuaranteed>>::{closure#0}::{closure#0}, core[672e3947e150d6c6]::result::Result<(), rustc_errors[1b15f4e7e49d1fd5]::ErrorGuaranteed>>::{closure#1} as core[672e3947e150d6c6]::ops::function::FnOnce<()>>::call_once::{shim:vtable#0}
at /home/ubuntu/rust2/library/core/src/ops/function.rs:250:5
188: 0x7ffb5b433968 - <alloc::boxed::Box<F,A> as core::ops::function::FnOnce<Args>>::call_once::he8b26fc22c6f51ec
at /home/ubuntu/rust2/library/alloc/src/boxed.rs:1988:9
189: 0x7ffb5b433968 - <alloc::boxed::Box<F,A> as core::ops::function::FnOnce<Args>>::call_once::h5cf9cbe75a8c3ddc
at /home/ubuntu/rust2/library/alloc/src/boxed.rs:1988:9
190: 0x7ffb5b41199c - std::sys::unix:🧵:Thread:🆕:thread_start::h2d6dd4455e97d031
at /home/ubuntu/rust2/library/std/src/sys/unix/thread.rs:108:17
191: 0x7ffb5441b609 - start_thread
192: 0x7ffb5b282133 - clone
193: 0x0 - <unknown>
note: the compiler unexpectedly panicked. this is a bug.
note: we would appreciate a bug report: https://github.com/rust-lang/rust/issues/new?labels=C-bug%2C+I-ICE%2C+T-compiler&template=ice.md
note: rustc 1.68.0-dev running on x86_64-unknown-linux-gnu
query stack during panic:
#0 [typeck] type-checking `<impl at /home/ubuntu/test.rs:7:1: 7:34>::trigger`
#1 [typeck_item_bodies] type-checking all item bodies
#2 [analysis] running analysis passes on this crate
end of query stack
error: aborting due to 2 previous errors
For more information about this error, try `rustc --explain E0601`.
```
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
Unify id-based thread parking implementations
Multiple platforms currently use thread-id-based parking implementations (NetBSD and SGX[^1]). Even though the strategy does not differ, these are duplicated for each platform, as the id is encoded into an atomic thread variable in different ways for each platform.
Since `park` is only called by one thread, it is possible to move the thread id into a separate field. By ensuring that the field is only written to once, before any other threads access it, these accesses can be unsynchronized, removing any restrictions on the size and niches of the thread id.
This PR also renames the internal `thread_parker` modules to `thread_parking`, as that name now better reflects their contents. I hope this does not add too much reviewing noise.
r? `@m-ou-se`
`@rustbot` label +T-libs
[^1]: SOLID supports this as well, I will switch it over in a follow-up PR.
