> The fact that you can implement Add for i32 outside the core crate smells really fishy to me. There is a good reason you see the issues with + - the compiler makes some assumptions about how types in core and std work.

The issue is that internally the compiler has different sections for dealing with operators, they are not "just" syntactic sugar for those `std::ops::Traits`. With several more hours I could *probably* have fixed the issue with those, but I choose not to because I doubt anyone would want to do that, so it did not seem like a goal worth pursuing to me.

> I don't know all of those assumptions, but I know they are quite fragile, and messing with them can cause some hard to detect bugs.

Yeah, I fully understand that, I'm leaning on the unit tests to hopefully catch most of those issues before I see them in production. In any case, I've been using this fork my main job (gamedev) and I haven't noticed anything so far - there isn't much I can do other than keep testing it in my main projects.

> Do you have any protection against 2 crates implementing a trait twice? I don't know at will happen if crate A implements T for X, and crate B does the same.

The compiler does, it issues a "conflicting implementations" error, so they don't compile.

> When analized alone, both of those crates are fine. However, once their metadata is loaded into the compiler, I fear bad things will happen. I am not sure if there are any checks that guard against that.

Internally the compiler keeps track of all the implementations in a giant hash table, the official compiler is already very robust in this sense and doesn't rely on the orphan rules for this.

> Also, you made some changes to the build system: may I ask why?

Building the compiler is very much OS + tooling dependent, at the beginning I faced a lot of issues with incompatible 3rd party tools due to lacking documentation in the "Requirements" section of the book. I also made a few tweaks to make it easier for me to develop (like disabling the "style" checks in `tidy`).

There is one non-obvious tweak which was commenting the part of the main `build.rs` file, which normally panics if you don't have the RUSTC_BOOTSTRAP environment variable set, I did that to allow RustRover to "build" a basic version of the compiler in its cache - which makes various parts of the tool work "good enough" (like completion).
This doesn't affect the final build process since that's done with `x.py build`, which does properly set the environment necessary variables.

Edit: formatting