Use hir::ItemLocalId as keys in TypeckTables.
This PR makes `TypeckTables` use `ItemLocalId` instead of `NodeId` as key. This is needed for incremental compilation -- for stable hashing and for being able to persist and reload these tables. The PR implements the most important part of https://github.com/rust-lang/rust/issues/40303.
Some notes on the implementation:
* The PR adds the `HirId` to HIR nodes where needed (`Expr`, `Local`, `Block`, `Pat`) which obviates the need to store a `NodeId -> HirId` mapping in crate metadata. Thanks @eddyb for the suggestion! In the future the `HirId` should completely replace the `NodeId` in HIR nodes.
* Before something is read or stored in one of the various `TypeckTables` subtables, the entry's key is validated via the new `TypeckTables::validate_hir_id()` method. This makes sure that we are not mixing information from different items in a single table.
That last part could be made a bit nicer by either (a) new-typing the table-key and making `validate_hir_id()` the only way to convert a `HirId` to the new-typed key, or (b) just encapsulate sub-table access a little better. This PR, however, contents itself with not making things significantly worse.
Also, there's quite a bit of switching around between `NodeId`, `HirId`, and `DefIndex`. These conversions are cheap except for `HirId -> NodeId`, so if the valued reviewer finds such an instance in a performance critical place, please let me know.
Ideally we convert more and more code from `NodeId` to `HirId` in the future so that there are no more `NodeId`s after HIR lowering anywhere. Then the amount of switching should be minimal again.
r? @eddyb, maybe?
ast_validation: forbid "nonstandard" literal patterns
Since #42886, macros can create "nonstandard" PatKind::Lit patterns,
that contain path expressions instead of the usual literal expr. These
can cause trouble, including ICEs.
We *could* map these nonstandard patterns to PatKind::Path patterns
during HIR lowering, but that would be much effort for little gain, and
I think is too risky for beta. So let's just forbid them during AST
validation.
Fixes#43250.
beta-nominating because regression.
r? @eddyb
Cleanup for "Support compiling rustc without LLVM (try 2)"
This includes a small patch to allow running tests without llvm. Also check if you are not trying to compile a dylib.
cc #42932
r? @alexcrichton
Fix for issue #39827
*Cause of the issue*
While preparing for `trans_intrinsic_call()` invoke arguments are processed with `trans_argument()` method which excludes zero-sized types from argument list (to be more correct - all arguments for which `ArgKind` is `Ignore` are filtered out). As result `volatile_store()` intrinsic gets one argument instead of expected address and value.
*How it is fixed*
Modification of the `trans_argument()` method may cause side effects, therefore change was implemented in `volatile_store()` intrinsic building code itself. Now it checks function signature and if it was specialised with zero-sized type, then emits `C_nil()` instead of accessing non-existing second argument.
Optimize allocation paths in RawVec
Since the `Alloc` trait was introduced (https://github.com/rust-lang/rust/pull/42313) and it was integrated everywhere (https://github.com/rust-lang/rust/pull/42727) there's been some slowdowns and regressions that have slipped through. The intention of this PR is to try to tackle at least some of them, but they've been very difficult to quantify up to this point so it probably doesn't solve everything.
This PR primarily targets the `RawVec` type, specifically the `double` function. The codegen for this function is now much closer to what it was before #42313 landed as many runtime checks have been elided.
Since #42886, macros can create "nonstandard" PatKind::Lit patterns,
that contain path expressions instead of the usual literal expr. These
can cause trouble, including ICEs.
We *could* map these nonstandard patterns to PatKind::Path patterns
during HIR lowering, but that would be much effort for little gain, and
I think is too risky for beta. So let's just forbid them during AST
validation.
Fixes#43250.
Fix include! in doc tests
By making the path relative to the current file.
Fixes#43153
[breaking-change] - if you use `include!` inside a doc test, you'll need to change the path to be relative to the current file rather than relative to the working directory.
Fix unused_result lint triggering when a function returns `()`, `!` or an empty enum
Also added a test to prevent this from happening again.
Fixes#43806
Rustbuild cleanups/fixes and improvements
Each commit is a standalone change, and can/should be reviewed separately.
This adds two new functionalities:
- `--target` and `--host` can be passed without changing config.toml, and we'll respect the users' wishes, instead of requiring that all possible targets are passed.
- Note that this means that `./x.py clean` won't be quite as wide-spread as before, since it limits itself to the configured hosts, not all hosts. This could be considered a feature as well.
- `ignore-git` field in `config.toml` which tells Rustbuild to not attempt to load git hashes from `.git`.
This is a precursor to eventual further simplification of the configuration system, but I want to get this merged first so that later work can be made in individual PRs.
r? @alexcrichton
Expose all OS-specific modules in libstd doc.
1. Uses the special `--cfg dox` configuration passed by rustbuild when running `rustdoc`. Changes the `#[cfg(platform)]` into `#[cfg(any(dox, platform))]` so that platform-specific API are visible to rustdoc.
2. Since platform-specific implementations often won't compile correctly on other platforms, `rustdoc` is changed to apply `everybody_loops` to the functions during documentation and doc-test harness.
3. Since platform-specific code are documented on all platforms now, it could confuse users who found a useful API but is non-portable. Also, their examples will be doc-tested, so must be excluded when not testing on the native platform. An undocumented attribute `#[doc(cfg(...))]` is introduced to serve the above purposed.
Fixes#24658 (Does _not_ fully implement #1998).
This fixes the bug we previously had where we'd build a libtest tool
after building a libstd tool and clear out the libstd tool. Since we
clear out all tools for a given stage on invocations of CleanTools after
lib{std, test, rustc} change, we need to make sure that all tools built
with that stage will be built after the clearing is done.
The fix contained here technically isn't perfect; there is still an edge
case of compiling a libstd tool, then compiling libtest, which will
clear out the libstd tool and it won't ever get rebuilt within that
session of rustbuild. This is where the caching system used today shows
it's problems -- in effect, all tools depend on a global counter of the
stage being cleared out. We can implement such a counter in a future
patch to ensure that tools are rebuilt as needed, but it is deemed
unlikely that it will be required in practice, since most if not all
tools are built after the relevant stage's std/test/rustc are built,
though this is only an opinion and hasn't been verified.
Some users of the build system change the git sha on every build due to
utilizing git to push changes to a remote server. This allows them to
simply configure that away instead of depending on custom patches to
rustbuild.
This introduces a slight change in behavior, where we unilaterally
respect the --host and --target parameters passed for all sanity
checking and runtime configuration.
Improve std::ops docs
Fixes#29365. (This fixes all but one point from @steveklabnik's list, but that point was referring to examples of implementing range traits, but there are no range traits in std::ops.)
The main changes are quite a bit of copyediting, adding more "real" examples for some of the traits, incorporating some guidance from the API docs, more linking (cross-docs and to the book & reference), cleaning up examples, moving things around, and so on. Refer to the commit messages for more details.
Note: I decided to link to the second edition of the book since I think it's more appropriate now for the sections I linked, if this is not okay, please say so!
The `RawVec` type has a number of invariants that it upholds throughout its
execution, and as a result many of the runtime checks imposed by using `Layout`
in a "raw" fashion aren't actually necessary. For example a `RawVec`'s capacity
is intended to always match the layout which "fits" the allocation, so we don't
need any runtime checks when retrieving the current `Layout` for a vector.
Consequently, this adds a safe `current_layout` function which internally uses
the `from_size_align_unchecked` function.
Along the same lines we know that most construction of new layouts will not
overflow. All allocations in `RawVec` are kept below `isize::MAX` and valid
alignments are also kept low enough that we're guaranteed that `Layout` for a
doubled vector will never overflow and will always succeed construction.
Consequently a few locations can use `from_size_align_unchecked` in addition
when constructing the *new* layout to allocate (or reallocate), which allows for
eliding some more runtime checks.
Overall this should significant improve performance for an important function,
`RawVec::double`. This commit removes four runtime jumps before `__rust_realloc`
is called, as well as one after it's called.
* fixed link typos and copy-paster errors
* rewrote Fn* explanations
* `RHS = Self` -> `RHS` is `Self` (added that to all applicable places as
well)
* fixed up some links
* s/MutDeref/DerefMut
* removed remaining superfluous `fn main()`s
* fixed some minor phrasings and factual errors and inaccuracies
std::ops docs: Fix phrasing and factual errors/inaccuracies
Update GitHub pull request documentation link
It looks like the GitHub documentation has been re-organized so that the "fork and pull" model isn't explained alongside the PR process in one convenient link any more.
