docs/test: add UI test and long-form error docs for `E0461`
Might take a couple of tries to pass CI. The UI test is x86-linux only; I'm not sure how to generalize it to other architectures.
r? ``@GuillaumeGomez``
Some `compare_method` tweaks
1. Make some of the comparison functions' names more regular
2. Reduce pub scope of some of the things in `compare_method`
~3. Remove some unnecessary opaque type handling code -- `InferCtxt` already is in a mode that doesn't define opaque types~
* moved to a different PR
4. Bubble up `ErrorGuaranteed` for region constraint errors in `compare_method` - Improves a redundant error message in one unit test.
5. Move the `compare_method` module to have a more general name, since it's more like `compare_impl_item` :)
6. Rename `collect_trait_impl_trait_tys`
Remove some totally duplicated files in `rustc_infer`
I have no idea why or how I duplicated these files from `compiler/rustc_infer/src/infer/error_reporting/note.rs`, but I did by accident, and nothing caught it 🤦
Implement allow-by-default `multiple_supertrait_upcastable` lint
The lint detects when an object-safe trait has multiple supertraits.
Enabled in libcore and liballoc as they are low-level enough that many embedded programs will use them.
r? `@nikomatsakis`
Account for `match` expr in single line
When encountering `match Some(42) { Some(x) => x, None => "" };`, output
```
error[E0308]: `match` arms have incompatible types
--> f53.rs:2:52
|
2 | let _ = match Some(42) { Some(x) => x, None => "" };
| -------------- - ^^ expected integer, found `&str`
| | |
| | this is found to be of type `{integer}`
| `match` arms have incompatible types
```
Always suggest as `MachineApplicable` in `recover_intersection_pat`
This resolves one FIXME in `recover_intersection_pat` by always applying `MachineApplicable` when suggesting, as `bindings_after_at` is now stable.
This also separates a test to apply `// run-rustfix`.
Signed-off-by: Yuki Okushi <jtitor@2k36.org>
Rollup of 4 pull requests
Successful merges:
- #105515 (Account for macros in const generics)
- #106146 (Readme: update section on how to run `x.py`)
- #106150 (Detect when method call on LHS might be shadowed)
- #106174 (Remove unused empty CSS rules in ayu theme)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Fix incorrect span when using byte-escaped rbrace
Fix#103826, a format args span issue introduced in #102214.
The current solution for tracking skipped characters made it so that certain situations were ambiguous enough that the original span couldn't be worked out later. This PR improves on the original solution by keeping track of groups of skipped characters using a map, and fixes the previous bug. See an example of this ambiguity in the [previous PR's discussion](https://github.com/rust-lang/rust/pull/102214#issuecomment-1258711015).
Don't perform invalid checks in `codegen_attrs`
The attributes `#[track_caller]` and `#[cmse_nonsecure_entry]` are only valid on functions. When validating one of these attributes, codegen_attrs previously called `fn_sig`, [which can only be used on functions](https://github.com/rust-lang/rust/pull/105201), on the item the attribute was attached to, assuming that the item was a function without checking. This led to [ICEs in situations where the attribute was incorrectly used on non-functions](https://github.com/rust-lang/rust/issues/105594).
With this change, we skip calling `fn_sig` if the item the attribute is attached to must be a function but isn't, because `check_attr` will reject such cases without codegen_attrs's intervention.
As a side note, some of the attributes in codegen_attrs are only valid on functions, but that property isn't actually checked. I'm planning to fix that in a follow up PR since it's a behavior change that will need to be validated rather than an obvious bugfix. Thankfully, all the attributes like that I've found so far are unstable.
Fixes#105594.
r? `@cjgillot`
Remove wrapper functions for some unstable options
They are trivial and just forward to the option. Like most other options, we can just access it directly.
abort immediately on bad mem::zeroed/uninit
Now that we have non-unwinding panics, let's use them for these assertions. This re-establishes the property that `mem::uninitialized` and `mem::zeroed` will never unwind -- the earlier approach of causing panics here sometimes led to hard-to-debug segfaults when the surrounding code was not able to cope with the unexpected unwinding.
Cc `@bjorn3` I did not touch cranelift but I assume it needs a similar patch. However it has a `codegen_panic` abstraction that I did not want to touch since I didn't know how else it is used.
Using that options basically changes all stable hashes we may compute.
Adding/removing as UNTRACKED it makes everything ICE (unstable fingerprint
everywhere). As TRACKED, it can still do its job without ICEing.
Rollup of 6 pull requests
Successful merges:
- #105661 (implement the skeleton of the updated trait solver)
- #105853 (Make the pre-push script work on directories with spaces)
- #106043 (Move tests)
- #106048 (Run `tidy` in its own job in PR CI)
- #106055 (Check arg expressions properly on error in `confirm_builtin_call`)
- #106067 (A few metadata nits)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
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.
r? ```@compiler-errors``` / ```@rust-lang/types``` :3
Allow building std with cranelift
- Don't pass llvm-specific args when using cranelift
- Don't use `asm` in compiler_builtins when using cranelift
r? `@bjorn3` cc `@Mark-Simulacrum`
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?
r? `@tmiasko`
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)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Add a missing early return in drop tracking `handle_uninhabited_return`
This return is needed so we don't call `Ty::is_inhabited_from` from a type with ty/ct vars in it.
Fixes#105981
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.
Fixes#104396
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.
Retag as FnEntry on `drop_in_place`
This commit changes the mir drop shim to always retag its argument as if it were a `&mut`.
cc rust-lang/unsafe-code-guidelines#373
Re-enable `Fn` trait call notation error for non-tuple argument
I have no idea why I delayed this bug... but also there doesn't seem to be a UI test that actually shows a change, so maybe that's why.
Fixes#105936
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
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.
Fixes#104588
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)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Clarify that raw retags are not permitted in Mir
Not sure when this changed, but documentation and the validator needed to be updated. This also removes raw retags from custom mir.
cc rust-lang/miri#2735
r? `@RalfJung`
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.
Refer:
b0343a38a5
fixes https://github.com/rust-lang/rust/issues/102162
Don't ICE in `check_must_not_suspend_ty` for mismatched tuple arity
These expressions are just used for their spans, so make it best-effort here.
Fixes#105728
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.
Fixes https://github.com/rust-lang/rust/issues/105379
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.
r? `@RalfJung`
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)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
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.
Fixes https://github.com/rust-lang/rust/issues/105379
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
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.
Fixes#104588
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.
Bump `cfg-if` to `1.0` in rustc crates
When `packed_simd_2` and `getrandom` are updated to newer versions, we will no longer have a dependency on old `cfg_if` versions.
Fix an opaque type ICE
fixes#104551
The issue is that if you have
```rust
type T = impl Sized;
let (_a, _b): T = ..
```
we have only the type annotation `T`, but want to use that ascription for `_a` and `_b`, so what we generate is a type ascription plus a field projection saying `_a`'s type is `T::0`. Of course `T` has no fields. Of course we could also not generate type annotations for projections into opaque types at all, but that's more fragile, as we now have to make sure that 12bbdbdb44/compiler/rustc_mir_build/src/build/matches/mod.rs (L709) doesn't have any arm that introduces a user type annotation except for `PatKind::Binding`.
docs: add long error explanation for error E0472
Add long-form error docs for E0472: "inline assembly not supported on this target" and update UI tests.
R? `@GuillaumeGomez`
Implement va_list and va_arg for s390x FFI
Following the s390x ELF ABI and based on the clang implementation, provide appropriate definitions of va_list in library/core/src/ffi/mod.rs and va_arg handling in compiler/rustc_codegen_llvm/src/va_arg.rs.
Fixes the following test cases on s390x:
src/test/run-make-fulldeps/c-link-to-rust-va-list-fn src/test/ui/abi/variadic-ffi.rs
Fixes https://github.com/rust-lang/rust/issues/84628.
Rollup of 5 pull requests
Successful merges:
- #105901 (Don't panic on stable since miri is not available there)
- #105912 (rustdoc: force pre tags to have the default line height)
- #105914 (rustdoc: Simplify CSS for scraped code examples code blocks)
- #105933 (Add readable rustdoc display for tvOS and watchOS)
- #105935 (docs/test: add UI test and long-form error docs for `E0377`)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Improve syntax of `newtype_index`
This makes it more like proper Rust and also makes the implementation a lot simpler.
Mostly just turns weird flags in the body into proper attributes.
It should probably also be converted to an attribute macro instead of function-like, but that can be done in a future PR.
Add `IMPLIED_BOUNDS_ENTAILMENT` lint
Implements a lint (#105572) version of the hard-error introduced in #105483. Context is in that PR.
r? `@lcnr`
cc `@oli-obk` who had asked for this to be a lint first
Not sure if this needs to be an FCP, since it's a lint for now.
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.
Refer:
b0343a38a5
Revert #103880 "Use non-ascribed type as field's type in mir"
This PR prepares a revert for #103880 to fix#105809, #105881, #105886 and others (like the duplicates of the first one), in case an actual fix can't get done today.
I've also added the MCVE from #105809. There is no MCVE for the #105881 and #105886 ICEs yet however, so there are no tests for them here, although we'll need one before relanding the original changes.
Were this PR to land, it would also reopen#96514 as it was fixed by the original PR.
Opening as draft to allow time for a possible fix.
r? `@jackh726`
The src/test/ui/issues/issue-74564-if-expr-stack-overflow.rs test case
added to verify https://github.com/rust-lang/rust/issues/74564 still
crashes with a stack overflow on s390x-ibm-linux.
Symptom is a very deep recursion in compiler/rustc_lint/src/early.rs:
fn visit_expr(&mut self, e: &'a ast::Expr) {
self.with_lint_attrs(e.id, &e.attrs, |cx| {
lint_callback!(cx, check_expr, e);
ast_visit::walk_expr(cx, e);
})
}
(where walk_expr recursively calls back into visit_expr). The crash
happens at a nesting depth of over 17000 stack frames when using the
default 8 MB stack size on s390x.
This patch fixes the problem by adding a ensure_sufficient_stack
call to the with_lint_attrs routine (which also should take care
of all the other mutually recursive visitors here).
Fixes part of https://github.com/rust-lang/rust/issues/105383.
Following the s390x ELF ABI and based on the clang implementation,
provide appropriate definitions of va_list in library/core/src/ffi/mod.rs
and va_arg handling in compiler/rustc_codegen_llvm/src/va_arg.rs.
Fixes the following test cases on s390x:
src/test/run-make-fulldeps/c-link-to-rust-va-list-fn
src/test/ui/abi/variadic-ffi.rs
Fixes https://github.com/rust-lang/rust/issues/84628.
Revert "Replace usage of `ResumeTy` in async lowering with `Context`"
Reverts rust-lang/rust#105250
Fixes: #105501
Following instructions from [forge](https://forge.rust-lang.org/compiler/reviews.html#reverts).
This change introduced a breaking change that is not actionable nor relevant, and is blocking updates to our toolchain. Along with other comments on the CL marking issues that are fixed by reverts, reverting is best until these issues can be resolved
cc. `@Swatinem`
Add long error docs for `E0460` and `E0457`
Final docs for errors in #61137 that have UI tests, my next PRs will also add these tests.
r? ``@GuillaumeGomez``
if 2 errors of the kind and ident and span of the ident, b1, b2 and misc1 misc2 are the same
then these 2 ambiguity errors matched
prevent identical ambiguity error from pushing into vector of ambiguity_errors
this will fix#105177
Rollup of 8 pull requests
Successful merges:
- #105419 (Add tests for #41731)
- #105447 (Add a test for #103095)
- #105842 (print argument name in arg mismatch if possible)
- #105863 (Update browser-ui-test version to reduce GUI tests flakyness)
- #105867 (remove redundant fn params that were only "used" in recursion)
- #105869 (don't clone Copy types)
- #105873 (use &str / String literals instead of format!())
- #105879 (Revert "Introduce lowering_arena to avoid creating AST nodes on the fly")
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Revert "Introduce lowering_arena to avoid creating AST nodes on the fly"
This reverts commit d9a1faaa9c (#101499).
This was originally part of #101345 which has now been closed as a different approach is taken now.
r? `@oli-obk`
cc `@spastorino`
print argument name in arg mismatch if possible
A bit more contextual than just `/* value */`, at least when the argument is named something related to its context.
The UI test cases are... not super convincing, but also they're minimized tests.
Remove the `..` from the body, only a few invocations used it and it's
inconsistent with rust syntax.
Use `;` instead of `,` between consts. As the Rust syntax gods inteded.
This removes the `custom` format functionality as its only user was
trivially migrated to using a normal format.
If a new use case for a custom formatting impl pops up, you can add it
back.
Migrate rustc_mir_build diagnostics
Rebases https://github.com/rust-lang/rust/pull/100854
~~The remaining issue is how to better resolve 72bea68af4~~
~~The diagnostic macros seems to generate a broken diagnostic, and I couldn't figure out how to manually format the fluent message, so I hardcoded the format string for now. I'd like pointers to a better fix for this.~~
Also, I'm not 100% sure I didn't mess up a rebase somewhere 🙂
r? `@davidtwco`
Support call and drop terminators in custom mir
The only caveat with this change is that cleanup blocks are not supported. I would like to add them, but it's not quite clear to me what the best way to do that is, so I'll have to think about it some more.
r? ``@oli-obk``
Don't copy symbols from dylibs with `-Zdylib-lto`
When `rustc_driver` started being built with `-Zdylib-lto -Clto=thin`, some libstd symbols were copied by the LTO process into the dylib. That causes duplicate local symbols that are not present otherwise.
Depending on the situation (lib loading order apparently), the duplicated symbols could cause issues: `rustc_driver` overrode the panic hook, but it didn't apply to rustc main's hook (the default from libstd). This is the cause of #105637, in some situations the panic hook installed by `rustc_driver` isn't executed, and only libstd's backtrace is shown (and a double panic). The query stack, as well as the various notes to open a GH about the ICE, don't appear.
It's not clear exactly what is needed to trigger the issue, but I have simulated a reproducer [here](https://github.com/lqd/issue-105637) with cargo involved, the incorrect panic hook is executed on my machine. It is hard to reproduce in a unit test: `cargo run` + `rustup` involves LD_LIBRARY_PATH, which is not the case for `compiletest`. cargo also adds unconditional flags that are then overridden in [`bootstrap` when building rustc with `rust.lto = thin`](9c07efe84f/src/bootstrap/compile.rs (L702-L714)) as done on CI).
All this to say the compilation and execution environment in `bootstrap` leading to the bug building `rustc_driver` is different from our UI tests, and I believe one of the reasons it's hard to make an exact reproducer test. Thankfully there's _still_ a difference in the behavior though: although in the unit test the correct panic hook seems to be executed compared to my repro and the current nightly, only the fix removes the double panic here.
The `7e8277aefa12f1469fb1df01418ff5846a7854a9` `try` build:
- fixes the reproducer repo linked above
- restores the ICE messages from https://github.com/rust-lang/rust/issues/105321 back to the state in its OP compared to the description in https://github.com/rust-lang/rust/issues/105637
- restores the ICE message and the query stack from https://github.com/rust-lang/rust/issues/105777 compared to nightly
While I believe this technically fixes the P-critical issue https://github.com/rust-lang/rust/issues/105637, I would not want to close it yet as we may want to backport to beta/stable (if a point release happens, it would fix the ICEs reported on 1.66.0, which is built with ThinLTO on linux). Once this PR lands, I'll also open another PR to re-enable ThinLTO on x64 darwin's dist builder.
Rollup of 6 pull requests
Successful merges:
- #105493 (Help rust-analyzer normalize query return types)
- #105710 (Don't bug if we're trying to cast `dyn*` to another type)
- #105711 (bail in `collect_trait_impl_trait_tys` if signatures reference errors)
- #105768 (Detect inherent associated types not having CamelCase)
- #105780 (rustdoc: Don't add "Read more" link if there is no extra content)
- #105802 (Make enum-match.rs test robust against variable name changes)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Stabilize default_alloc_error_handler
Tracking issue: #66741
This turns `feature(default_alloc_error_handler)` on by default, which causes the compiler to automatically generate a default OOM handler which panics if `#[alloc_error_handler]` is not provided.
The FCP completed over 2 years ago but the stabilization was blocked due to an issue with unwinding. This was fixed by #88098 so stabilization can be unblocked.
Closes#66741
Rewrite `E0158` error-code docs for clarity
Fixes#105585.
The `E0158` error-code docs are unclear. It doesn't explain all three different variants of the error and doesn't explain *why* the error occurs. This PR cleans it up a bit and brings it properly into line with [RFC1567](https://rust-lang.github.io/rfcs/1567-long-error-codes-explanation-normalization.html).
I'm a first time Rust contributor so I've probably not got it quite right. I also haven't run the whole build process because I assume that my minor docs changes shouldn't break everything.
always use `anonymize_bound_vars`
Unless this is perf-sensitive, it's probably best to always use one anonymize function that does the right thing for all bound vars.
r? types
Move `TypeckResults` to separate module
`ty::context` is really big and the typeck results aren't directly related to `TyCtxt`, so move them to a separate module. Also contains a small drive-by macro "improvement".
Custom MIR: Many more improvements
Commits are each atomic changes, best reviewed one at a time, with the exception that the last commit includes all the documentation.
### First commit
Unsafetyck was not correctly disabled before for `dialect = "built"` custom MIR. This is fixed and a regression test is added.
### Second commit
Implements `Discriminant`, `SetDiscriminant`, and `SwitchInt`.
### Third commit
Implements indexing, field, and variant projections.
### Fourth commit
Documents the previous commits and everything else.
There is some amount of weirdness here due to having to beat Rust syntax into cooperating with MIR concepts, but it hopefully should not be too much. All of it is documented.
r? `@oli-obk`
always check alignment during CTFE
We originally disabled alignment checks because they got in the way -- there are some things we do with the interpreter during CTFE which does not correspond to actually running user-written code, but is purely administrative, and we didn't want alignment checks there, so we just disabled them entirely. But with `-Zextra-const-ub-checks` we anyway had to figure out how to disable those alignment checks while doing checks in regular code. So now it is easy to enable CTFE alignment checking by default. Let's see what the perf consequences of that are.
r? `@oli-obk`
Various cleanups to dest prop
This makes fixing the issues identified in #105577 easier. A couple changes
- Use an enum with names instead of a bool
- Only call `remove_candidates_if` from one place instead of two. Doing it from two places is far too fragile, since any divergence in the behavior between those callsites is likely to be unsound.
- Remove `is_constant`. Right now we only merge locals, so this doesn't do anything, and the logic would be wrong if it did.
r? `@tmiasko`
Auto traits in `dyn Trait + Auto` are suggestable
Not sure why I had made the `IsSuggestableVisitor` have that rule to not consider `dyn Trait + Auto` to be suggestable.
It's possible that this was done because of the fact that we don't print the right parentheses for `&(dyn Trait + Auto)`, but that's a problem with printing these types in general that we probably have tracked somewhere else...
Ensure async trait impls are async (or otherwise return an opaque type)
As a workaround for the full `#[refine]` semantics not being implemented
yet, forbit returning a concrete future type like `Box<dyn Future>` or a
manually implemented Future.
`-> impl Future` is still permitted; while that can also cause
accidental refinement, that's behind a different feature gate
(`return_position_impl_trait_in_trait`) and that problem exists
regardless of whether the trait method is async, so will have to be
solved more generally.
Fixes https://github.com/rust-lang/rust/issues/102745
Highlight conflicting param-env candidates, again
Un-reverts #98794 (i.e. reverts #99290).
The previous time I attempted to land this PR, it was because of an incremental issue (#99233). The repro instructions in the issue is no longer manifest the ICE -- I think it's because this ambiguity code was refactored (I think by `@lcnr)` to no longer store the ambiguities in the fulfillment error, but instead recompute them on the fly.
The main motivation for trying to re-land this is that it fixes#105131 by highlighting the root-cause of the issue, which is conflicting param-env candidates:
```
error[E0283]: type annotations needed: cannot satisfy `Self: Gen<'source>`
|
note: multiple `impl`s or `where` clauses satisfying `Self: Gen<'source>` found
--> $DIR/conflicting-bounds.rs:3:1
|
LL | pub trait Gen<'source> {
| ^^^^^^^^^^^^^^^^^^^^^^
...
LL | Self: for<'s> Gen<'s, Output = T>;
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^
error: aborting due to previous error
For more information about this error, try `rustc --explain E0283`.
```
Fixes#105131.
Fixes (again) #98786
Sync rustc_codegen_cranelift
This time there are a bunch of bugfixes, some new llvm intrinsic implementations and refactorings to the build system in preparation for running cg_clif tests as part of `./x.py test`.
r? `@ghost`
`@rustbot` label +A-codegen +A-cranelift +T-compiler
As a workaround for the full `#[refine]` semantics not being implemented
yet, forbit returning a concrete future type like `Box<dyn Future>` or a
manually implemented Future.
`-> impl Future` is still permitted; while that can also cause
accidental refinement, that's behind a different feature gate
(`return_position_impl_trait_in_trait`) and that problem exists
regardless of whether the trait method is async, so will have to be
solved more generally.
Fixes#102745
