Projection types in user annotations may contain inference variables.
This makes the normalization depend on the unification with the actual
type and thus requires a separate TypeOp to track the obligations.
Otherwise simply calling `TypeChecker::normalize` would ICE with
"unexpected ambiguity"
We delay projection normalization to further stages in order to
register user type annotations before normalization in HIR typeck.
There are two consumers of astconv: ItemCtxt and FnCtxt.
The former already expects unnormalized types from astconv, see its
AstConv trait impl.
The latter needs `RawTy` for a cleaner interface.
Unfortunately astconv still needs the normalization machinery in
order to resolve enum variants that have projections in the self type,
e.g. `<<T as Trait>::Assoc>::StructVariant {}`.
This is why `AstConv::normalize_ty_2` is necessary.
Add help diag. for `const = Enum` missing braces around `Enum`
Previously it was not clear why this errored or if it was even supported, as there was no diagnostic that suggested wrapping it in braces.
Thus, add a simple diagnostic that suggests wrapping enum variants in braces.
Fixes#105927
rustdoc: remove no-op CSS `.rustdoc.source .sidebar { width: 0 }`
This CSS was added in dc2c972334, before 6a5f8b1aef when the sidebars were merged.
Now that they are merged, the source sidebar is being pushed off-screen anyway, so giving it zero width doesn't do much.
Handle non-existent upstream master branches in `x fmt`
People who do have a remote for `rust-lang/rust` but don't have the master branch checked out there used to get this error when running `x fmt`:
> fatal: ambiguous argument 'rust/master': unknown revision or path not in the working tree.
> Use '--' to separate paths from revisions, like this:
> 'git <command> [<revision>...] -- [<file>...]'
> rust/master
Which is not exactly helpful.
Now, we fall back to `origin/master` (hoping that at least that remote exists) for that case. If there is still some error, we just fall back to `x fmt .` and print a warning.
r? `@jyn514`
Add default and latest stable edition to --edition in rustc (attempt 2)
Fixes#106041
No longer leaks string like my first attempt PR, #106094 - uses LazyLock to construct a `&'static str`
It will now output the default edition and latest stable edition in the help message for the `--edition` flag.
Going to request the same reviewer as the first attempt for continuity - r? `@Nilstrieb`
Fix rustdoc source code rendering for `#[path = "../path/to/mod.rs"]` links
Fixes#103517
While generating the location for modules source HTML to be saved at, a `..` path component appeared to be translated to `/up/`.
Additionally, while generating the navigation sidebar, `..` path components were ignored. This means that (as in the issue above), a *real* directory structure of:
```
sys/
unix/
mod.rs <-- contains #![path = "../unix/mod.rs]
cmath.rs
```
was rendered as:
```
sys/
unix/
mod.rs
unix/
cmath.rs <-- links to sys/unix/unix/cmath.rs.html, 404
```
While the *files* were stored as
```
sys/
unix/
mod.rs.html
up/
unix/
cmath.rs.html
```
Improve include macro documentation
As outlined in #106118, the `include!` macro is a SEO problem when it comes to the Rust documentation. Beginners may see it as a replacement to `include` syntax in other languages. I feel like this documentation should quite explicitly link to the modules' documentation.
The primary goal of this PR is to address that issue by adding a warning to the documentation. While I was here, I also added some other parts. This included a `Uses` section and some (intra doc) links to other relevant topics.
I hope this can help beginners to Rust more quickly understand some multi-file project intricacies.
# References
- Syntax for the warning: 58accc6da3/tracing/src/lib.rs (L55)
refactor: clean up `errors.rs` and `error_codes_check.rs`
`errors.rs` is basically unused now, `error_codes_check.rs` is useful but not well commented, etc. It also doesn't check certain things which are certainly not correct. For example, `E0505` has a UI test in `src/test/ui/error-codes/` but that test actually outputs `E0504`?! Other issues like these exist. I've implemented these with "warnings" which are a bit rough around the edges but should be removed eventually.
r? `@GuillaumeGomez` (again not sure if you want to review but its relevant to you)
This CSS was added in dc2c972334,
before 6a5f8b1aef when the sidebars
were merged.
Now that they are merged, the source sidebar is being pushed
off-screen anyway, so giving it zero width doesn't do much.
