Fixed consistency of Apple simulator target's ABI
Currently there's a few Apple device simulator targets that are inconsistent since some set `target_abi = "sim"` (the correct thing to do) while a bunch of others don't set anything (`""`). Due to this its very hard to reliability check if some Rust code is running inside a simulator. This changes all of them to do the same thing and set `sim` as their `target_abi`.
The new way to identity a simulator during compilation is as simple as `cfg(all(target_vendor="apple", target_abi = "sim"))` or even `cfg(target_abi = "sim")` being less pedantic about it.
The issues with the current form (and inspiration for this) are also summarized in `@thomcc's` [Tweet](https://twitter.com/at_tcsc/status/1576685244702691328).
Allow use of `-Clto=thin` with `-Ccodegen-units=1` in general
The current logic to ignore ThinLTO when `-Ccodegen-units=1` makes sense for local ThinLTO but even in this scenario, a user may still want (non-local) ThinLTO for the purpose of optimizing dependencies into the final crate which is being compiled with 1 CGU.
The previous behavior was even more confusing because if you were generating a binary (`--emit=link`), then you would get ThinLTO but if you asked for LLVM IR or bytecode, then it would silently change to using regular LTO.
With this change, we only override the defaults for local ThinLTO if you ask for a single output such as LLVM IR or bytecode and in all other cases honor the requested LTO setting.
r? `@michaelwoerister`
fix(generic_const_exprs): Fix predicate inheritance for children of opaque types
Fixes#99705
We currently have a special case to perform predicate inheritance when the const item is in the generics. I think we're also going to need this for opaque return types. When evaluating the predicates applied to the associated item, it'll inherit from its parent, the opaque type, which will never have predicates applied. This PR bypass the opaque typed parent and inherit predicates directly from the function itself.
Reorder `walk_` functions in intravisit.rs
Reorder the `walk_` functions to match the order of the `visit_` methods. This is a follow up to https://github.com/rust-lang/rust/pull/103692.
Note that there are some oddballs. I put them where I thought made the most sense:
```diff
$ diff \
<(sed -n 's/^.*\<fn visit_\([^(]*\).*$/\1/;T;p' compiler/rustc_hir/src/intravisit.rs) \
<(sed -n 's/^.*\<fn walk_\([^<]*\).*$/\1/;T;p' compiler/rustc_hir/src/intravisit.rs)
1,5d0
< nested_item
< nested_trait_item
< nested_impl_item
< nested_foreign_item
< nested_body
9,10d3
< id
< name
20c13
< array_length
---
> array_len
30a24
> fn_ret_ty
31a26
> fn_kind
41c36
< variant_data
---
> struct_def
46c41
< infer
---
> inf
54d48
< attribute
```
Also, as some weak evidence that i did things correctly, I get the following before and after the change:
```sh
$ sort compiler/rustc_hir/src/intravisit.rs | openssl sha256
SHA256(stdin)= cac13d2545731ef442f318e2b4286490d7ac5494f4ad10c4cf4c5d4f50d21641
```
r? `@fee1-dead`
Gate some parser recovery behind the check
Mainly in `expr.rs`. `may_recover` doesn't do anything useful yet until I implement that on top of #103439.
r? `@compiler-errors`
Print valid `--print` requests if request is invalid
When someone makes a typo, it can be useful to see the valid options. This is also useful if someone wants to find out about all the options.
Add `multivalue` target feature to WASM target
This PR is similar to #99643 and #97808. It addresses #96472 for the `multivalue` target feature.
The problem I am trying to fix is to remove the following warning when compiling with `-C target-feature=+multivalue` for `--target=wasm32-unknown-unknown`.
```
warning: unknown feature specified for `-Ctarget-feature`: `multivalue`
|
= note: it is still passed through to the codegen backend
= note: consider filing a feature request
```
Change #[suggestion_*] attributes to use style="..."
As discussed [on Zulip](https://rust-lang.zulipchat.com/#narrow/stream/336883-i18n/topic/.23100717.20tool_only_span_suggestion), this changes `#[(multipart_)suggestion_{short,verbose,hidden}(...)]` attributes to plain `#[(multipart_)suggestion(...)]` attributes with a `style = "{short,verbose,hidden}"` parameter.
It also adds a new style, `tool-only`, that corresponds to `tool_only_span_suggestion`/`tool_only_multipart_suggestion` and causes the suggestion to not be shown in human-readable output at all.
Best reviewed commit-by-commit, there's a bit of noise in there.
cc #100717 `@compiler-errors`
r? `@davidtwco`
Track where diagnostics were created.
This implements the `-Ztrack-diagnostics` flag, which uses `#[track_caller]` to track where diagnostics are created. It is meant as a debugging tool much like `-Ztreat-err-as-bug`.
For example, the following code...
```rust
struct A;
struct B;
fn main(){
let _: A = B;
}
```
...now emits the following error message:
```
error[E0308]: mismatched types
--> src\main.rs:5:16
|
5 | let _: A = B;
| - ^ expected struct `A`, found struct `B`
| |
| expected due to this
-Ztrack-diagnostics: created at compiler\rustc_infer\src\infer\error_reporting\mod.rs:2275:31
```
resolve: Turn the binding from `#[macro_export]` into a proper `Import`
Continuation of https://github.com/rust-lang/rust/pull/91795.
```rust
#[macro_export]
macro_rules! m { /*...*/ }
```
is desugared to something like
```rust
macro_rules! m { /*...*/ } // Non-modularized macro_rules item
pub use m; // It's modularized reexport
```
This PR adjusts the internal representation to better match this model.
rustc_metadata: Encode even less doc comments
The fact that `def_id` is in the `tcx.privacy_access_levels(())` table is not very meaningful, especially after https://github.com/rust-lang/rust/pull/102026, `is_exported` (or `is_reachable` in the worst case) is what you need.
Follow up to https://github.com/rust-lang/rust/pull/98450.
r? `@GuillaumeGomez` `@lqd`
(almost) Always use `ObligationCtxt` when dealing with canonical queries
Hope this is a step in the right direction. cc rust-lang/types-team#50.
r? `@lcnr`
Fix E0433 No Typo Suggestions
Fixes#48676Fixes#87791Fixes#96625Fixes#95462Fixes#101637
Follows up PR #72923
Several open issues refer to the problem that E0433 does not suggest typos like other errors normally do. This fix augments the implementation of PR #72923.
**Background**
When the path of a function call, e.g. `Struct::foo()`, involves names that cannot be resolved, there are two errors that could be emitted by the compiler:
- If `Struct` is not found, it is ``E0433: failed to resolve: use of undeclared type `Struct` ``.
- If `foo` is not found in `Struct`, it is ``E0599: no function or associated item named `foo` found for struct `Struct` in the current scope``
When a name is used as a type, `e.g. fn foo() -> Struct`, and the name cannot be resolved, it is ``E0412: cannot find type `Struct` in this scope``.
Before #72923, `E0433` does not implement any suggestions, and the PR introduces suggestions for missing `use`s. When a resolution error occurs in the path of a function call, it tries to smart resolve just the type part of the path, e.g. `module::Struct` of a call to `module::Struct::foo()`. However, along with the suggestions, the smart-resolve function will report `E0412` since it only knows that it is a type that we cannot resolve instead of being a part of the path. So, the original implementation swap out `E0412` errors returned by the smart-resolve function with the real `E0433` error, but keeps the "missing `use`" suggestions to be reported to the programmer.
**Issue**
The current implementation only reports if there are "missing `use`" suggestions returned by the smart-resolve function; otherwise, it would fall back the normal reporting, which does not emit suggestions. But the smart-resolve function could also produce typo suggestions, which are omitted currently.
Also, it seems like that not all info has been swapped out when there are missing suggestions. The error message underlining the name in the snippet still says ``not found in this scope``, which is a `E0412` messages, if there are `use` suggestions, but says the normal `use of undeclared type` otherwise.
**Fixes**
This fix swaps out all fields in `Diagnostic` returned by the smart-resolve function except for `suggestions` with the current error, and merges the `suggestions` of the returned error and that of the current error together. If there are `use` suggestions, the error is saved to `use_injection` to be reported at the end; otherwise, the error is emitted immediately as `Resolver::report_error` does.
Some tests are updated to use the correct underlining error messages, and one additional test for typo suggestion is added to the test suite.
r? rust-lang/diagnostics
Rewrite implementation of `#[alloc_error_handler]`
The new implementation doesn't use weak lang items and instead changes `#[alloc_error_handler]` to an attribute macro just like `#[global_allocator]`.
The attribute will generate the `__rg_oom` function which is called by the compiler-generated `__rust_alloc_error_handler`. If no `__rg_oom` function is defined in any crate then the compiler shim will call `__rdl_oom` in the alloc crate which will simply panic.
This also fixes link errors with `-C link-dead-code` with `default_alloc_error_handler`: `__rg_oom` was previously defined in the alloc crate and would attempt to reference the `oom` lang item, even if it didn't exist. This worked as long as `__rg_oom` was excluded from linking since it was not called.
This is a prerequisite for the stabilization of `default_alloc_error_handler` (#102318).
interpret: move type_name implementation to an interpreter-independent helper file
This should avoid pinging rust-lang/miri each time that file changes, which is really not necessary.
r? `@oli-obk`
Reduce span of let else irrefutable_let_patterns warning
Huge spans aren't good for IDE users as they underline constructs that are possibly multiline.
Similar PR to #90761 which did the same for the `unused_macros` lint.
The new implementation doesn't use weak lang items and instead changes
`#[alloc_error_handler]` to an attribute macro just like
`#[global_allocator]`.
The attribute will generate the `__rg_oom` function which is called by
the compiler-generated `__rust_alloc_error_handler`. If no `__rg_oom`
function is defined in any crate then the compiler shim will call
`__rdl_oom` in the alloc crate which will simply panic.
This also fixes link errors with `-C link-dead-code` with
`default_alloc_error_handler`: `__rg_oom` was previously defined in the
alloc crate and would attempt to reference the `oom` lang item, even if
it didn't exist. This worked as long as `__rg_oom` was excluded from
linking since it was not called.
This is a prerequisite for the stabilization of
`default_alloc_error_handler` (#102318).
Rollup of 8 pull requests
Successful merges:
- #97971 (Enable varargs support for calling conventions other than C or cdecl )
- #101428 (Add mir building test directory)
- #101944 (rustdoc: clean up `#toggle-all-docs`)
- #102101 (check lld version to choose correct option to disable multi-threading in tests)
- #102689 (Add a tier 3 target for the Sony PlayStation 1)
- #103746 (rustdoc: add support for incoherent impls on structs and traits)
- #103758 (Add regression test for reexports in search results)
- #103764 (All verbosity checks in `PrettyPrinter` now go through `PrettyPrinter::should_print_verbose`)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
