Tweak debug outputs to make debugging new solver easier
1. Move the fields that are "most important" (I know this is subjective) to the beginning of the structs.
For goals, I typically care more about the predicate than the param-env (which is significantly longer in debug output).
For canonicalized things, I typically care more about what is *being* canonicalized.
For a canonical response, I typically care about the response -- or at least, it's typically useful to put it first since it's short and affects the whether the solver recurses or not...
2. Add some more debug and instrument calls to functions to add more structure to tracing lines.
r? `@oli-obk` or `@BoxyUwU` (since I think `@lcnr` is on holiday)
Allow `transmute`s to produce `OperandValue`s instead of needing `alloca`s
LLVM can usually optimize these away, but especially for things like transmutes of newtypes it's silly to generate the `alloc`+`store`+`load` at all when it's actually a nop at LLVM level.
LLVM can usually optimize these away, but especially for things like transmutes of newtypes it's silly to generate the `alloc`+`store`+`load` at all when it's actually a nop at LLVM level.
Do not suppress temporary_cstring_as_ptr in macros.
There isn't really a reason to skip the lint when part of the expression comes from an expansion.
Fixes https://github.com/rust-lang/rust/issues/94694
Move a const-prop-lint specific hack from mir interpret to const-prop-lint and make it fallible
fixes#109743
This hack didn't need to live in the mir interpreter. For const-prop-lint it is entirely correct to avoid doing any const prop if normalization fails at this stage. Most likely we couldn't const propagate anything anyway, and if revealing was needed (so opaque types were involved), we wouldn't want to be too smart and leak the hidden type anyway.
Don't collect return-position impl traits for documentation
#104889 modified the rustdoc ast collection step to use a HIR visitor, which more thoroughly walks the HIR tree. that means that we're going to encounter inner items (incl return-position impl traits and async fn opaque futures) that are not possible to document.
FIxes (but does not close due to being a beta regression) #109931
r? `@GuillaumeGomez`
rustdoc: escape GAT args in more cases
Fixes#109488.
Previously we printed the *un*escaped form of GAT arguments not only when `f.alternate()` was true but *also* when we failed to compute the URL of the trait associated with the type projection, i.e. when `href(…)` returned an `Err(_)`.
In this PR the argument printing logic is entirely separate from the link resolution code above as it should be.
Further, we now only try to compute the URL if the HTML format was requested with `!f.alternate()`. Before, we would sometimes compute the `href` only to throw it away later.
Emit feature error for parenthesized generics in associated type bounds
We don't actually do AST->HIR lowering with some `-Zunpretty` flags, so it's not correct to just delay a bug instead of emitting a feature error.
Some diagnostics regressed because of the new errors, but oh well. 🤷Fixes#109898
Fix `non_exhaustive_omitted_patterns` lint span
Fixes#109837
`DUMMY_SP` was being passed as the span in many cases where we have a span available to use. This meant that the location of the violating pattern wasn't shown, or the list of un-covered variants
r? `@Nilstrieb`
Pull some tuple variant fields out into their own struct
This is groundwork for adding more fields to those new structs, but I believe the change to be useful on its own.
r? `@Nilstrieb` but feel free to reroll for `compiler`
Previously if the expression contained generic consts and did not have a directly equivalent
type, transmuting the type in this way was forbidden, despite the two sizes being identical.
Instead, we should be able to lazily tell if the two consts are identical, and if so allow them
to be transmuted.
Never consider int and float vars for `FnPtr` candidates
This solves a regression where `0.0.cmp()` was ambiguous when a custom trait with a `cmp` method was in scope.
For integers it shouldn't be a problem in practice so I wasn't able to add a test.
I'm not sure whether there could be more issues hidden in the shadows as mentioned in the issue, but this should at least fix the problematic regression immediately.
fixes#109892
r? oli-obk
This solves a regression where `0.0.cmp()` was ambiguous when a custom
trait with a `cmp` method was in scope.
FOr integers it shouldn't be a problem in practice so I wasn't able to
add a test.
Drop array patterns using subslices
Fixes#109004
Drops contiguous subslices of an array when moving elements out with a pattern, which improves perf for large arrays
r? `@compiler-errors`
Fix subslice capture in closure
Fixes#109298 by refining captures in the same way for Subslices and Indexes. The comment `// we never capture this` seems to have been inaccurate, as changing it to an assert causes many test failures
`@rustbot` label +A-closures
Move `doc(primitive)` future incompat warning to `invalid_doc_attributes`
Fixes#88070.
It's been a while since this was turned into a "future incompatible lint" so I think we can now turn it into a hard error without problem.
r? `@jyn514`
rustdoc: Fix invalid suggestions on ambiguous intra doc links v2
Fixes https://github.com/rust-lang/rust/issues/108653.
This is another approach to fixing the same issue. This time, we keep the computed information around instead of re-computing it.
Strangely enough, the order for ambiguities seem to have been changed. Not an issue but it creates a lot of diff...
So which version do you prefer?
r? `@notriddle`
Initial support for return type notation (RTN)
See: https://smallcultfollowing.com/babysteps/blog/2023/02/13/return-type-notation-send-bounds-part-2/
1. Only supports `T: Trait<method(): Send>` style bounds, not `<T as Trait>::method(): Send`. Checking validity and injecting an implicit binder for all of the late-bound method generics is harder to do for the latter.
* I'd add this in a follow-up.
3. ~Doesn't support RTN in general type position, i.e. no `let x: <T as Trait>::method() = ...`~
* I don't think we actually want this.
5. Doesn't add syntax for "eliding" the function args -- i.e. for now, we write `method(): Send` instead of `method(..): Send`.
* May be a hazard if we try to add it in the future. I'll probably add it in a follow-up later, with a structured suggestion to change `method()` to `method(..)` once we add it.
7. ~I'm not in love with the feature gate name 😺~
* I renamed it to `return_type_notation` ✔️
Follow-up PRs will probably add support for `where T::method(): Send` bounds. I'm not sure if we ever want to support return-type-notation in arbitrary type positions. I may also make the bounds require `..` in the args list later.
r? `@ghost`
Something similar was previously removed as a part of #104602, but after this PR all table changes should also be "locally correct" after every update.
`-Cdebuginfo=1` was never line tables only and
can't be due to backwards compatibility issues.
This was clarified and an option for line tables only
was added. Additionally an option for line info
directives only was added, which is well needed for
some targets. The debug info options should now
behave the same as clang's debug info options.
Insert alignment checks for pointer dereferences when debug assertions are enabled
Closes https://github.com/rust-lang/rust/issues/54915
- [x] Jake tells me this sounds like a place to use `MirPatch`, but I can't figure out how to insert a new basic block with a new terminator in the middle of an existing basic block, using `MirPatch`. (if nobody else backs up this point I'm checking this as "not actually a good idea" because the code looks pretty clean to me after rearranging it a bit)
- [x] Using `CastKind::PointerExposeAddress` is definitely wrong, we don't want to expose. Calling a function to get the pointer address seems quite excessive. ~I'll see if I can add a new `CastKind`.~ `CastKind::Transmute` to the rescue!
- [x] Implement a more helpful panic message like slice bounds checking.
r? `@oli-obk`
Closures always implement `FnOnce` in new solver
We should process `[closure]: FnOnce(Tys...) -> Ty` obligations *before* fallback and closure analysis. We can do this by taking advantage of the fact that `FnOnce` is always implemented by closures, even before we definitely know the closure kind.
Fixescompiler-errors/next-solver-hir-issues#15
r? ``@oli-obk`` (trying to spread the reviewer load for new trait solver prs, and this one is pretty self-contained, though feel free to reassign 😸)
Don't ICE on placeholder consts in deep reject
Since we canonicalize const params into placeholder consts, we need to be able to handle them during deep reject.
r? `@lcnr` (though maybe `@oli-obk` can look at this one too, if he wants 😸)
Fixescompiler-errors/next-solver-hir-issues#10
rustdoc: run more HIR validation to mirror rustc
# Explanation
While investigating these issues: https://github.com/rust-lang/rust/issues/107093, https://github.com/rust-lang/rust/issues/106079
I thought it maybe would be useful to test running `rustdoc` on all rust files under `tests/ui` grepping for files that causes any ICEs.
And these are the files I found would cause ICEs.
```
// These are handled by this fix.
tests/ui/late-bound-lifetimes/mismatched_arg_count.rs
tests/ui/associated-consts/issue-102335-const.rs
tests/ui/const-generics/generic_const_exprs/issue-102768.rs
tests/ui/const-generics/const-arg-type-arg-misordered.rs
tests/ui/generic-associated-types/parse/trait-path-type-error-once-implemented.rs
tests/ui/typeck/issue-88643.rs
tests/ui/typeck/issue-75889.rs
tests/ui/typeck/issue-83621-placeholder-static-in-extern.rs
// These are not they will still produce a ICE after this change
tests/ui/limits/issue-56762.rs
tests/ui/union/projection-as-union-type-error-2.rs
tests/ui/union/projection-as-union-type-error.rs
```
I reduces the issues handled by this PR down to the tests added in the PR. That includes the linked issues.
But the 3 files that are not handled I will leave for a future PR.
This PR adds the `type_collecting` step from `hir_analysis::check_crate` to the rustdoc typechecks.
It had the following comment on it.
```
// this ensures that later parts of type checking can assume that items
// have valid types and not error
```
Adding the check report the same errors as rustc does for these input.
And not ICE when the lint checker walks the HIR or when in the `rustdoc::clean` pass.
This PR updates the expected errors of some existing rustdoc-ui tests (some now report less errors).
These new reported errors does mirror the errors reported by rustc.
# Performance
It does more checking so it will probably regress. We should run ``@bors` try `@rust-timer` queue` and see.
# Discussion
Maybe instead of calling a subset of the checks in `hir_analysis::check_crate` and having comments that say they should be kept in sync. We could instead call `check_crate` directly and pass in some flag. Maybe `check_toplevel_signatures_only` or something like that. That flag would have to skip most of the checks in that function tough.
apparently I missed some tests in the last commit. Rather than having
dozens of tests use the long version, use the short version in
`run-make` and the long version in `run-make-fulldeps` (which is now
only three tests)
