comment out FIXMEs to not display them on UI

Signed-off-by: onur-ozkan <[email protected]>

Author: onur-ozkan

Diff for: 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 for: src/solve/invariants.md

@@ -1,6 +1,8 @@
 # Invariants of the type system
 
+<!--
 FIXME: This file talks about invariants of the type system as a whole, not only the solver
+-->
 
 There are a lot of invariants - things the type system guarantees to be true at all times -
 which are desirable or expected from other languages and type systems. Unfortunately, quite

Diff for: 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 for: src/solve/opaque-types.md

@@ -60,8 +60,11 @@ 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.
+-->
 
 ### using alias-bounds of normalizable aliases
 
@@ -86,9 +89,11 @@ opaque before the first defining use of the opaque.
 
 These are not supported and trying to define them right now should always error.
 
+<!--
 FIXME: Because looking up opaque types in the opaque type storage can now unify regions,
 we have to eagerly check that the opaque types does not reference placeholders. We otherwise
 end up leaking placeholders.
+-->
 
 ## member constraints
 
@@ -99,8 +104,11 @@ The handling of member constraints does not change in the new solver. See the
 
 ## calling methods on opaque types
 
+<!--
 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 for: 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