-
Notifications
You must be signed in to change notification settings - Fork 13k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Create a new TyKind::DynStar variant #107908
Conversation
Some changes occurred to the CTFE / Miri engine cc @rust-lang/miri Some changes occurred to the core trait solver cc @rust-lang/initiative-trait-system-refactor Some changes occurred to MIR optimizations cc @rust-lang/wg-mir-opt |
This is almost certainly going to break in CI... I fixed what I could test locally, but unfortunately I haven't found a great way to test things like cranelift on my own machine. |
Some changes occurred in compiler/rustc_codegen_cranelift cc @bjorn3 |
9267996
to
329895b
Compare
Some changes occurred in src/tools/clippy cc @rust-lang/clippy |
fdb72fc
to
1febfb2
Compare
Not finished yet, just enough to make it compile.
1febfb2
to
d16faac
Compare
The job Click to see the possible cause of the failure (guessed by this bot)
|
This will also cause tons of conflicts with #107728 :/ |
Needs fixing, and probably should wait until Ralf's PR is landed. @rustbot author |
☔ The latest upstream changes (presumably #108052) made this pull request unmergeable. Please resolve the merge conflicts. |
@@ -1,19 +1,23 @@ | |||
//! Checks for usage of `&Vec[_]` and `&String`. | |||
|
|||
use clippy_utils::diagnostics::{span_lint, span_lint_and_sugg, span_lint_and_then, span_lint_hir_and_then}; | |||
use clippy_utils::diagnostics::{ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This file looks as if it was just re-formatted. Please don't commit formatting changes to Clippy in the Rust repo.
Gonna close this since it's pretty stale, and probably just needs to be done from scratch. |
Where is that tracked? |
@RalfJung, what do you mean? |
Do we have an issue tracking this cleanup and the reasons for it? Chances are it will just get forgotten otherwise.
I guess the tracking issue for dynstar would be the right place?
|
Ah, no, we currently do not have one. I'll leave a comment on the dyn* tracking issue. |
Previously
dyn*
was implemented by adding aDynKind
field on thety::Dynamic
variant. This works well for cases where we can treat the two types mostly the same, which is most of the front parts of the compiler (type checker, etc.). It doesn't work so well for the backends like Miri, since the representation of adyn
anddyn*
are quite different. This PR splits thedyn*
type into its own variant to make it more explicit how it is handled.r? compiler-errors