Don't translate compiler-internal bug messages
These are not very useful to be translated, as
* translators would get really weird and bad english versions to start out from,
* compiler devs have to do some work for what is supposed to be dead code and just a sanity check,
* the target audience is other compiler devs.
r? `@davidtwco`
new solver: don't consider blanket impls multiple times
only consider candidates which rely on the self type in `assemble_candidates_after_normalizing_self_ty`.
r? ``@compiler-errors``
Turn copy into moves during DSE.
Dead store elimination computes whether removing a direct store to an unborrowed place is allowed.
Where removing a store is allowed, writing `uninit` is too.
This means that we can use this pass to transform `copy` operands into `move` operands. This is only interesting in call terminators, so we only handle those.
Special care is taken for the `use_both(_1, _1)` case:
- moving the second argument is ok, as `_1` is not live after the call;
- moving the first argument is not, as the second argument reads `_1`.
Fixes#75993
Fixes https://github.com/rust-lang/rust/issues/108068
r? `@RalfJung`
cc `@JakobDegen`
Verify that all crate sources are in sync
This ensures that rustc will not attempt to link against a cdylib as if it is a rust dylib when an rlib for the same crate is available. Previously rustc didn't actually check if any further formats of a crate which has been loaded are of the same version and if they are actually valid. This caused a cdylib to be interpreted as rust dylib as soon as the corresponding rlib was loaded. As cdylibs don't export any rust symbols, linking would fail if rustc decides to link against the cdylib rather than the rlib.
Two crates depended on the previous behavior by separately compiling a test crate as both rlib and dylib. These have been changed to capture their original spirit to the best of my ability while still working when rustc verifies that all crates are in sync. It is unlikely that build systems depend on the current behavior and in any case we are taking a lot of measures to ensure that any change to either the source or the compilation options (including crate type) results in rustc rejecting it as incompatible. We merely didn't do this check here for now obsolete perf reasons.
Fixes https://github.com/rust-lang/rust/issues/10786
Fixes https://github.com/rust-lang/rust/issues/82151
Fixes https://github.com/rust-lang/rust/issues/82972
Closes https://github.com/bevy-cheatbook/bevy-cheatbook/issues/114
Use the correct span for displaying the line following a derive sugge…
`span` here is the main span of the diagnostic. In the linked issue's case, this belongs to `main.rs`. However, the line numbers (and line we are trying to display) are in `name.rs`, so using `span_to_lines` gives us the wrong `FileLines`.
Use `parts[0].span` (the span of the suggestion) here like the rest of the code does to get the right file.
Not sure if this needs a dedicated test because this fixes an existing error in the UI suite
Fixes#113844
Properly document `lifetime_mapping` in `OpaqueTy`
Also use an `Option` to signify that the value is actually present, instead of just no captured lifetimes.
On nightly, dump ICE backtraces to disk
Implement rust-lang/compiler-team#578.
When an ICE is encountered on nightly releases, the new rustc panic handler will also write the contents of the backtrace to disk. If any `delay_span_bug`s are encountered, their backtrace is also added to the file. The platform and rustc version will also be collected.
<img width="1032" alt="Screenshot 2023-03-03 at 2 13 25 PM" src="https://user-images.githubusercontent.com/1606434/222842420-8e039740-4042-4563-b31d-599677171acf.png">
The current behavior will *always* write to disk on nightly builds, regardless of whether the backtrace is printed to the terminal, unless the environment variable `RUSTC_ICE_DISK_DUMP` is set to `0`. This is a compromise and can be changed.
Rollup of 7 pull requests
Successful merges:
- #113444 (add tests for alias bound preference)
- #113716 (Add the `no-builtins` attribute to functions when `no_builtins` is applied at the crate level.)
- #113754 (Simplify native_libs query)
- #113765 (Make it clearer that edition functions are `>=`, not `==`)
- #113774 (Improve error message when closing bracket interpreted as formatting fill character)
- #113785 (Fix invalid display of inlined re-export when both local and foreign items are inlined)
- #113803 (Fix inline_const with interpolated block)
r? `@ghost`
`@rustbot` modify labels: rollup
Fix inline_const with interpolated block
Interpolation already worked when we had a `const $block` that wasn't a statement expr:
```
fn foo() {
let _ = const $block;
}
```
But it was failing when the const block was in statement expr position:
```
fn foo() {
const $block;
}
```
... because of a bug in a check for const items. This fixes that.
---
cc https://github.com/rust-lang/rust/pull/112953#issuecomment-1631354481, though I don't think this requires an FCP since it's already supported in exprs and seems to me to be fully a parser bug.
Make it clearer that edition functions are `>=`, not `==`
r? `@Nilstrieb`
We could also perhaps derive `Ord` on `Edition` and use comparison operators.
Add the `no-builtins` attribute to functions when `no_builtins` is applied at the crate level.
**When `no_builtins` is applied at the crate level, we should add the `no-builtins` attribute to each function to ensure it takes effect in LTO.**
This is also the reason why no_builtins does not take effect in LTO as mentioned in #35540.
Now, `#![no_builtins]` should be similar to `-fno-builtin` in clang/gcc, see https://clang.godbolt.org/z/z4j6Wsod5.
Next, we should make `#![no_builtins]` participate in LTO again. That makes sense, as LTO also takes into consideration function-level instruction optimizations, such as the MachineOutliner. More importantly, when a user writes a large `#![no_builtins]` crate, they would like this crate to participate in LTO as well.
We should also add a function-level no_builtins attribute to allow users to have more control over it. This is similar to Clang's `__attribute__((no_builtin))` feature, see https://clang.godbolt.org/z/Wod6KK6eq. Before implementing this feature, maybe we should discuss whether to support more fine-grained control, such as `__attribute__((no_builtin("memcpy")))`.
Related discussions:
- #109821
- #35540
Next (a separate pull request?):
- [ ] Revert #35637
- [ ] Add a function-level `no_builtin` attribute?
Encode shorthands for spans in metadata.
Spans occupy a typically large proportion of metadata.
This PR deduplicates encoded spans in order to reduce encoded length.
This ensures that rustc will not attempt to link against a cdylib as if
it is a rust dylib when an rlib for the same crate is available.
Previously rustc didn't actually check if any further formats of a
crate which has been loaded are of the same version and if they are
actually valid. This caused a cdylib to be interpreted as rust dylib as
soon as the corresponding rlib was loaded. As cdylibs don't export any
rust symbols, linking would fail if rustc decides to link against the
cdylib rather than the rlib.
Two crates depended on the previous behavior by separately compiling a
test crate as both rlib and dylib. These have been changed to capture
their original spirit to the best of my ability while still working
when rustc verifies that all crates are in sync. It is unlikely that
build systems depend on the current behavior and in any case we are
taking a lot of measures to ensure that any change to either the source
or the compilation options (including crate type) results in rustc
rejecting it as incompatible. We merely didn't do this check here for
now obsolete perf reasons.
Implement rust-lang/compiler-team#578.
When an ICE is encountered on nightly releases, the new rustc panic
handler will also write the contents of the backtrace to disk. If any
`delay_span_bug`s are encountered, their backtrace is also added to the
file. The platform and rustc version will also be collected.
Reasoning: if the stack is empty, the loop will be infinite,
so the assumption is that the stack can't be non empty. Unwrap
makes the assumption more clear (and removes an indentation level)
Better diagnostics for dlltool errors.
When dlltool fails, show the full command that was executed. In particular, llvm-dlltool is not very helpful, printing a generic usage message rather than what actually went wrong, so stdout and stderr aren't of much use when troubleshooting.
allow opaques to be defined by trait queries, again
This basically reverts #112963.
Moreover, all call-sites of `enter_canonical_trait_query` can now define opaque types, see the ui test `defined-by-user-annotation.rs`.
Fixes#113689
r? `@compiler-errors` `@oli-obk`
Instead of repeatedly merging the two smallest CGUs, we now use a
merging algorithm that aims to minimize the duplication of inlined
functions.
`exa-0.10.1` was one benchmark that saw particularly good results. The
old CGU stats:
```
INTERNALIZE
- unique items: 2774 (1216 root + 1558 inlined), unique size: 122065 (77219 root + 44846 inlined)
- placed items: 3834 (1216 root + 2618 inlined), placed size: 154552 (77219 root + 77333 inlined)
- placed/unique items ratio: 1.38, placed/unique size ratio: 1.27
- CGUs: 16, mean size: 9659.5, sizes: [11791, 11634, 11173, 10987, 10939, 10507, 9992, 9813, 9593, 9580, 9030, 8447, 7975, 7961, 7876, 7254]
```
The new CGU stats:
```
INTERNALIZE
- unique items: 2774 (1216 root + 1558 inlined), unique size: 122065 (77219 root + 44846 inlined)
- placed items: 3626 (1216 root + 2410 inlined), placed size: 147201 (77219 root + 69982 inlined)
- placed/unique items ratio: 1.31, placed/unique size ratio: 1.21
- CGUs: 16, mean size: 9200.1, sizes: [11634, 10939, 10227, 9555, 9178, 9167, 8879, 8804, 8604, 8603 (x3), 8602 (x2), 8601, 8600]
```
The difference is in the number of inlined items. There are 1558 unique
inlined items. With the old algorithm these were placed 2618 times,
resulting in 1060 duplicates. With the new algorithm these were placed
2410 times, resulting in 852 duplicates. Also, the mean CGU size dropped
from 9659.5 to 9200.1, and the CGU size distribution tightened, with the
biggest one a little smaller and the smallest ones a little bigger.
Restrict recursive opaque type check
We have a recursive opaque check in writeback to avoid inferring the hidden of an opaque type to be itself:
33a2c2487a/compiler/rustc_hir_typeck/src/writeback.rs (L556-L575)
Issue #113619 treats `make_option2` as not defining the TAIT `TestImpl` since it is inferred to have the definition `TestImpl := B<TestImpl>`, which fails this check. This regressed in #102700 (5d15beb591), I think due to the refactoring that made us record the hidden types of TAITs during writeback.
However, nothing actually seems to go bad if we relax this recursion checker to only check for directly recursive definitions. This PR fixes#113619 by changing this recursive check from being a visitor to just checking that the hidden type is exactly the same as the opaque being inferred.
Alternatively, we may be able to fix#113619 by restricting this recursion check only to RPITs/async fns. It seems to only be possible to use misuse the recursion check to cause ICEs for TAITs (though I didn't try too hard to create a bad RPIT example... may be possible, actually.)
r? `@oli-obk`
--
Fixes#113314
Fix removal span calculation of `unused_qualifications` suggestion
Given a path such as `std::ops::Index<str>`, calculate the unnecessary qualification removal span by computing the beginning of the entire span until the ident span of the last path segment, which handles generic arguments and lifetime arguments in the last path segment. Previous logic only kept the ident span of the last path segment which is incorrect.
Closes#113808.
Safe Transmute: Fix ICE (due to UnevaluatedConst)
This patch updates the code that looks at the `Assume` type when evaluating if transmutation is possible. An ICE was being triggered in the case that the `Assume` parameter contained an unevaluated const (in this test case, due to a function with missing parameter names).
Fixes#110892
Rename `arg_iter` to `iter_instantiated`
`arg_iter` doesn't make sense, and doesn't really indicate what it's doing (returning an iterator that ~~substitutes~~ instantiates its elements).
`iter_instantiated_copied` is kinda awkward but i don't really wanna bikeshed it.
r? `@oli-obk`
Add x86_64-unknown-linux-ohos target
This complements the existing `aarch64-unknown-linux-ohos` and `armv7-unknown-linux-ohos` targets.
This should be covered by the existing MCP (https://github.com/rust-lang/compiler-team/issues/568), but I can also create a new MCP if that is preferred.
When dlltool fails, show the full command that was executed. In
particular, llvm-dlltool is not very helpful, printing a generic usage
message rather than what actually went wrong, so stdout and stderr
aren't of much use when troubleshooting.
miri: fail when calling a function that requires an unavailable target feature
miri will report an UB when calling a function that has a `#[target_feature(enable = ...)]` attribute is called and the required feature is not available.
"Available features" are the same that `is_x86_feature_detected!` (or equivalent) reports to be available during miri execution (which can be enabled or disabled with the `-C target-feature` flag).
This patch updates the code that looks at the `Assume` type when evaluating if
transmutation is possible. An ICE was being triggered in the case that the
`Assume` parameter contained an unevaluated const (in this test case, due to a
function with missing parameter names).
Fixes#110892
CI: build CMake 3.20 to support LLVM 17
LLVM 17 will require CMake at least 3.20, so we have to go back to building our own CMake on the Linux x64 dist builder.
r? `@nikic`
