Add documentation for unstable_feature_bound
There is more detail and explanation in https://hackmd.io/``````@tiif/Byd3mq7Ige``````
Original PR that implemented this: rust-lang/rust#140399
r? ``````@BoxyUwU`````` to nominate for types team discussion
The project build for compiler-rt is deprecated.
The runtimes build will use the just-built clang. As such, we
also need to pass --gcc-toolchain to the runtimes build, so that
it can find the GCC installation.
Consolidate staging for `rustc_private` tools
This PR continues bootstrap refactoring, this time by consolidating staging for `Mode::ToolRustc` tools. This refactoring was in the critical path of refactoring `test`/`dist`/`clippy`/`doc` steps, and getting rid of the rmeta/rlib sysroot copy, because tools are pervasive and they are being used for a lot of things in bootstrap.
The main idea is to explicitly model the fact that a stage N `Mode::ToolRustc` tool always works with two different compilers:
- Stage N-1 rustc (`build_compiler`) builds stage N rustc (`target_compiler`)
- Rlib artifacts from stage N rustc are copied to the sysroot of stage N-1 rustc
- Stage N-1 rustc builds the (stage N) tool itself, the tool links to the rlib artifacts of the stage N rustc
Before, the code often used `compiler`, which meant sometimes the build compiler, sometimes the target compiler, and sometimes neither (looking at you, `download-rustc`). This is especially annoying when you get to a situation where you have an install step that invokes a dist step that invokes a tool build step, where *some* compiler is being propagated through, without it being clear what does that compiler represent. This refactoring hopefully makes that clearer and more explicit. It also gets rid of a few `builder.ensure(Rustc(...))` calls within bootstrap, which is always nice.
`Rustdoc` needs to be handled a bit specially, because it acts as a compiler itself, I documented that in the changes.
It wasn't practical to do these refactorings in multiple PRs, so I did it all in one PR. The meat of the change is 9ee6d1c1ed112c3dcfb5684b33772b136df0dca3.
I tested manually that `x build rustdoc` and `x build miri` still works even with `download-rustc`, although I cannot promise any extra support for `download-rustc`, IMO we will just have to reimplement it from scratch in a different way.
As usually, I did some drive-by refactorings to bootstrap, trying to document and clarify things, add more step metadata and tests.
Since these changes broke Cargo, which was incorrectly using `Mode::ToolRustc`, I also changed cargo to `ToolTarget` in this PR.
Best reviewed commit-by-commit (note that I renamed `link_compiler` to `target_compiler`, in accordance to the rest of bootstrap, in the last commit).
r? `@jieyouxu`
try-job: x86_64-gnu-aux
try-job: x86_64-msvc-ext1
Add a tidy check to prevent adding UI tests directly under `tests/ui/`
This PR implements https://github.com/rust-lang/compiler-team/issues/902.
Only the last commit (adding the new check) is functional; earlier commits are just small drive-by changes to make the other ui/ui-fulldeps checks more logically contained.
r? ```@Kobzol``` (or compiler)
Implement debugging output of the bootstrap Step graph into a DOT file
There are already a bunch of ways how we can debug bootstrap, so why not add one more =D (ideally I'd like to consolidate these approaches somewhat, ```@Shourya742``` is looking into that, but I think that this specific debugging tool is orthogonal to the rest of them, and is quite useful).
This PR adds the option to render the bootstrap step graph into the DOT format, in order to understand what steps were executed, along with their fields (`Debug` output).
Here you can see an example of the generated DOT files for the `BOOTSTRAP_TRACING=1 ./x build compiler --stage 2 --dry-run` command on x64 Linux. One is with cached deps (what this PR does), the other one without.
[bootstrap-dot.zip](https://github.com/user-attachments/files/21548679/bootstrap-dot.zip)
Visual example:
<img width="1899" height="445" alt="image" src="https://github.com/user-attachments/assets/ae40e6d2-0ea8-48bb-b77e-6b21700b95ee" />
r? ```@jieyouxu```
rustdoc template font links only emit `crossorigin` when needed
The `crossorigin` attribute may cause issues when the href is not actually cross-origin. Specifically, the tag causes the browser to send a preflight OPTIONS request to the server even if it is same-origin. Some temperamental servers may reject all CORS preflight requests even if they're actually same-origin, which causes a CORS error and prevents the fonts from loading, even later on.
This commit fixes that problem by not emitting `crossorigin` if the url appears to be relative to the same origin.
Distinguish prepending and replacing self ty in predicates
There are two kinds of functions called `with_self_ty`:
1. Prepends the `Self` type onto an `ExistentialPredicate` which lacks it in its internal representation.
2. Replaces the `Self` type of an existing predicate, either for diagnostics purposes or in the new trait solver when normalizing that self type.
This PR distinguishes these two because I often want to only grep for one of them. Namely, let's call it `with_replaced_self_ty` when all we're doing is replacing the self type.
Remove unnecessary `rust_` prefixes
part of https://github.com/rust-lang/rust/issues/116005
Honestly, not sure if this can affect linking somehow, also I didn't touched things like `__rust_panic_cleanup` and `__rust_start_panic` which very likely will break something, so just small cleanup here
also didn't changed `rust_panic_without_hook` because it was renamed here https://github.com/rust-lang/rust/pull/144852
r? libs
For "stage 1" ui-fulldeps, use the stage 1 compiler to query target info
Testing ui-fulldeps in "stage 1" actually uses the stage 0 compiler, so that test programs can link against stage 1 rustc crates.
Unfortunately, using the stage 0 compiler causes problems when compiletest tries to obtain target information from the compiler, but the output format has changed since the last bootstrap beta bump.
We can work around this by also providing compiletest with a stage 1 compiler, and having it use that compiler to query for target information.
---
This fixes the stage 1 ui-fulldeps failure seen at https://github.com/rust-lang/rust/pull/144443#issuecomment-3146992771.
Stylize `*-lynxos178-*` target maintainer handle to make it easier to copy/paste
Apparently I forgot to submit this branch I had lying around.
Noticed while reviewing Tier 3 target platform support pages. In the same style as rust-lang/rust#139028.
Do not give function allocations alignment in consteval and Miri.
We do not yet have a (clear and T-lang approved) design for how `#[align(N)]` on functions should affect function pointers' addresses on various platforms, so for now do not give function pointers alignment in consteval and Miri.
----
Old summary:
Not a full solution to <https://github.com/rust-lang/rust/issues/144661>, but fixes the immediate issue by making function allocations all have alignment 1 in consteval, ignoring `#[rustc_align(N)]`, so the compiler doesn't know if any offset other than 0 is non-null.
A more "principlied" solution would probably be to make function pointers to `#[instruction_set(arm::t32)]` functions be at offset 1 of an align-`max(2, align attribute)` allocation instead of at offset 0 of their allocation during consteval, and on wasm to either disallow `#[align(N)]` where N > 1, or to pad the function table such that the function pointer of a `#[align(N)]` function is a multiple of `N` at runtime.
Add lint against dangling pointers from local variables
## `dangling_pointers_from_locals`
*warn-by-default*
The `dangling_pointers_from_locals` lint detects getting a pointer to data of a local that will be dropped at the end of the function.
### Example
```rust
fn f() -> *const u8 {
let x = 0;
&x // returns a dangling ptr to `x`
}
```
```text
warning: a dangling pointer will be produced because the local variable `x` will be dropped
--> $DIR/dangling-pointers-from-locals.rs:10:5
|
LL | fn simple() -> *const u8 {
| --------- return type of the function is `*const u8`
LL | let x = 0;
| - `x` is defined inside the function and will be drop at the end of the function
LL | &x
| ^^
|
= note: pointers do not have a lifetime; after returning, the `u8` will be deallocated at the end of the function because nothing is referencing it as far as the type system is concerned
= note: `#[warn(dangling_pointers_from_locals)]` on by default
```
### Explanation
Returning a pointer from a local value will not prolong its lifetime, which means that the value can be dropped and the allocation freed while the pointer still exists, making the pointer dangling.
If you need stronger guarantees, consider using references instead, as they are statically verified by the borrow-checker to never dangle.
------
This is related to GitHub codeql [CWE-825](https://github.com/github/codeql/blob/main/rust/ql/src/queries/security/CWE-825/AccessAfterLifetimeBad.rs) which shows examples of such simple miss-use.
It should be noted that C compilers warns against such patterns even without `-Wall`, https://godbolt.org/z/P7z98arrc.
------
`@rustbot` labels +I-lang-nominated +T-lang
cc `@traviscross`
r? compiler
compiletest: Preliminary cleanup of `ProcRes` printing/unwinding
While experimenting with changes to how compiletest handles output capture, error reporting, and unwinding, I repeatedly ran in to difficulties with this core code for reporting test failures caused by a subprocess.
There should be no change in compiletest output.
r? jieyouxu
Remove the omit_gdb_pretty_printer_section attribute
Disabling loading of pretty printers in the debugger itself is more reliable. Before this commit the .gdb_debug_scripts section couldn't be included in dylibs or rlibs as otherwise there is no way to disable the section anymore without recompiling the entire standard library.
Testing ui-fulldeps in "stage 1" actually uses the stage 0 compiler, so that
test programs can link against stage 1 rustc crates.
Unfortunately, using the stage 0 compiler causes problems when compiletest
tries to obtain target information from the compiler, but the output format has
changed since the last bootstrap beta bump.
We can work around this by also providing compiletest with a stage 1 compiler,
and having it use that compiler to query for target information.
This reduces the amount of "hidden" printing in error-reporting code, which
will be helpful when overhauling compiletest's error handling and output
capture.
Properly pass path to staged `rustc` to `compiletest` self-tests
Otherwise, this can do weird things like use a global rustc, or try to use stage 0 rustc. This must be properly configured, because `compiletest` is intended to only support one compiler target spec JSON format (of the in-tree compiler).
Historically, this was probably done so before `bootstrap` was really its own thing, and `compiletest` had to be runnable as a much more "self-standing" tool.
Follow-up to rust-lang/rust#144675, as I didn't realize this until Zalathar pointed it out in [#t-infra/bootstrap > Building vs testing `compiletest` @ 💬](https://rust-lang.zulipchat.com/#narrow/channel/326414-t-infra.2Fbootstrap/topic/Building.20vs.20testing.20.60compiletest.60/near/532040838).
r? ````@Kobzol````
[rustdoc] Display unsafe attrs with edition 2024 `unsafe()` wrappers.
Use Rust 2024 edition representation for unsafe attributes in rustdoc HTML:
- `#[no_mangle]` -> `#[unsafe(no_mangle)]`
- `#[export_name = "foo"]` -> `#[unsafe(export_name = "foo")]`
- `#[link_section = ".text"]` -> `#[unsafe(link_section = ".text")]`
The 2024 edition representation is used regardless of the crate's own edition. This ensures that Rustaceans don't have to learn the rules of an outdated edition (e.g. that `unsafe()` wasn't always necessary) in order to understand a crate's documentation.
After some looking through the `T-rustdoc` issues, I was not able to find an existing issue for this. Apologies if I missed it.
r? ``````@aDotInTheVoid``````
get rid of some false negatives in rustdoc::broken_intra_doc_links
rustdoc will not try to do intra-doc linking if the "path" of a link looks too much like a "real url".
however, only inline links (`[text](url)`) can actually contain a url, other types of links (reference links, shortcut links) contain a *reference* which is later resolved to an actual url.
the "path" in this case cannot be a url, and therefore it should not be skipped due to looking like a url.
fixes https://github.com/rust-lang/rust/issues/54191
to minimize the number of false positives that will be introduced, the following heuristic is used:
If there's no backticks, be lenient revert to old behavior.
This is to prevent churn by linting on stuff that isn't meant to be a link.
only shortcut links have simple enough syntax that they
are likely to be written accidentlly, collapsed and reference links
need 4 metachars, and reference links will not usually use
backticks in the reference name.
therefore, only shortcut syntax gets the lenient behavior.
here's a truth table for how link kinds that cannot be urls are handled:
| | is shortcut link | not shortcut link |
|--------------|--------------------|-------------------|
| has backtick | never ignore | never ignore |
| no backtick | ignore if url-like | never ignore |
