Matthias Krüger [Wed, 2 Nov 2022 21:06:26 +0000 (22:06 +0100)]
Rollup merge of #103610 - wesleywiser:thinlto_cgu1, r=michaelwoerister
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.
Matthias Krüger [Wed, 2 Nov 2022 21:06:26 +0000 (22:06 +0100)]
Rollup merge of #99801 - Neo-Zhixing:fix/generic_const_exprs_parent_opaque_predicates, r=oli-obk
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.
Dylan DPC [Wed, 2 Nov 2022 17:02:06 +0000 (22:32 +0530)]
Rollup merge of #103864 - smoelius:reorder-walk-functions, r=fee1-dead
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
```
bors [Wed, 2 Nov 2022 07:47:10 +0000 (07:47 +0000)]
Auto merge of #103649 - petrochenkov:docnotrait, r=GuillaumeGomez
rustdoc: Do not add external traits to the crate in `register_res`
It's not clear why it was done, and apparently it's no longer necessary now.
Such additions are unpredictable for early doc link resolution and would force us to collect all doc links from all external traits.
bors [Wed, 2 Nov 2022 04:27:48 +0000 (04:27 +0000)]
Auto merge of #103857 - Manishearth:rollup-709fui6, r=Manishearth
Rollup of 8 pull requests
Successful merges:
- #103072 (compiletest: set the dylib path when gathering target cfg)
- #103084 (Derive `Eq` and `Hash` for `ControlFlow`)
- #103575 (Change #[suggestion_*] attributes to use style="...")
- #103637 (Use stdio in UWP apps)
- #103638 (Add `multivalue` target feature to WASM target)
- #103781 (Detect unused files in `src/test/mir-opt` and error on them in tidy.)
- #103837 (Migrate sidebar-links-color GUI test to functions)
- #103839 (Print valid `--print` requests if request is invalid)
Rollup merge of #103781 - JakobDegen:mir-opt-tidy, r=jyn514
Detect unused files in `src/test/mir-opt` and error on them in tidy.
Closes #97564 .
Determining which files are generated by a given mir opt test is somewhat difficult. Because of this, we extract the logic for doing it out into a common crate that both compiletest and tidy can depend on. This avoids making compiletest a dependency of tidy which would negatively impact compile times for tidy.
Testing for this is that it catches 5 files that violated this lint (and removes them).
Rollup merge of #103638 - ia0:multivalue, r=nagisa
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
```
Rollup merge of #103637 - ChrisDenton:stdio-uwp, r=thomcc
Use stdio in UWP apps
Fixes #103233
This has been supported since Windows 10.0.16299. See https://learn.microsoft.com/en-us/uwp/win32-and-com/win32-apis#apis-from-api-ms-win-core-console-l1-1-0dll
Rollup merge of #103575 - Xiretza:suggestions-style-attr, r=davidtwco
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.
Rollup merge of #103084 - inquisitivecrystal:control-flow, r=scottmcm
Derive `Eq` and `Hash` for `ControlFlow`
There's really no reason for `ControlFlow` not to derive these traits. This is the part of #96416 that no one objected to, but that PR seems stale. The `Eq` derive was also [requested](https://rust-lang.zulipchat.com/#narrow/stream/219381-t-libs/topic/.60ControlFlow.3A.20Eq.60/near/303610659) by `@lcnr` on Zulip to allow for pattern matching.
This change requires an FCP because it's insta-stable.
Rollup merge of #103072 - cuviper:compiletest-path, r=Mark-Simulacrum
compiletest: set the dylib path when gathering target cfg
If the compiler is built with `rpath = false`, then it won't find its
own libraries unless the library search path is set. We already do that
while running the actual compiletests, but #100260 added another rustc
command for getting the target cfg.
Check compiletest suite=codegen mode=codegen (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu)
thread 'main' panicked at 'error: failed to get cfg info from "[...]/build/x86_64-unknown-linux-gnu/stage1/bin/rustc"
--- stdout
--- stderr
[...]/build/x86_64-unknown-linux-gnu/stage1/bin/rustc: error while loading shared libraries: librustc_driver-a2a76dc626cd02d2.so: cannot open shared object file: No such file or directory
', src/tools/compiletest/src/common.rs:476:13
Now the library path is set here as well, so it works without rpath.
bors [Tue, 1 Nov 2022 21:09:45 +0000 (21:09 +0000)]
Auto merge of #103217 - mejrs:track, r=eholk
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
```
bors [Tue, 1 Nov 2022 18:15:32 +0000 (18:15 +0000)]
Auto merge of #103841 - Dylan-DPC:rollup-rff2x1l, r=Dylan-DPC
Rollup of 5 pull requests
Successful merges:
- #84022 (Make PROC_MACRO_DERIVE_RESOLUTION_FALLBACK a hard error)
- #103760 (resolve: Turn the binding from `#[macro_export]` into a proper `Import`)
- #103813 (rustdoc: remove unnecessary CSS `.search-results { clear: both }`)
- #103817 (rustdoc: rename syntax highlighting CSS class `attribute` to `attr`)
- #103833 (:arrow_up: rust-analyzer)
Dylan DPC [Tue, 1 Nov 2022 16:31:36 +0000 (22:01 +0530)]
Rollup merge of #103760 - petrochenkov:macimp, r=cjgillot
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.
bors [Tue, 1 Nov 2022 15:05:14 +0000 (15:05 +0000)]
Auto merge of #103496 - petrochenkov:effvisdoc2, r=lqd
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`
bors [Tue, 1 Nov 2022 09:01:12 +0000 (09:01 +0000)]
Auto merge of #103832 - Dylan-DPC:rollup-maw3kmx, r=Dylan-DPC
Rollup of 6 pull requests
Successful merges:
- #103061 (Rewrite implementation of `#[alloc_error_handler]`)
- #103584 (Remove bounds check when array is indexed by enum)
- #103706 (Fix E0433 No Typo Suggestions)
- #103729 (interpret: fix align_of_val on packed types)
- #103759 (Use `adt_def` during type collection.)
- #103809 (Fix a typo in std::net mod doc comment)
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.
Dylan DPC [Tue, 1 Nov 2022 08:42:25 +0000 (14:12 +0530)]
Rollup merge of #103061 - Amanieu:rewrite_alloc_error_handler, r=bjorn3
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).
bors [Tue, 1 Nov 2022 05:34:00 +0000 (05:34 +0000)]
Auto merge of #103829 - JohnTitor:rollup-o03nzr8, r=JohnTitor
Rollup of 10 pull requests
Successful merges:
- #103007 (Add better python discovery)
- #103674 (Update note about unstable split-debuginfo flag.)
- #103692 (Add `walk_generic_arg`)
- #103749 (Reduce span of let else irrefutable_let_patterns warning)
- #103772 (better error for `rustc_strict_coherence` misuse)
- #103788 (Fix ICE in checking transmutability of NaughtyLenArray)
- #103793 (rustdoc: add margins to all impl-item toggles, not just methods)
- #103798 (interpret: move type_name implementation to an interpreter-independent helper file)
- #103799 (Remove generation of tuple struct fields in the search index)
- #103805 (Enable RUSTC_BOOTSTRAP for a few steps)
Yuki Okushi [Tue, 1 Nov 2022 03:03:40 +0000 (12:03 +0900)]
Rollup merge of #103674 - ehuss:split-debuginfo-doc-unstable, r=davidtwco
Update note about unstable split-debuginfo flag.
split-debuginfo was effectively stabilized in #98051. The note about it requiring `-Z unstable-options` is no longer accurate.
The rules for when it is gated and when it is supported are somewhat complex. I considered removing the note entirely, or making it more generic, but opted to instead try to summarize the current state.
Yuki Okushi [Tue, 1 Nov 2022 03:03:40 +0000 (12:03 +0900)]
Rollup merge of #103007 - albertlarsan68:better-python-discovery, r=jyn514
Add better python discovery
The Microsoft Store version of Python installs itself as `pythonM.m`, with `M` being the major version and `m` the minor.
The `x.ps1` script will now search for python executables whose command matches the regex `python\d`.
The `\d` at the end is to protect from using the `pythonw` versions, which do not work as standard python.
bors [Mon, 31 Oct 2022 18:50:06 +0000 (18:50 +0000)]
Auto merge of #103795 - thomcc:untest, r=Mark-Simulacrum
Include both benchmarks and tests in the numbers given to `TeFiltered{,Out}`
Fixes #103794
`#[bench]` is broken on nightly without this, sadly. It apparently has no test coverage. In addition to manually testing, I've added a run-make smokecheck for this (which would have caught the issue), but it would be nice to have a better way to test, err, libtest. For now we should get this in ASAP IMO
Amanieu d'Antras [Fri, 14 Oct 2022 01:24:58 +0000 (02:24 +0100)]
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).
Dylan DPC [Mon, 31 Oct 2022 09:22:57 +0000 (14:52 +0530)]
Rollup merge of #103766 - lukas-code:error-in-core, r=Dylan-DPC
Add tracking issue to `error_in_core`
This was merged in https://github.com/rust-lang/rust/pull/99917 without a tracking issue, so I'm creating one now: https://github.com/rust-lang/rust/issues/103765
The changes in this commit caused several bugs/incompatibilities (https://github.com/rust-lang/rust/pull/101833#issuecomment-1270191721, https://github.com/rust-lang/rust/issues/102560). For now we're reverting this commit and will re-land it alongside fixes for those bugs.
bors [Mon, 31 Oct 2022 03:40:22 +0000 (03:40 +0000)]
Auto merge of #103787 - notriddle:rollup-q1vmxsb, r=notriddle
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`)
Michael Howell [Mon, 31 Oct 2022 02:31:40 +0000 (19:31 -0700)]
Rollup merge of #103764 - SarthakSingh31:issue-94187-2, r=compiler-errors
All verbosity checks in `PrettyPrinter` now go through `PrettyPrinter::should_print_verbose`
Follow-up to #103428. That pr only partially fixed #94187. In some cases (like closures) `std::any::type_name` was still producing a different output when `-Zverbose` was enabled.
This pr fixes those cases and adds a new function `PrettyPrinter::should_print_verbose`. This function should always be used over `self.tcx().sess.verbose()` inside a `impl PrettyPrinter`.
Michael Howell [Mon, 31 Oct 2022 02:31:38 +0000 (19:31 -0700)]
Rollup merge of #102689 - ayrtonm:master, r=cjgillot
Add a tier 3 target for the Sony PlayStation 1
This adds a tier 3 target, `mipsel-sony-psx`, for the Sony PlayStation 1. I've tested it pretty thoroughly with [this SDK](https://github.com/ayrtonm/psx-sdk-rs) I wrote for it.
From the [tier 3 target policy](https://doc.rust-lang.org/rustc/target-tier-policy.html#tier-3-target-policy) (I've omitted the subpoints for brevity, but read over everything)
> A tier 3 target must have a designated developer or developers (the "target maintainers") on record to be CCed when issues arise regarding the target. (The mechanism to track and CC such developers may evolve over time.)
I'd be the designated developer
> Targets must use naming consistent with any existing targets; for instance, a target for the same CPU or OS as an existing Rust target should use the same name for that CPU or OS. Targets should normally use the same names and naming conventions as used elsewhere in the broader ecosystem beyond Rust (such as in other toolchains), unless they have a very good reason to diverge. Changing the name of a target can be highly disruptive, especially once the target reaches a higher tier, so getting the name right is important even for a tier 3 target.
The target name follows the conventions of the existing PSP target (`mipsel-sony-psp`) and uses `psx` following the convention of the broader [PlayStation homebrew community](https://psx-spx.consoledev.net/).
> Tier 3 targets may have unusual requirements to build or use, but must not create legal issues or impose onerous legal terms for the Rust project or for Rust developers or users.
No legal issues with this target.
> Neither this policy nor any decisions made regarding targets shall create any binding agreement or estoppel by any party. If any member of an approving Rust team serves as one of the maintainers of a target, or has any legal or employment requirement (explicit or implicit) that might affect their decisions regarding a target, they must recuse themselves from any approval decisions regarding the target's tier status, though they may otherwise participate in discussions.
:+1:
> Tier 3 targets should attempt to implement as much of the standard libraries as possible and appropriate (core for most targets, alloc for targets that can support dynamic memory allocation, std for targets with an operating system or equivalent layer of system-provided functionality), but may leave some code unimplemented (either unavailable or stubbed out as appropriate), whether because the target makes it impossible to implement or challenging to implement. The authors of pull requests are not obligated to avoid calling any portions of the standard library on the basis of a tier 3 target not implementing those portions.
The psx supports `core` and `alloc`, but will likely not support `std` anytime soon.
> The target must provide documentation for the Rust community explaining how to build for the target, using cross-compilation if possible. If the target supports running binaries, or running tests (even if they do not pass), the documentation must explain how to run such binaries or tests for the target, using emulation if possible or dedicated hardware if necessary.
This target has an SDK and a `cargo-psx` tool for formatting binaries as psx executables. Documentation and examples are provided in the [psx-sdk-rs README](https://github.com/ayrtonm/psx-sdk-rs#psx-sdk-rs), the SDK and cargo tool are both available through crates.io and docs.rs has [SDK documentation](https://docs.rs/psx/latest/psx/).
> Tier 3 targets must not impose burden on the authors of pull requests, or other developers in the community, to maintain the target. In particular, do not post comments (automated or manual) on a PR that derail or suggest a block on the PR based on a tier 3 target. Do not send automated messages or notifications (via any medium, including via `@)` to a PR author or others involved with a PR regarding a tier 3 target, unless they have opted into such messages.
:+1:
> Patches adding or updating tier 3 targets must not break any existing tier 2 or tier 1 target, and must not knowingly break another tier 3 target without approval of either the compiler team or the maintainers of the other tier 3 target.
projects / rust.git / log