From b54d3809a54a9a56c6dd04e0bfea6b8b4e41caf8 Mon Sep 17 00:00:00 2001 From: onur-ozkan <work@onurozkan.dev> Date: Wed, 1 Jan 2025 22:08:37 +0300 Subject: [PATCH 1/2] comment out FIXMEs to not display them on UI Signed-off-by: onur-ozkan <work@onurozkan.dev> --- src/method-lookup.md | 4 +++- src/solve/normalization.md | 4 ++++ src/solve/opaque-types.md | 2 ++ src/tests/directives.md | 13 ++++++++----- 4 files changed, 17 insertions(+), 6 deletions(-) diff --git a/src/method-lookup.md b/src/method-lookup.md index 8b49e8d00..c8d529a32 100644 --- a/src/method-lookup.md +++ b/src/method-lookup.md @@ -67,6 +67,7 @@ imported to use an inherent method, they are associated with the type itself (note that inherent impls can only be defined in the same crate as the type itself). +<!-- FIXME: Inherent candidates are not always derived from impls. If you have a trait object, such as a value of type `Box<ToString>`, then the trait methods (`to_string()`, in this case) are inherently associated @@ -76,7 +77,8 @@ to change: when DST's "impl Trait for Trait" is complete, trait object dispatch could be subsumed into trait matching, and the type parameter behavior should be reconsidered in light of where clauses. -TODO: Is this FIXME still accurate? +Is this still accurate? +--> **Extension candidates** are derived from imported traits. If I have the trait `ToString` imported, and I call `to_string()` as a method, diff --git a/src/solve/normalization.md b/src/solve/normalization.md index 8858258b5..d4cd13487 100644 --- a/src/solve/normalization.md +++ b/src/solve/normalization.md @@ -52,12 +52,14 @@ before assigning the resulting rigid type to an inference variable. This is used This has to be used whenever we match on the value of some type, both inside and outside of the trait solver. +<!-- FIXME: structure, maybe we should have an "alias handling" chapter instead as talking about normalization without explaining that doesn't make too much sense. FIXME: it is likely that this will subtly change again by mostly moving structural normalization into `NormalizesTo`. +--> [structural_norm]: https://github.com/rust-lang/rust/blob/2627e9f3012a97d3136b3e11bf6bd0853c38a534/compiler/rustc_trait_selection/src/solve/alias_relate.rs#L140-L175 [structural-relate]: https://github.com/rust-lang/rust/blob/a0569fa8f91b5271e92d2f73fd252de7d3d05b9c/compiler/rustc_trait_selection/src/solve/alias_relate.rs#L88-L107 @@ -72,11 +74,13 @@ possible. However, this only works for aliases referencing bound variables if th not ambiguous as we're unable to replace the alias with a corresponding inference variable without leaking universes. +<!-- FIXME: we previously had to also be careful about instantiating the new inference variable with another normalizeable alias. Due to our recent changes to generalization, this should not be the case anymore. Equating an inference variable with an alias now always uses `AliasRelate` to fully normalize the alias before instantiating the inference variable: [source][generalize-no-alias] +--> [generalize-no-alias]: https://github.com/rust-lang/rust/blob/a0569fa8f91b5271e92d2f73fd252de7d3d05b9c/compiler/rustc_infer/src/infer/relate/generalize.rs#L353-L358 diff --git a/src/solve/opaque-types.md b/src/solve/opaque-types.md index 87531705c..672aab770 100644 --- a/src/solve/opaque-types.md +++ b/src/solve/opaque-types.md @@ -60,6 +60,7 @@ Finally, we check whether the item bounds of the opaque hold for the expected ty [eq-prev]: https://github.com/rust-lang/rust/blob/384d26fc7e3bdd7687cc17b2662b091f6017ec2a/compiler/rustc_trait_selection/src/solve/normalizes_to/opaque_types.rs#L51-L59 [insert-storage]: https://github.com/rust-lang/rust/blob/384d26fc7e3bdd7687cc17b2662b091f6017ec2a/compiler/rustc_trait_selection/src/solve/normalizes_to/opaque_types.rs#L68 [item-bounds-ck]: https://github.com/rust-lang/rust/blob/384d26fc7e3bdd7687cc17b2662b091f6017ec2a/compiler/rustc_trait_selection/src/solve/normalizes_to/opaque_types.rs#L69-L74 + [^1]: FIXME: this should ideally only result in a unique candidate given that we require the args to be placeholders and regions are always inference vars [^2]: FIXME: why do we check whether the expected type is rigid for this. @@ -101,6 +102,7 @@ The handling of member constraints does not change in the new solver. See the FIXME: We need to continue to support calling methods on still unconstrained opaque types in their defining scope. It's unclear how to best do this. + ```rust use std::future::Future; use futures::FutureExt; diff --git a/src/tests/directives.md b/src/tests/directives.md index b0527da7b..69f4c8641 100644 --- a/src/tests/directives.md +++ b/src/tests/directives.md @@ -2,7 +2,9 @@ <!-- toc --> -> **FIXME(jieyouxu)** completely revise this chapter. +<!-- +FIXME(jieyouxu) completely revise this chapter. +--> Directives are special comments that tell compiletest how to build and interpret a test. They must appear before the Rust source in the test. They may also @@ -248,10 +250,11 @@ Consider writing the test as a proper incremental test instead. |-------------|--------------------------------------------------------------|------------------------------------------|---------------------------| | `doc-flags` | Flags passed to `rustdoc` when building the test or aux file | `rustdoc`, `js-doc-test`, `rustdoc-json` | Any valid `rustdoc` flags | -> **FIXME(rustdoc)**: what does `check-test-line-numbers-match` do? -> -> Asked in -> <https://rust-lang.zulipchat.com/#narrow/stream/266220-t-rustdoc/topic/What.20is.20the.20.60check-test-line-numbers-match.60.20directive.3F>. +<!-- +**FIXME(rustdoc)**: what does `check-test-line-numbers-match` do? +Asked in +<https://rust-lang.zulipchat.com/#narrow/stream/266220-t-rustdoc/topic/What.20is.20the.20.60check-test-line-numbers-match.60.20directive.3F>. +--> ### Pretty printing From db5d166d7e03509711d107db4f4009f69c1c9288 Mon Sep 17 00:00:00 2001 From: onur-ozkan <work@onurozkan.dev> Date: Thu, 2 Jan 2025 00:15:09 +0300 Subject: [PATCH 2/2] add a FIXME note on src/solve/normalization.md Signed-off-by: onur-ozkan <work@onurozkan.dev> --- src/solve/normalization.md | 3 +++ 1 file changed, 3 insertions(+) diff --git a/src/solve/normalization.md b/src/solve/normalization.md index d4cd13487..857c27292 100644 --- a/src/solve/normalization.md +++ b/src/solve/normalization.md @@ -1,5 +1,8 @@ # Normalization in the new solver +> **NOTE**: FIXME: The content of this chapter has some been changed quite +significantly since it was written. + With the new solver we've made some fairly significant changes to normalization when compared to the existing implementation.