| Age | Commit message (Collapse) | Author | Lines |
|---|
|
ignore_git → omit_git_hash
Fixes #110020
|
|
|
|
|
|
r=Mark-Simulacrum
Download beta compiler toolchain in bootstrap if it doesn't yet exist
Blocker for #107812 and #99989
See: https://github.com/rust-lang/rust/pull/107812#discussion_r1143492202
r? `@jyn514`
|
|
This is needed for when the shell scripts bypass python altogether and run the downloaded
bootstrap directly. Changes are mainly provided from @jyn514, I just fixed the review notes.
Signed-off-by: ozkanonur <work@onurozkan.dev>
|
|
Rollup of 6 pull requests
Successful merges:
- #109806 (Workaround #109797 on windows-gnu)
- #109957 (diagnostics: account for self type when looking for source of unsolved type variable)
- #109960 (Fix buffer overrun in bootstrap and (test-only) symlink_junction)
- #110013 (Label `non_exhaustive` attribute on privacy errors from non-local items)
- #110016 (Run collapsed GUI test in mobile mode as well)
- #110022 (fix: fix regression in #109203)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Fix buffer overrun in bootstrap and (test-only) symlink_junction
I don't think these can be hit in practice, due to their inputs being valid paths. It's also not security-sensitive code, but just... bad vibes.
I think this is still not really the right way to do this (in terms of path correctness), but is no worse than it was.
r? `@ChrisDenton`
|
|
extend `detect_src_and_out` test
> I was thinking about the following cases when I wrote the comment in #109055
>
> 1. Running bootstrap from the source root.
> 2. Running from a subdirectory of the source root.
> 3. Running from outside the source root.
> 4. Running on a different machine from where bootstrap was compiled (which will be important > for #107812). You can mostly replicate this by renaming the source root so it no longer exists on disk.
> 5. Running with `--build-dir`.
> 6. Running with `$RUST_BOOTSTRAP_CONFIG` set in the environment and `build-dir` set in the file.
Tested all the topics mentioned above. All worked fine. The test is now also covers if build dir is manually specified in config.
r? `@jyn514`
helps #109120 partially
|
|
Tests marked `// force-host` were using the default linker, even if a
custom linker was configured in config.toml.
This change adds a new flag, --host-linker, to compiletest, and renames
--linker to --target-linker.
|
|
Signed-off-by: ozkanonur <work@onurozkan.dev>
|
|
Validate `ignore` and `only` compiletest directive, and add human-readable ignore reasons
This PR adds strict validation for the `ignore` and `only` compiletest directives, failing if an unknown value is provided to them. Doing so uncovered 79 tests in `tests/ui` that had invalid directives, so this PR also fixes them.
Finally, this PR adds human-readable ignore reasons when tests are ignored due to `ignore` or `only` directives, like *"only executed when the architecture is aarch64"* or *"ignored when the operative system is windows"*. This was the original reason why I started working on this PR and #108659, as we need both of them for Ferrocene.
The PR is a draft because the code is extremely inefficient: it calls `rustc --print=cfg --target $target` for every rustc target (to gather the list of allowed ignore values), which on my system takes between 4s and 5s, and performs a lot of allocations of constant values. I'll fix both of them in the coming days.
r? `@ehuss`
|
|
submodule detection for proper fix on #96188
This commit resolves an internal FIXME note within the bootstrap by implementing submodule detection. This is accomplished through an iterative process over the `.gitmodules` file.
r? `@albertlarsan68`
|
|
This commit resolves an internal FIXME note within the bootstrap by implementing submodule detection.
This is accomplished through an iterative process over the `.gitmodules` file.
Signed-off-by: ozkanonur <work@onurozkan.dev>
|
|
|
|
|
|
|
|
This flag (counterintuitively) was removing the `GNU_STACK` ELF attribute, which caused the optimized `libLLVM.so` file to be flagged as having an executable stack on SELinux.
|
|
|
|
|
|
|
|
|
|
Rollup of 7 pull requests
Successful merges:
- #109526 (LIBPATH is used as dylib's path environment variable on AIX)
- #109642 (check for missing codegen backeng config)
- #109722 (Implement read_buf for RustHermit)
- #109856 (fix(middle): emit error rather than delay bug when reaching limit)
- #109868 (Improve PR job names in Github Actions preview)
- #109871 (Include invocation start times)
- #109873 (Move some UI tests into subdirectories)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Include invocation start times
For multi-invocation builders (e.g., dist-x86_64-linux) this timestamp is necessary to correlate the data in the metrics JSON with other data sources (e.g., logs, cpu-usage CSV, etc.). Such correlation may not be perfect but is sometimes helpful and awkward to do otherwise.
|
|
lenko-d:rust_codegen-backends_interacts_confusingly_with_paths, r=Mark-Simulacrum
check for missing codegen backeng config
Fixes [#109610](https://github.com/rust-lang/rust/issues/109610)
|
|
LIBPATH is used as dylib's path environment variable on AIX
See https://4js.com/online_documentation/fjs-fgl-3.00.05-manual-html/c_fgl_installation_017.html.
|
|
fix `build --stage 2 compiler/rustc` panic
Skip assembling(which causes panic due to not found `.librustc.stamp` file) process
for stage3(since it has problems with sysroot) if full-bootstrap isn't used.
Resolves #90244
|
|
|
|
For multi-invocation builders (e.g., dist-x86_64-linux) this timestamp
is necessary to correlate the data in the metrics JSON with other data
sources (e.g., logs, cpu-usage CSV, etc.). Such correlation may not be
perfect but is sometimes helpful and awkward to do otherwise.
|
|
Signed-off-by: ozkanonur <work@onurozkan.dev>
|
|
Replace any existing `build/host` symlink
This has two advantages:
1. If `build.build` changes between runs, the symlink is no longer silently wrong.
2. If the entire build directory is moved, the symlink is no longer broken because it points to the wrong absolute path.
|
|
This has two advantages:
1. If `build.build` changes between runs, the symlink is no longer
silently wrong.
2. If the entire build directory is moved, the symlink is no longer
broken because it points to the wrong absolute path.
|
|
|
|
FreeBSD 13.1 and 13.2 can build Rust with LLD just fine on powerpc.
|
|
Add OpenHarmony targets
- `aarch64-unknown-linux-ohos`
- `armv7-unknown-linux-ohos`
Compiler team MCP: https://github.com/rust-lang/compiler-team/issues/568
|
|
- `aarch64-unknown-linux-ohos`
- `armv7-unknown-linux-ohos`
|
|
socket ancillary data implementation for FreeBSD (from 13 and above).
introducing new build config as well.
|
|
Always set `RUSTC_BOOTSTRAP` with `x doc`
Fixes #100060
Note that there is still a warning - the `unused_allocation` lint does not fire in stage 0, but that's just a matter of waiting for #104363 to land in beta
|
|
|
|
|
|
introducing new build config as well.
|
|
r=Mark-Simulacrum
Rename 'src/bootstrap/native.rs' to llvm.rs
Fixed #108240
Renamed 'native.rs' to 'llvm.rs', also moved `TestHelpers` to `test.rs`. Replaced all the `native.rs` occurrences at `src/bootstrap` files to `llvm.rs`
|
|
- Link to more documentation
- Move `changelog-seen` into the "Global Settings" section
- Update incorrect comments on `llvm.link-shared` and
`rust.debug-assertions`
- Use the correct default in the commented-out example more often
- Clarify that `docs` and `compiler-docs` only control the default,
they're not a hard-off switch.
- Document `-vvv` and `local-rebuild`
- Minor improvements to doc-comments in config.toml.example
This also sets `download-rustc = false`; that was already the default,
but it will be helpful in case the default changes
(https://jyn.dev/2023/01/12/Bootstrapping-Rust-in-2023.html).
|
|
|
|
Permit the MIR inliner to inline diverging functions
This heuristic prevents inlining of `hint::unreachable_unchecked`, which in turn makes `Option/Result::unwrap_unchecked` a bad inlining candidate. I looked through the changes to `core`, `alloc`, `std`, and `hashbrown` by hand and they all seem reasonable. Let's see how this looks in perf...
---
Based on rustc-perf it looks like this regresses ctfe-stress, and the cachegrind diff indicates that this regression is in `InterpCx::statement`. I don't know how to do any deeper analysis because that function is _enormous_ in the try toolchain, which has no debuginfo in it. And a local build produces significantly different codegen for that function, even with LTO.
|
|
r=pietroalbini
Bugfix: avoid panic on invalid json output from libtest
#108659 introduces a custom test display implementation. It does so by using libtest to output json. The stdout is read and parsed; The code trims the line read and checks whether it starts with a `{` and ends with a `}`. If so, it concludes that it must be a json encoded `Message`. Unfortunately, this does not work in all cases:
- This assumes that tests running with `--nocapture` will never start and end lines with `{` and `}` characters
- Output is generated by issuing multiple `write_message` [statements](https://github.com/rust-lang/rust/blob/master/library/test/src/formatters/json.rs#L33-L60). Where only the last one issues a `\n`. This likely results in a race condition as we see multiple json outputs on the same line when running tests for the `x86_64-fortanix-unknown-sgx` target:
```
10:21:04 [0m[0m[1m[32m Running[0m tests/run-time-detect.rs (build/x86_64-unknown-linux-gnu/stage1-std/x86_64-fortanix-unknown-sgx/release/deps/run_time_detect-8c66026bd4b1871a)
10:21:04
10:21:04 running 1 tests
10:21:04 test x86_all ... ok
10:21:04 [0m[0m[1m[32m Running[0m tests/thread.rs (build/x86_64-unknown-linux-gnu/stage1-std/x86_64-fortanix-unknown-sgx/release/deps/thread-ed5456a7d80a6193)
10:21:04 thread 'main' panicked at 'failed to parse libtest json output; error: trailing characters at line 1 column 135, line: "{ \"type\": \"suite\", \"event\": \"ok\", \"passed\": 1, \"failed\": 0, \"ignored\": 0, \"measured\": 0, \"filtered_out\": 0, \"exec_time\": 0.000725911 }{ \"type\": \"suite\", \"event\": \"started\", \"test_count\": 1 }\n"', render_tests.rs:108:25
```
This PR implements a partial fix by being much more conservative of what it asserts is a valid json encoded `Message`. This prevents panics, but still does not resolve the race condition. A discussion is needed where this race condition comes from exactly and how it best can be avoided.
cc: `@jethrogb,` `@pietroalbini`
|
|
Renamed 'native.rs' to 'llvm.rs', also moved `TestHelpers` to `test.rs`.Replaced all the `native.rs` ocurrences at `src/bootstrap` files to `llvm.rs`
|
|
|
|
|
|
Rollup of 10 pull requests
Successful merges:
- #109373 (Set LLVM `LLVM_UNREACHABLE_OPTIMIZE` to `OFF`)
- #109392 (Custom MIR: Allow optional RET type annotation)
- #109394 (adapt tests/codegen/vec-shrink-panik for LLVM 17)
- #109412 (rustdoc: Add GUI test for "Auto-hide item contents for large items" setting)
- #109452 (Ignore the vendor directory for tidy tests.)
- #109457 (Remove comment about reusing rib allocations)
- #109461 (rustdoc: remove redundant `.content` prefix from span/a colors)
- #109477 (`HirId` to `LocalDefId` cleanup)
- #109489 (More general captures)
- #109494 (Do not feed param_env for RPITITs impl side)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Set LLVM `LLVM_UNREACHABLE_OPTIMIZE` to `OFF`
This option was added to LLVM in https://reviews.llvm.org/D121750?id=416339. It makes `llvm_unreachable` in builds without assertions compile to an `LLVM_BUILTIN_TRAP` instead of `LLVM_BUILTIN_UNREACHABLE` (which causes undefined behavior and is equivalent to `std::hint::unreachable_unchecked`).
Having compiler bugs triggering undefined behavior generally seems undesirable and inconsistent with Rust's goals. There is a check in `src/tools/tidy/src/style.rs` to reject code using `llvm_unreachable`. But it is used a lot within LLVM itself.
For instance, this changes a failure I get compiling `libcore` for m68k from a `SIGSEGV` to `SIGILL`, which seems better though it still doesn't provide a useful message without switching to an LLVM build with asserts.
It may be best not to do this if it noticeably degrades compiler performance, but worthwhile if it doesn't do so in any significant way. I haven't looked into what benchmarks there are for Rustc. That should be considered before merging.
|
