Replace 'NULL' with 'null'
This replaces occurrences of "NULL" with "null" in docs, comments, and compiler error/lint messages. This is for the sake of consistency, as the lowercase "null" is already the dominant form in Rust. The all-caps NULL looks like the C macro (or SQL keyword), which seems out of place in a Rust context, given that NULL does not exist in the Rust language or standard library (instead having [`ptr::null()`](https://doc.rust-lang.org/stable/std/ptr/fn.null.html)).
Do not print visibility in external traits
This PR fixes the bug that caused traits, which were re-exported, having visibility modifiers in front of methods, which is invalid.
It would be nice to add a test for this, but I don't even know if tests with multiple crates are possible.
Resolves#81274
Add ErrorKind::OutOfMemory
Ability to express `ENOMEM` as an `io::Error`.
I've used `OutOfMemory` as opposed to `NotEnoughMem` or `AllocationFailed`, because "OOM" is used in Rust already.
See also #84612
Fix debuginfo for generators
First, all fields except the discriminant (including `outer_fields`) should be put into structures inside the variant part, which gives an equivalent layout but offers us much better integration with debuggers.
Second, artificial flags in generator variants should be removed.
- Literally, variants are not artificial. We have `yield` statements, upvars and inner variables in the source code.
- Functionally, we don't want debuggers to suppress the variants. It contains the state of the generator, which is useful when debugging. So they shouldn't be marked artificial.
- Debuggers may use artificial flags to find the active variant. In this case, marking variants artificial will make debuggers not work properly.
Fixes#62572.
Fixes#79009.
And refer https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/Debuginfo.20for.20generators.
Don't download cargo twice when download-rustc is set
Previously, this caused a bug on NixOS:
1. bootstrap.py would download and patch stage0/cargo
2. bootstrap.py would download nightly cargo, but extract it to
stage0/cargo instead of ci-rustc/cargo. It would still try (and fail) to patch ci-rustc/cargo.
3. bootstrap.py would fail to build rustbuild because stage0/cargo
wasn't patched.
The "proper" fix is to extract nightly cargo to ci-rustc instead, but it
doesn't seem to be necessary at all, so this just skips downloading it
instead.
Fixes https://github.com/rust-lang/rust/issues/84702
Allow running `x.py test --stage 2 src/tools/linkchecker` with `download-rustc = true`
Previously, the LD_LIBRARY_PATH for the linkchecker looked like
`build/x86_64-unknown-linux-gnu/stage1/lib/rustlib/x86_64-unknown-linux-gnu/lib`, because the linkchecker depends on the master copy of the standard library. This is true, but doesn't include the library path for the compiler libraries:
```
/home/joshua/src/rust/rust/build/x86_64-unknown-linux-gnu/stage1-tools-bin/error_index_generator: error while loading shared libraries: libLLVM-12-rust-1.53.0-nightly.so: cannot open shared object file: No such file or directory
```
That file is in
`build/x86_64-unknown-linux-gnu/stage1/lib/libLLVM-12-rust-1.53.0-nightly.so`,
which wasn't included in the dynamic path. This adds `build/x86_64-unknown-linux-gnu/stage1/lib` to the dynamic path for the linkchecker.
Move HIR parenting information out of hir_owner
Split out of #82681.
The parent of a HIR node and its content are currently bundled together, but are rarely used together.
This PR separates both information in two distinct queries for HIR owners.
This reduces incremental invalidation for HIR items that appear within a function body when this body (and the local ids) changes.
added --no-run option for rustdoc
resolve#59053
add `--no-run` option for `rustdoc` for compiling doc test but not running them.
Intended for use with `--persist-doctests`.
Be stricter about rejecting LLVM reserved registers in asm!
LLVM will silently produce incorrect code if these registers are used as operands.
cc `@rust-lang/wg-inline-asm`
Rollup of 8 pull requests
Successful merges:
- #84601 (rustdoc: Only store locations in Cache::extern_locations and calculate the other info on-demand)
- #84704 (platform-support.md: Update for consistency with Target Tier Policy)
- #84724 (Replace llvm::sys::fs::F_None with llvm::sys::fs::OF_None)
- #84740 (Reset the docs' copy path button after 1 second)
- #84749 (Sync `rustc_codegen_cranelift`)
- #84756 (Add a ToC to the Target Tier Policy documentation)
- #84765 (Update cargo)
- #84774 (Fix misspelling)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Add a ToC to the Target Tier Policy documentation
The policy document is quite lengthy, I figured it might be good to have a quick way to jump to the specific tier policies.
Reset the docs' copy path button after 1 second
I like that this copy path button on the top next to the type/module's name changes to a check mark when you successfully clicked and copied the path but I find it really weird how the icon stays that check mark forever after the first time of clicking it. Imagine you leave that documentation tab open and come back after 2 hours and you still see that check mark in that box because you copied the path 2 hours ago. You will probably be confused and you might've forgotten what that button even does (even more so currently where this is a new feature, or when you simply don't use it often), so I really think at some point it should go back to the ⎘ icon which, at least to me, pretty clearly indicates copying, whereas the check mark (if it stays there for so long) could falsely look like a verification mark indicating "this module is verified" or something like that.
I believe after a longer period of time it's not logical to still tell the user "yes you've copied this successful".
In addition to this timeout, maybe it could be made so that you can't copy again until this cooldown of 1 second is over, but I'm not sure how useful or user-friendly that feature would be so maybe it's fine the way it is now.
Also the timeout is cleared every time you click again so if you constantly click it, it won't reset during that.
platform-support.md: Update for consistency with Target Tier Policy
Split into five sections to match the tiers: "Tier 1 with Host Tools",
"Tier 1", "Tier 2 with Host Tools", "Tier 2", and "Tier 3". Explain each
tier briefly in prose, and link to the corresponding section of the
policy for full requirements.
Drop the `host` columns from the first four, since the different
sections distinguish that. (Keep the `host` column for "Tier 3", since
it's a single list and the `host` column just indicates if host tools
are expected to work.)
Targets with host tools always have full support for std, so drop the
`std` column from those.
Move the explanations of the `std` column next to the appropriate
tables, and drop the unknown/WIP case for tier 2 targets.
Use "target" terminology consistently throughout.
Sort each table by target name.
Vastly improves coverage spans for macros
Fixes: #84561
This resolves problems where macros like `trace!(...)` would show zero coverage if tracing was disabled, and `assert_eq!(...)` would show zero coverage if the assertion did not fail, because only one coverage span was generated, for the branch.
This PR started with an idea that I could just drop branching blocks with same span as expanded macro. (See the fixed issue for more details.)
That did help, but it didn't resolve everything.
I also needed to add a span specifically for the macro name (plus `!`) to ensure the macro gets coverage even if it's internal expansion adds conditional branching blocks that are retained, and would otherwise drop the outer span. Now that outer span is _only_ the `(argument, list)`, which can safely be dropped now), because the macro name has its own span.
While testing, I also noticed the spanview debug output can cause an ICE on a function with no body. The
workaround for this is included in this PR (separate commit).
r? `@tmandry`
cc? `@wesleywiser`
