| Age | Commit message (Collapse) | Author | Lines |
|
Co-authored-by: lcnr <rust@lcnr.de>
Co-authored-by: Ralf Jung <post@ralfj.de>
Co-authored-by: waffle <waffle.lapkin@gmail.com>
|
|
|
|
Rustc pull update
|
|
|
|
|
|
Pull recent changes from https://github.com/rust-lang/rust via Josh.
Upstream ref: efd420c770bb179537c01063e98cb6990c439654
Filtered ref: d11dbbb02905535a89393e80c24274bee81fa928
This merge was created using https://github.com/rust-lang/josh-sync.
|
|
This updates the rust-version file to efd420c770bb179537c01063e98cb6990c439654.
|
|
Now all our Josh subtrees should be using josh-sync.
|
|
|
|
|
|
rustc-dev-guide subtree update
Subtree update of `rustc-dev-guide` to https://github.com/rust-lang/rustc-dev-guide/commit/cca233729f03d0c59456cd3e866f92681faf4c54.
Created using https://github.com/rust-lang/josh-sync.
r? ```@ghost```
|
|
gpu offload host code generation
r? ghost
This will generate most of the host side code to use llvm's offload feature.
The first PR will only handle automatic mem-transfers to and from the device.
So if a user calls a kernel, we will copy inputs back and forth, but we won't do the actual kernel launch.
Before merging, we will use LLVM's Info infrastructure to verify that the memcopies match what openmp offloa generates in C++. `LIBOMPTARGET_INFO=-1 ./my_rust_binary` should print that a memcpy to and later from the device is happening.
A follow-up PR will generate the actual device-side kernel which will then do computations on the GPU.
A third PR will implement manual host2device and device2host functionality, but the goal is to minimize cases where a user has to overwrite our default handling due to performance issues.
I'm trying to get a full MVP out first, so this just recognizes GPU functions based on magic names. The final frontend will obviously move this over to use proper macros, like I'm already doing it for the autodiff work.
This work will also be compatible with std::autodiff, so one can differentiate GPU kernels.
Tracking:
- https://github.com/rust-lang/rust/issues/131513
|
|
|
|
add rdg push git config entry for git protocol pushers (again)
|
|
|
|
|
|
Rustc pull update
|
|
|
|
Pull recent changes from https://github.com/rust-lang/rust via Josh.
Upstream ref: 460259d14de0274b97b8801e08cb2fe5f16fdac5
Filtered ref: 599ee17eb87c83f97eb37fd9fe264da65d4c9461
This merge was created using https://github.com/rust-lang/josh-sync.
|
|
This updates the rust-version file to 460259d14de0274b97b8801e08cb2fe5f16fdac5.
|
|
|
|
|
|
tests: Require `run-fail` ui tests to have an exit code (`SIGABRT` not ok)
And introduce two new directives for ui tests:
* `run-crash`
* `run-fail-or-crash`
Normally a `run-fail` ui test like tests that panic shall not be terminated by a signal like `SIGABRT`. So begin having that as a hard requirement.
Some of our current tests do terminate by a signal/crash however. Introduce and use `run-crash` for those tests. Note that Windows crashes are not handled by signals but by certain high bits set on the process exit code. Example exit code for crash on Windows: `0xc000001d` (`STATUS_ILLEGAL_INSTRUCTION`). Because of this, we define "crash" on all platforms as "not exit with success and not exit with a regular failure code in the range 1..=127".
Some tests behave differently on different targets:
* Targets without unwind support will abort (crash) instead of exit with failure code 101 after panicking. As a special case, allow crashes for `run-fail` tests for such targets.
* Different sanitizer implementations handle detected memory problems differently. Some abort (crash) the process while others exit with failure code 1. Introduce and use `run-fail-or-crash` for such tests.
This adds further (cc https://github.com/rust-lang/rust/pull/142304, https://github.com/rust-lang/rust/pull/142886) protection against the regression in https://github.com/rust-lang/rust/issues/123733 since that bug also manifested as `SIGABRT` in `tests/ui/panics/panic-main.rs` (shown as `Aborted (core dumped)` in the logs attached to that issue, and I have also been able to reproduce this locally).
### TODO
- [x] **Q:** what about on Windows?
**A:** we'll treat any exit code outside of 1 - 127 as "crashed", and we'll do the same on unix.
- [x] test all permutations of actual vs expected
**Done:** See https://github.com/rust-lang/rust/pull/143002#issuecomment-3007502894.
- [x] Handle targets without unwind support
- [x] Add `run-fail-or-crash` for some sanitizer tests
- [x] remote-test-client. See https://github.com/rust-lang/rust/pull/143448
### Zulip discussion
See https://rust-lang.zulipchat.com/#narrow/channel/122651-general/topic/compiletest.3A.20terminate.20by.20signal.20vs.20exit.20with.20error/with/525611235
try-job: aarch64-apple
try-job: x86_64-msvc-1
try-job: x86_64-gnu
try-job: dist-i586-gnu-i586-i686-musl
try-job: test-various
try-job: armhf-gnu
|
|
And introduce two new directives for ui tests:
* `run-crash`
* `run-fail-or-crash`
Normally a `run-fail` ui test like tests that panic shall not be
terminated by a signal like `SIGABRT`. So begin having that as a hard
requirement.
Some of our current tests do terminate by a signal/crash however.
Introduce and use `run-crash` for those tests. Note that Windows crashes
are not handled by signals but by certain high bits set on the process
exit code. Example exit code for crash on Windows: `0xc000001d`.
Because of this, we define "crash" on all platforms as "not exit with
success and not exit with a regular failure code in the range 1..=127".
Some tests behave differently on different targets:
* Targets without unwind support will abort (crash) instead of exit with
failure code 101 after panicking. As a special case, allow crashes for
`run-fail` tests for such targets.
* Different sanitizer implementations handle detected memory problems
differently. Some abort (crash) the process while others exit with
failure code 1. Introduce and use `run-fail-or-crash` for such tests.
|
|
docs: update link to RISC-V and Xtensa installation guide
Replace outdated link https://docs.esp-rs.org/book/installation/riscv-and-xtensa.html with the official Espressif documentation at https://docs.espressif.com/projects/rust/book/installation/index.html
|
|
|
|
|
|
Correct which exploit mitigations are enabled by default
This was brought up by ``@Noratrieb`` in [#project-exploit-mitigations > Incorrect table in the rustc book](https://rust-lang.zulipchat.com/#narrow/channel/343119-project-exploit-mitigations/topic/Incorrect.20table.20in.20the.20rustc.20book/with/523684203). Thanks! :)
[Rendered](https://github.com/rust-lang/rust/blob/132a47e72316b60e99c3e5fefb9c3a06641138e4/src/doc/rustc/src/exploit-mitigations.md)
r? ``@rcvalle``
|
|
|
|
rustc-dev-guide subtree update
r? ghost
|
|
|
|
|
|
Pull recent changes from https://github.com/rust-lang/rust via Josh.
Upstream ref: fd2eb391d032181459773f3498c17b198513e0d0
Filtered ref: 1ea8d5f9c22f0930a0caa27637ef9232fead3c2b
This merge was created using https://github.com/rust-lang/josh-sync.
|
|
This updates the rust-version file to fd2eb391d032181459773f3498c17b198513e0d0.
|
|
|
|
Co-authored-by: Boxy <rust@boxyuwu.dev>
|
|
|
|
|
|
Update books
## rust-lang/book
3 commits in ef1ce8f87a8b18feb1b6a9cf9a4939a79bde6795..b2d1a0821e12a676b496d61891b8e3d374a8e832
2025-07-08 17:24:41 UTC to 2025-07-02 21:30:57 UTC
- Chapter 16 from tech review (rust-lang/book#4438)
- WIP ch 17 edits after tech review (rust-lang/book#4319)
- Chapter 15 from tech review (rust-lang/book#4433)
## rust-embedded/book
1 commits in 41f688a598a5022b749e23d37f3c524f6a0b28e1..fe88fbb68391a465680dd91109f0a151a1676f3e
2025-07-08 18:54:25 UTC to 2025-07-08 18:54:25 UTC
- Clarify usage of #[interrupt] attribute and recommend device crate re… (rust-embedded/book#386)
## rust-lang/nomicon
3 commits in 8b61acfaea822e9ac926190bc8f15791c33336e8..3ff384320598bbe8d8cfe5cb8f18f78a3a3e6b15
2025-07-05 07:34:22 UTC to 2025-07-05 07:13:51 UTC
- Add build script part to FFI chapter for more clear and smooth learn … (rust-lang/nomicon#440)
- Cleanups for tree example of splitting borrows (rust-lang/nomicon#443)
- Handle drop zst (rust-lang/nomicon#425)
## rust-lang/reference
17 commits in e9fc99f107840813916f62e16b3f6d9556e1f2d8..1f45bd41fa6c17b7c048ed6bfe5f168c4311206a
2025-07-11 23:15:51 UTC to 2025-07-01 16:49:33 UTC
- mention an important use for the naked attribute (rust-lang/reference#1929)
- Array expression repeat operands can be const blocks. (rust-lang/reference#1928)
- Document (tuple) struct pattern namespace behavior (rust-lang/reference#1925)
- Replace set of en dashes with set of em dashes (rust-lang/reference#1926)
- Update `should_panic` to use the attribute template (rust-lang/reference#1882)
- const-eval.const-expr.borrows: mention indirect places (rust-lang/reference#1865)
- associated-items.md: remove redundant word (rust-lang/reference#1874)
- introduction.md: replace hard-to-read example (rust-lang/reference#1873)
- typo (rust-lang/reference#1924)
- Update `ignore` to use the attribute template (rust-lang/reference#1881)
- Update `test` to use the attribute template (rust-lang/reference#1880)
- Update `cfg_attr` to use the attribute template (rust-lang/reference#1879)
- Update `cfg` to use the attribute template (rust-lang/reference#1878)
- allow constants to refer to mutable/external memory, but reject such constants as patterns (rust-lang/reference#1859)
- Remove outdated comment about non-copy unions (rust-lang/reference#1872)
- Add a template for documenting attributes (rust-lang/reference#1877)
- Switch enum grammar to use "variant" (rust-lang/reference#1876)
## rust-lang/rust-by-example
1 commits in 288b4e4948add43f387cad35adc7b1c54ca6fe12..e386be5f44af711854207c11fdd61bb576270b04
2025-07-04 23:17:15 UTC to 2025-07-04 23:17:15 UTC
- Update Chinese translations (rust-lang/rust-by-example#1943)
|
|
|
|
tweak some git clone commands
|
|
|
|
|
|
|
|
|
|
Add target maintainer information for aarch64-unknown-linux-musl
Mentioning ``@famfo`` so that they can review the documentation. We're both very invested in this target; I originally promoted it to tier 2 with host tools in rust-lang/rust#76420 back in 2020.
|
|
|
|
Signed-off-by: Jens Reidel <adrian@travitia.xyz>
|
|
Add profiler to bootstrap command
This PR adds command profiling to the bootstrap command. It tracks the total execution time and records cache hits for each command. It also provides the ability to export execution result to a JSON file. Integrating this with Chrome tracing could further enhance observability.
r? `@Kobzol`
|
|
under bootstrap profiling section
|