nils [Fri, 23 Dec 2022 17:02:13 +0000 (18:02 +0100)]
Rollup merge of #105661 - lcnr:evaluate-new, r=compiler-errors
implement the skeleton of the updated trait solver
cc ```@rust-lang/initiative-trait-system-refactor```
This is mostly following the architecture discussed in the types team meetup.
After discussing the desired changes for the trait solver, we encountered cyclic dependencies between them. Most notably between changing evaluate to be canonical and returning inference constraints. We cannot canonicalize evaluate without returning inference constraints due to coinductive cycles. However, caching inference constraints also relies on canonicalization. Implementing both of these changes at once in-place is not feasible.
This somewhat closely mirrors the current `evaluate` implementation with the following notable differences:
- it moves `project` into the core solver, allowing us to correctly deal with coinductive projections (will be required for implied bounds, perfect derive)
- it changes trait solver overflow to be non-fatal (required to backcompat breakage from changes to the iteration order of nested goals, deferred projection equality, generally very useful)
- it returns inference constraints and canonicalizes inputs and outputs (required for a lot things, most notably merging fulfill and evaluate, and deferred projection equality)
- it is implemented to work with lazy normalization
A lot of things aren't yet implemented, but the remaining FIXMEs should all be fairly self-contained and parallelizable. If the architecture looks correct and is what we want here, I would like to quickly merge this and then split the work.
bors [Fri, 23 Dec 2022 13:37:11 +0000 (13:37 +0000)]
Auto merge of #106053 - compiler-errors:incr-test-revision, r=Mark-Simulacrum
Take revision into account in non-incremental-mode `// incremental` tests
A UI test I added in #105983 confusingly [failed](https://github.com/rust-lang/rust/pull/106031#issuecomment-1362558067) in a merge because two different revisions raced with each other for the same incremental directory for a (non-incremental-mode, i.e. `src/test/ui`) UI test.
Let's take the revision name into account when generating an incremental directory so that other UI tests that combine `// incremental` and `// revisions` won't race and cause possible flakiness in CI.
`packed_simd_2` is only used as a dependency of `bytecount` which in turn is only used by `rustfmt`. I can't see any issue with the minor version bump.
The bigger jump is `getrandom@0.2.0` which is used by a number of things, but 0.2.8 is still semver compatible and there doesn't seem to be any worrying changes (see the [changelog](https://github.com/rust-random/getrandom/blob/master/CHANGELOG.md)). The only breaking change are the removal of XP, stdweb and CloudAbi support but these are not host targets and rustc lacks support for them in any case (stdweb development was [abandonded](https://rustsec.org/advisories/RUSTSEC-2020-0056.html), XP is [tier 3 and `no_std`](https://doc.rust-lang.org/beta/rustc/platform-support.html#tier-3) and CloubAbi is [no longer supported](https://github.com/rust-lang/rust/pull/78439)).
Note that this doesn't affect `getrandom@0.1.16` which is what std depends on and which is already using the latest version of `cfg-if` (besides, there are already plans to remove that entirely).
bors [Fri, 23 Dec 2022 02:44:32 +0000 (02:44 +0000)]
Auto merge of #106070 - matthiaskrgr:rollup-jv9ctkl, r=matthiaskrgr
Rollup of 6 pull requests
Successful merges:
- #105978 (Mark `proc_macro_decls_static` as always used)
- #106051 (Allow building std with cranelift)
- #106056 (Make `sess.bug` much less noisy)
- #106057 (Give a more helpful error for "trimmed_def_paths constructed")
- #106058 (Fix the issue number in comment for as_local_call_operand)
- #106059 (Avoid running the `Profile` step twice on `x setup`)
Matthias Krüger [Fri, 23 Dec 2022 00:17:52 +0000 (01:17 +0100)]
Rollup merge of #106059 - jyn514:setup-twice, r=Nilstrieb
Avoid running the `Profile` step twice on `x setup`
Prevents runs like the following:
```
$ x setup
Welcome to the Rust project! What do you want to do with x.py?
a) library: Contribute to the standard library
b) compiler: Contribute to the compiler itself
c) codegen: Contribute to the compiler, and also modify LLVM or codegen
d) tools: Contribute to tools which depend on the compiler, but do not modify it directly (e.g. rustdoc, clippy, miri)
e) user: Install Rust from source
Please choose one (a/b/c/d/e): b
To get started, try one of the following commands:
- `x.py check`
- `x.py build`
- `x.py test`
For more suggestions, see https://rustc-dev-guide.rust-lang.org/building/suggested.html
`x.py` will now use the configuration at /home/nilsh/projects/rustfast/src/bootstrap/defaults/config.compiler.toml
Welcome to the Rust project! What do you want to do with x.py?
...
```
Matthias Krüger [Fri, 23 Dec 2022 00:17:51 +0000 (01:17 +0100)]
Rollup merge of #106056 - jyn514:quiet-bug, r=compiler-errors
Make `sess.bug` much less noisy
cc https://rust-lang.zulipchat.com/#narrow/stream/122651-general/topic/ice.20debugging/near/315929150
Before:
<details>
```
Compiling core v0.0.0 (C:\Users\Joshua Nelson\src\rust2\library\core)
error: internal compiler error: no warnings or errors encountered even though `delayed_good_path_bugs` issued
note: some of the compiler flags provided by cargo are hidden
query stack during panic:
end of query stack
error: could not compile `core`
```
</details>
After:
<details>
```
Compiling core v0.0.0 (C:\Users\Joshua Nelson\src\rust2\library\core)
error: internal compiler error: no warnings or errors encountered even though `delayed_good_path_bugs` issued
Matthias Krüger [Fri, 23 Dec 2022 00:17:50 +0000 (01:17 +0100)]
Rollup merge of #105978 - jyn514:unused_proc_macro_decl, r=tmiasko
Mark `proc_macro_decls_static` as always used
This would have avoided a bug in https://github.com/rust-lang/rust/pull/104860.
In practice this shouldn't matter since nothing uses the query other than the `dead_code` lint, but this isn't documented as an internal-only query so it seems nice for it to be accurate. I think for `dead_code` it doesn't matter because the relevant code is generated by `rustc_builtin_macros` and isn't linted.
I think `@tmiasko` or `@bjorn3` would be a good reviewer?
bors [Fri, 23 Dec 2022 00:02:15 +0000 (00:02 +0000)]
Auto merge of #105036 - jyn514:cargo-docs, r=Mark-Simulacrum
Support documenting cargo
The primary motivation is to have the cargo docs show up on https://doc.rust-lang.org/nightly/nightly-rustc/cargo, but as a nice side effect this makes `x doc cargo` work locally.
bors [Thu, 22 Dec 2022 20:48:33 +0000 (20:48 +0000)]
Auto merge of #106054 - matthiaskrgr:rollup-38epsfh, r=matthiaskrgr
Rollup of 6 pull requests
Successful merges:
- #105567 (KCFI test: Also support LLVM 16 output)
- #105847 (Ensure param-env is const before calling `eval_to_valtree`)
- #105983 (Add a missing early return in drop tracking `handle_uninhabited_return`)
- #106027 (rustdoc: simplify CSS and DOM for more-scraped-examples)
- #106035 (Migrate search tab title color to CSS variable)
- #106037 (Add regression test for #94293)
Joshua Nelson [Mon, 28 Nov 2022 23:10:44 +0000 (18:10 -0500)]
Support documenting Cargo
The primary motivation is to have the cargo docs show up on https://doc.rust-lang.org/nightly/nightly-rustc/cargo, but as a nice side effect this makes `x doc cargo` work locally.
Joshua Nelson [Thu, 22 Dec 2022 19:21:48 +0000 (13:21 -0600)]
Avoid running the `Profile` step twice on `x setup`
Prevents runs like the following:
```
$ x setup
Welcome to the Rust project! What do you want to do with x.py?
a) library: Contribute to the standard library
b) compiler: Contribute to the compiler itself
c) codegen: Contribute to the compiler, and also modify LLVM or codegen
d) tools: Contribute to tools which depend on the compiler, but do not modify it directly (e.g. rustdoc, clippy, miri)
e) user: Install Rust from source
Please choose one (a/b/c/d/e): b
To get started, try one of the following commands:
- `x.py check`
- `x.py build`
- `x.py test`
For more suggestions, see https://rustc-dev-guide.rust-lang.org/building/suggested.html
`x.py` will now use the configuration at /home/nilsh/projects/rustfast/src/bootstrap/defaults/config.compiler.toml
Welcome to the Rust project! What do you want to do with x.py?
...
```
Joshua Nelson [Thu, 22 Dec 2022 18:43:27 +0000 (12:43 -0600)]
Make `sess.bug` much less noisy
Before:
```
Compiling core v0.0.0 (C:\Users\Joshua Nelson\src\rust2\library\core)
error: internal compiler error: no warnings or errors encountered even though `delayed_good_path_bugs` issued
note: some of the compiler flags provided by cargo are hidden
query stack during panic:
end of query stack
error: could not compile `core`
```
After:
```
Compiling core v0.0.0 (C:\Users\Joshua Nelson\src\rust2\library\core)
error: internal compiler error: no warnings or errors encountered even though `delayed_good_path_bugs` issued
Matthias Krüger [Thu, 22 Dec 2022 18:36:13 +0000 (19:36 +0100)]
Rollup merge of #105847 - compiler-errors:issue-104396, r=oli-obk
Ensure param-env is const before calling `eval_to_valtree`
Other queries call `ParamEnv::with_const` *inside* of the query itself (e.g. `const_eval_global_id_for_typeck`), so this could alternatively be moved into the provider of `eval_to_valtree` instead. I don't have a particularly strong opinion, though *theoretically* caching is better if we make the query keys more constrained.
I'm not exactly sure how this is an effect of the `-Zmir-opt-level=3` flag. Maybe something about the inliner causes us to inline an unevaluated const into a body where it can be evaluated, but where it has not yet been normalized.
This seems likely, since we're inlining `from_fn_1::<{ N / 2 }, _>` in `from_fn_2`, which means that we will need to evaluate that constant during the const prop pass after inlining.
Matthias Krüger [Thu, 22 Dec 2022 18:36:12 +0000 (19:36 +0100)]
Rollup merge of #105567 - TimNN:kcfi16, r=nikic
KCFI test: Also support LLVM 16 output
With a regex we can support the LLVM 16 output now already (and there are some third-party build bots that test Rust with LLVM head, like https://buildkite.com/llvm-project/rust-llvm-integrate-prototype/builds?branch=master).
Joshua Nelson [Thu, 22 Dec 2022 17:16:29 +0000 (11:16 -0600)]
Mark `proc_macro_decls_static` as always used
This would have avoided a bug in https://github.com/rust-lang/rust/pull/104860.
In practice this shouldn't matter since nothing uses the query other than the `dead_code` lint,
but this isn't documented as an internal-only query so it seems nice for it to be accurate.
I think for `dead_code` it doesn't matter because the relevant code is generated by `rustc_builtin_macros` and isn't linted.
Nikita Popov [Tue, 20 Dec 2022 16:07:04 +0000 (17:07 +0100)]
Use LLVM_CMAKE_DIR for lld build
LLVM_CONFIG_PATH is no longer supported as of LLVM 16, switch to
using the cmake module instead.
We separately return the llvm-config and cmake directory paths,
because llvm-config always refers to the host binary, while
the cmake directory is for the target triple.
bors [Thu, 22 Dec 2022 11:06:51 +0000 (11:06 +0000)]
Auto merge of #106034 - matthiaskrgr:rollup-2zpql33, r=matthiaskrgr
Rollup of 8 pull requests
Successful merges:
- #104741 (Switch `#[track_caller]` back to a no-op unless feature gate is enabled)
- #105769 (add function to tell the identical errors for ambiguity_errors)
- #105843 (Suggest associated const on possible capitalization mistake)
- #105966 (Re-enable `Fn` trait call notation error for non-tuple argument)
- #106002 (codegen tests: adapt patterns to also work with v0 symbol mangling)
- #106010 (Give opaque types a better coherence error)
- #106016 (rustdoc: simplify link anchor to section expand JS)
- #106024 (Fix ICE due to `todo!()` in `rustdoc` for `Term`s)
Matthias Krüger [Thu, 22 Dec 2022 10:03:51 +0000 (11:03 +0100)]
Rollup merge of #106002 - krasimirgg:v0sym, r=tmiasko
codegen tests: adapt patterns to also work with v0 symbol mangling
No functional changes intended.
These tests were failing under `new-symbol-mangling = true`, cf. https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/a.20few.20panic-abort.20tests.20fail.20under.20.60new-symbol-mangling.60.
This adapts the patterns to work in this case.
Matthias Krüger [Thu, 22 Dec 2022 10:03:50 +0000 (11:03 +0100)]
Rollup merge of #105769 - lyming2007:issue-105177-fix, r=eholk
add function to tell the identical errors for ambiguity_errors
if 2 errors of the kind and ident and span of the ident, b1, b2 and misc1 misc2 are the same we call these 2 ambiguity errors identical
prevent identical ambiguity error from pushing into vector of ambiguity_errors this will fix #105177
Matthias Krüger [Thu, 22 Dec 2022 10:03:49 +0000 (11:03 +0100)]
Rollup merge of #104741 - bryangarza:bug-104588-async-track-caller, r=compiler-errors
Switch `#[track_caller]` back to a no-op unless feature gate is enabled
This patch fixes a regression, in which `#[track_caller]`, which was previously a no-op, was changed to actually turn on the behavior. This should instead only happen behind the `closure_track_caller` feature gate.
Also, add a warning for the user to understand how their code will compile depending on the feature gate being turned on or not.
bors [Thu, 22 Dec 2022 08:37:58 +0000 (08:37 +0000)]
Auto merge of #104889 - GuillaumeGomez:fix-impl-block-in-const-expr, r=notriddle
Fix impl block in const expr
Fixes #83026.
The problem was that we didn't visit block expressions. Considering how big the [walk_expr](https://doc.rust-lang.org/nightly/nightly-rustc/src/rustc_hir/intravisit.rs.html#678) function is, I decided to instead implement the `hir` visitor on the struct. It also answers the question which was in a comment for `RustdocVisitor`: we should have used a visitor instead of our ad-hoc implementation.
Adding this visitor also added some extra checks that weren't present before (check changes in `rustdoc-ui` tests).
bors [Thu, 22 Dec 2022 05:30:00 +0000 (05:30 +0000)]
Auto merge of #106025 - matthiaskrgr:rollup-vz5rqah, r=matthiaskrgr
Rollup of 6 pull requests
Successful merges:
- #105837 (Don't ICE in `check_must_not_suspend_ty` for mismatched tuple arity)
- #105932 (Correct branch-protection ModFlagBehavior for Aarch64 on LLVM-15)
- #105960 (Various cleanups)
- #105985 (Method chain nitpicks)
- #105996 (Test that async blocks are `UnwindSafe`)
- #106012 (Clarify that raw retags are not permitted in Mir)
bors [Thu, 22 Dec 2022 02:16:59 +0000 (02:16 +0000)]
Auto merge of #106023 - JohnTitor:rollup-k8mettz, r=JohnTitor
Rollup of 8 pull requests
Successful merges:
- #105584 (add assert messages if chunks/windows are length 0)
- #105602 (interpret: add read_machine_[ui]size convenience methods)
- #105824 (str.lines() docstring: clarify that line endings are not returned)
- #105980 (Refer to "Waker" rather than "RawWaker" in `drop` comment)
- #105986 (Fix typo in reading_half_a_pointer.rs)
- #105995 (Add regression test for #96530)
- #106008 (Sort lint_groups in no_lint_suggestion)
- #106014 (Add comment explaining what the scrape-examples-toggle.goml GUI test is about)
Matthias Krüger [Thu, 22 Dec 2022 00:01:13 +0000 (01:01 +0100)]
Rollup merge of #105932 - MasterAwesome:aarch64-bti-llvm-15, r=nikic
Correct branch-protection ModFlagBehavior for Aarch64 on LLVM-15
When building with Fat LTO and BTI enabled on aarch64, the BTI is set to `Module::Min` for alloc shim but is set to `Module::Error` for the crate. This was fine when we were using LLVM-14 but LLVM-15 changes it's behaviour to support for compiling with different `mbranch-protection` flags.
Yuki Okushi [Wed, 21 Dec 2022 23:32:12 +0000 (08:32 +0900)]
Rollup merge of #106008 - uweigand:s390x-lintgroup-order, r=Nilstrieb
Sort lint_groups in no_lint_suggestion
The no_lint_suggestion routine passes a vector of lint group names to find_best_match_for_name. That routine depends on the sort order of its input vector, which matters in case multiple inputs are at the same Levenshtein distance to the target name.
However, no_lint_suggestion currently just passes lint_groups.keys() as input vector - this is sorted in hash value order, which is not guaranteed to be stable, and in fact differs between big- and little-endian host platforms, causing test failures on s390x.
To fix this, always sort the lint groups before using their names as input to find_best_match_for_name. In doing so, prefer non- deprecated lint group names over deprecated ones, and then use alphabetical order.
Yuki Okushi [Wed, 21 Dec 2022 23:32:10 +0000 (08:32 +0900)]
Rollup merge of #105824 - zacchiro:patch-1, r=JohnTitor
str.lines() docstring: clarify that line endings are not returned
Previously, the str.lines() docstring stated that lines are split at line endings, but not whether those were returned or not. This new version of the docstring states this explicitly, avoiding the need of getting to doctests to get an answer to this FAQ.
bors [Wed, 21 Dec 2022 23:20:04 +0000 (23:20 +0000)]
Auto merge of #105613 - Nilstrieb:rename-assert_uninit_valid, r=RalfJung
Rename `assert_uninit_valid` intrinsic
It's not about "uninit" anymore but about "filling with 0x01 bytes" so the name should at least try to reflect that.
This is actually not fully correct though, as it does still panic for all uninit with `-Zstrict-init-checks`. I'm not sure what the best way is to deal with that not causing confusion. I guess we could just remove the flag? I don't think having it makes a lot of sense anymore with the direction that we have chose to go. It could be relevant again if #100423 lands so removing it may be a bit over eager.
bors [Wed, 21 Dec 2022 20:19:22 +0000 (20:19 +0000)]
Auto merge of #105979 - matthiaskrgr:rollup-2luw3mx, r=matthiaskrgr
Rollup of 8 pull requests
Successful merges:
- #105791 (docs: add long error explanation for error E0472)
- #105897 (Fix an opaque type ICE)
- #105904 (Fix arch flag on i686-apple-darwin)
- #105949 (Bump `cfg-if` to `1.0` in rustc crates)
- #105964 (rustdoc: prevent CSS layout of line numbers shrinking into nothing)
- #105972 (rustdoc: simplify section anchor CSS)
- #105973 (Avoid going through the happy path in case of non-fn builtin calls)
- #105976 (Remove unused `check-stage2-T-arm-linux-androideabi-H-x86_64-unknown-linux-gnu` make rule)
Ulrich Weigand [Wed, 21 Dec 2022 16:27:45 +0000 (17:27 +0100)]
Sort lint_groups in no_lint_suggestion
The no_lint_suggestion routine passes a vector of lint group names
to find_best_match_for_name. That routine depends on the sort
order of its input vector, which matters in case multiple inputs
are at the same Levenshtein distance to the target name.
However, no_lint_suggestion currently just passes lint_groups.keys()
as input vector - this is sorted in hash value order, which is not
guaranteed to be stable, and in fact differs between big- and
little-endian host platforms, causing test failures on s390x.
To fix this, always sort the lint groups before using their names
as input to find_best_match_for_name. In addition, deprecated
lint groups should never be suggested, so filter those out.
bors [Wed, 21 Dec 2022 14:27:57 +0000 (14:27 +0000)]
Auto merge of #100390 - jhpratt:float-from-bool, r=dtolnay
Implement `From<bool>` for f32, f64
As is required for trait implementations, these are insta-stable. Given there is a release tomorrow and this needs FCP, I set 1.65 as the stable version.
Bryan Garza [Thu, 24 Nov 2022 03:39:47 +0000 (03:39 +0000)]
Update code based on PR comments
This patch does the following:
- Refactor some repeated lines into a single one
- Split the `ungated_async_fn_caller` lint into multiple lines, and make
one of those lines only print out on nightly
- Use test revisions instead of copying an existing test
Bryan Garza [Tue, 22 Nov 2022 21:15:27 +0000 (21:15 +0000)]
Switch `#[track_caller]` back to a no-op unless feature gate is enabled
This patch fixes a regression, in which `#[track_caller]`, which was
previously a no-op, was changed to actually turn on the behavior. This
should instead only happen behind the `closure_track_caller` feature
gate.
Also, add a warning for the user to understand how their code will
compile depending on the feature gate being turned on or not.
Matthias Krüger [Tue, 20 Dec 2022 22:35:17 +0000 (23:35 +0100)]
Rollup merge of #105976 - jyn514:unused-make-targets, r=Mark-Simulacrum
Remove unused `check-stage2-T-arm-linux-androideabi-H-x86_64-unknown-linux-gnu` make rule
It's not used anywhere in CI, and it seems of questionable use. It was first added in 0e272de69f4a9c889e5f1a024a88b3e1f60cb6c5, which looks like it's just intended for CI, not as a user-facing feature.
Matthias Krüger [Tue, 20 Dec 2022 22:35:17 +0000 (23:35 +0100)]
Rollup merge of #105973 - oli-obk:simplify_callee_checks, r=jackh726
Avoid going through the happy path in case of non-fn builtin calls
No functional change, just doing an early return. The removed comment is not applicable anymore, not every node needs type bindings in the error case. At best this would have been needed to avoid ICEs, but afaict this can't happen anymore today, as we do fallible checks.