Update around half of the January 2021 date references (#1155)
This commit is contained in:
parent
6f1c331e94
commit
1d25c44b9a
|
|
@ -2,15 +2,6 @@
|
|||
|
||||
<!-- toc -->
|
||||
|
||||
> **NOTE**: The structure of the repository is going through a lot of
|
||||
> transitions. In particular, we want to get to a point eventually where the
|
||||
> top-level directory has separate directories for the compiler, build-system,
|
||||
> std libs, etc, rather than one huge `src/` directory.
|
||||
>
|
||||
> As of <!-- date: 2021-01 --> January 2021, the standard libraries have been
|
||||
> moved to `library/` and the crates that make up the `rustc` compiler itself
|
||||
> have been moved to `compiler/`.
|
||||
|
||||
Now that we have [seen what the compiler does](./overview.md), let's take a
|
||||
look at the structure of the contents of the rust-lang/rust repo.
|
||||
|
||||
|
|
|
|||
|
|
@ -17,7 +17,7 @@ First, we have the lint declarations themselves: this is where the name and defa
|
|||
other metadata come from. These are normally defined by way of the [`declare_lint!`] macro, which
|
||||
boils down to a static with type `&rustc_session::lint::Lint`.
|
||||
|
||||
As of <!-- date: 2021-01 --> January 2021, we lint against direct declarations
|
||||
As of <!-- date: 2021-07 --> July 2021, we lint against direct declarations
|
||||
without the use of the macro today (although this may change in the future, as
|
||||
the macro is somewhat unwieldy to add new fields to, like all macros by
|
||||
example).
|
||||
|
|
|
|||
|
|
@ -157,7 +157,7 @@ no changes added to commit (use "git add" and/or "git commit -a")
|
|||
These changes are not changes to files: they are changes to submodules (more on
|
||||
this [later](#git-submodules)). To get rid of those, run `git submodule update`
|
||||
(or run any `x.py` command, which will automatically update the submodules).
|
||||
Note that there is (as of <!-- date: 2021-01 --> January 2021) a bug if you use
|
||||
Note that there is (as of <!-- date: 2021-07 --> July 2021) a [bug][#77620] if you use
|
||||
worktrees, submodules, and x.py in a commit hook. If you run into an error
|
||||
like:
|
||||
|
||||
|
|
@ -167,9 +167,10 @@ error: failed to read `/home/joshua/rustc-worktree/src/tools/miri/cargo-miri/Car
|
|||
Caused by:
|
||||
No such file or directory (os error 2)
|
||||
```
|
||||
it's not anything you did wrong. There is a workaround at [#77620].
|
||||
it's not anything you did wrong. There is a workaround in [the issue][#77620-workaround].
|
||||
|
||||
[#77620]: https://github.com/rust-lang/rust/issues/77620#issuecomment-705228229
|
||||
[#77620]: https://github.com/rust-lang/rust/issues/77620
|
||||
[#77620-workaround]: https://github.com/rust-lang/rust/issues/77620#issuecomment-705228229
|
||||
|
||||
## Rebasing and Conflicts
|
||||
|
||||
|
|
|
|||
|
|
@ -197,10 +197,9 @@ Miri's virtual memory. This is in contrast to `Scalar::Raw`, which is just some
|
|||
concrete integer.
|
||||
|
||||
However, a variable of pointer or reference *type*, such as `*const T` or `&T`,
|
||||
does not have to have a pointer *value*: it could be obtaining by casting or
|
||||
transmuting an integer to a pointer (as of <!-- date: 2021-01 --> January 2021
|
||||
that is hard to do in const eval, but eventually `transmute` will be stable as a
|
||||
`const fn`). And similarly, when casting or transmuting a reference to some
|
||||
does not have to have a pointer *value*: it could be obtained by casting or
|
||||
transmuting an integer to a pointer.
|
||||
And similarly, when casting or transmuting a reference to some
|
||||
actual allocation to an integer, we end up with a pointer *value*
|
||||
(`Scalar::Ptr`) at integer *type* (`usize`). This is a problem because we
|
||||
cannot meaningfully perform integer operations such as division on pointer
|
||||
|
|
|
|||
|
|
@ -3,7 +3,7 @@
|
|||
Most of the compiler is not parallel. This represents an opportunity for
|
||||
improving compiler performance.
|
||||
|
||||
As of <!-- date: 2021-01 --> January 2021, work on explicitly parallelizing the
|
||||
As of <!-- date: 2021-07 --> July 2021, work on explicitly parallelizing the
|
||||
compiler has stalled. There is a lot of design and correctness work that needs
|
||||
to be done.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
# Queries: demand-driven compilation
|
||||
|
||||
As described in [the high-level overview of the compiler][hl], the Rust compiler
|
||||
is still (as of <!-- date: 2021-01 --> January 2021) transitioning from a
|
||||
is still (as of <!-- date: 2021-07 --> July 2021) transitioning from a
|
||||
traditional "pass-based" setup to a "demand-driven" system. **The Compiler Query
|
||||
System is the key to our new demand-driven organization.** The idea is pretty
|
||||
simple. You have various queries that compute things about the input – for
|
||||
|
|
|
|||
|
|
@ -9,7 +9,7 @@ want to watch [Salsa In More
|
|||
Depth](https://www.youtube.com/watch?v=i_IhACacPRY), also by Niko
|
||||
Matsakis.
|
||||
|
||||
> As of <!-- date: 2021-01 --> January 2021, although Salsa is inspired by
|
||||
> As of <!-- date: 2021-07 --> July 2021, although Salsa is inspired by
|
||||
> (among other things) rustc's query system, it is not used directly in rustc.
|
||||
> It _is_ used in chalk and extensively in `rust-analyzer`, but there are no
|
||||
> medium or long-term concrete plans to integrate it into the compiler.
|
||||
|
|
|
|||
Loading…
Reference in New Issue