| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
|
|
Also, these are normal Rust things (crates/packages), so remove the word *normal*.
|
|
Update compiler-src.md
|
|
|
|
|
|
Introduce a normalization chapter
|
|
|
|
Refactor the dependency structure from a nested unordered list to a single-level ordered list.
IMO, this is clearer, but happy to close this PR without merging, if the change is not desired.
|
|
This adds documentation on how to stabilize the edition in the compiler.
|
|
This updates to the latest version of mdbook which has had a variety
of fixes of new features since the last update.
Changelog: https://github.com/rust-lang/mdBook/blob/master/CHANGELOG.md#mdbook-0448
|
|
Based on lessons learned from 2024. There's probably still more details
to say here since it was a ton of work. These are the major points that
I remember.
|
|
It was observed that some people were missing the `edition20xx` rustdoc
attribute. Although this probably won't solve that problem, I'd still
like to highlight it as something to be aware of.
|
|
I found "Rustc dev guide subtree update awkward"
|
|
|
|
|
|
|
|
|
|
|
|
|
|
fix(docs): add newlines between prefix/suffix chapters
|
|
toolchain version does not need to be specified
|
|
|
|
Signed-off-by: xizheyin <xizheyin@smail.nju.edu.cn>
|
|
|
|
`Results` contains and `Analysis` and an `EntryStates`. The unfortunate
thing about this is that the analysis needs to be mutable everywhere
(`&mut Analysis`) which forces the `Results` to be mutable everywhere,
even though `EntryStates` is immutable everywhere.
To fix this, this commit renames `Results` as `AnalysisAndResults`,
renames `EntryStates` as `Results`, and separates the analysis and
results as much as possible. (`AnalysisAndResults` doesn't get much use,
it's mostly there to facilitate method chaining of
`iterate_to_fixpoint`.)
`Results` is immutable everywhere, which:
- is a bit clearer on how the data is used,
- avoids an unnecessary clone of entry states in
`locals_live_across_suspend_points`, and
- moves the results outside the `RefCell` in Formatter.
The commit also reformulates `ResultsHandle` as the generic `CowMut`,
which is simpler than `ResultsHandle` because it doesn't need the
`'tcx` lifetime and the trait bounds. It also which sits nicely
alongside the new use of `Cow` in `ResultsCursor`.
|
|
`-Cforce-unwind-tables=yes`
|
|
|
|
|
|
|
|
rustc-dev-guide subtree update
r? ``@ghost``
|
|
|
|
|
|
|
|
support config extensions
_Copied from the `rustc-dev-guide` addition:_
>When working on different tasks, you might need to switch between different bootstrap >configurations.
>Sometimes you may want to keep an old configuration for future use. But saving raw config >values in
>random files and manually copying and pasting them can quickly become messy, especially if >you have a
>long history of different configurations.
>
>To simplify managing multiple configurations, you can create config extensions.
>
>For example, you can create a simple config file named `cross.toml`:
>
>```toml
>[build]
>build = "x86_64-unknown-linux-gnu"
>host = ["i686-unknown-linux-gnu"]
>target = ["i686-unknown-linux-gnu"]
>
>
>[llvm]
>download-ci-llvm = false
>
>[target.x86_64-unknown-linux-gnu]
>llvm-config = "/path/to/llvm-19/bin/llvm-config"
>```
>
>Then, include this in your `bootstrap.toml`:
>
>```toml
>include = ["cross.toml"]
>```
>
>You can also include extensions within extensions recursively.
>
>**Note:** In the `include` field, the overriding logic follows a right-to-left order. For example,
in `include = ["a.toml", "b.toml"]`, extension `b.toml` overrides `a.toml`. Also, parent extensions
always overrides the inner ones.
try-job: x86_64-mingw-2
|
|
|
|
|
|
|
|
|
|
|
|
- Rust backcompat removes the need to specify the version here
- Using these commands can result in a needless toolchain getting
downloaded, like in the case where user only has Nightly installed
|
|
|
|
add newlines between prefix/suffix chapters in SUMMARY.md
to ensure correct extraction by mdbook-i18n-helpers.
|
|
|
|
|
|
|
|
|
|
Rename `LifetimeName` as `LifetimeKind`.
It's a much better name, more consistent with how we name such things.
Also rename `Lifetime::res` as `Lifetime::kind` to match. I suspect this field used to have the type `LifetimeRes` and then the type was changed but the field name remained the same.
r? ``@BoxyUwU``
|
|
Remind to update dev branch while behind too many commits
|
|
Signed-off-by: xizheyin <xizheyin@smail.nju.edu.cn>
|
