-
Notifications
You must be signed in to change notification settings - Fork 12.9k
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
Skip reborrows in AbstractConstBuilder #90529
Conversation
Unless we never want these adjustments in general as they may just be noise @bors try @rust-timer queue |
Awaiting bors try build completion. @rustbot label: +S-waiting-on-perf |
⌛ Trying commit a50e129ce9c87622402210074bcec26b357c4834 with merge 74bfdbfa136949bcfff0227d9f9e3a76f6ff2402... |
@@ -93,6 +94,20 @@ impl<'tcx> Cx<'tcx> { | |||
) -> Expr<'tcx> { | |||
let Expr { temp_lifetime, .. } = expr; | |||
|
|||
// FIXME(generic_const_exprs): Once expressions of kind `AdressOf`, | |||
// `Borrow` and `Deref` are supported, we can allow adjustments here | |||
if let ExprKind::Literal { |
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.
I would assume that &*expr
is used for borrowck reasons 🤔
While I am not too familiar with this code, this impl seems worrying to me because:
- in places where we only have one of the adjustments, i.e. either
&CONST
or*CONST
this is incorrect. Don't know if something like that is possible rn but it seems likely to me. - this probably causes some subtle changes to borrowck, though considering that const params can currently only be
&'static Ty
this is probably not too much of a problem 🤷
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.
I completely misunderstood the issue, I initially thought that we would reject these borrows and derefs anyway, and this seems to be the case inside anonymous const blocks when generic_const_exprs
is used, where we always throw an error when we encounter them during the construction of the AbstractConst
(here), but treating all Borrow and Deref exprs as nops on all constants in general is not what we want obviously.
If we do want to allow reborrows, then the current implementation of raising the bug during the construction of the AbstractConst
seems to actually be what we want here right? And we should just keep this until we allow Borrows and Derefs inside anonymous constant.
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.
Maybe we should try to give a better error message during typeck here that makes the implicit adjustments explicit to the user?
☀️ Try build successful - checks-actions |
Queued 74bfdbfa136949bcfff0227d9f9e3a76f6ff2402 with parent e8423e6, future comparison URL. |
Finished benchmarking commit (74bfdbfa136949bcfff0227d9f9e3a76f6ff2402): comparison url. Summary: This benchmark run did not return any relevant changes. If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf. Benchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. While you can manually mark this PR as fit for rollup, we strongly recommend not doing so since this PR led to changes in compiler perf. @bors rollup=never |
This comment has been minimized.
This comment has been minimized.
I changed this PR, we now don't apply reborrow adjustments whenever we're inside an anonconst context. I think this is what we want to do here, since we would reject these adjustments during the const evaluatable checks anyway. I'm not sure whether solving this issue warrants the changes I had to make, introducing an expression check context solely for this might be considered unnecessary. Also I'm not sure whether this could result in performance problems, we would definitely need another timer run here. Also I would clean this up a little, just wanted to see whether the idea in general would be viable. |
99b8f85
to
c6fc1ac
Compare
This is still true. For a temporary fix this PR adds way too much logic that needs to go away again. Can't we "just" make the abstract-const builder handle this case instead? |
@oli-obk Implemented skipping re-borrows during AbstractConst construction. This does work (I tried this without the previous commit, but decided to leave that commit here just in case). We would unify reborrowed expressions with expressions that don't contain a reborrow now, I think this should be fine, but maybe I'm missing something. Could this be a problem, @lcnr? |
937c2fd
to
a07a33d
Compare
This comment has been minimized.
This comment has been minimized.
I am fine with skipping reborrows, maybe add a |
a07a33d
to
f09b549
Compare
This comment has been minimized.
This comment has been minimized.
f09b549
to
1777f43
Compare
@bors r=lcnr |
📌 Commit 1777f43 has been approved by |
@bors rollup |
…askrgr Rollup of 4 pull requests Successful merges: - rust-lang#90529 (Skip reborrows in AbstractConstBuilder) - rust-lang#91437 (Pretty print empty blocks as {}) - rust-lang#91450 (Don't suggest types whose inner type is erroneous) - rust-lang#91535 (Stabilize `-Z emit-future-incompat` as `--json future-incompat`) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup
Fixes #90455
Temporary fix to prevent confusing diagnostics that refer to implicit borrows and derefs until we allow borrows and derefs on constant expressions.
r? @oli-obk