| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Rollup of 6 pull requests
Successful merges:
- #136640 (Debuginfo for function ZSTs should have alignment of 8 bits, not 1 bit)
- #136648 (Add a missing `//@ needs-symlink` to `tests/run-make/libs-through-symlinks`)
- #136651 (Label mismatched parameters at the def site for foreign functions)
- #136691 (Remove Linkage::Private and Linkage::Appending)
- #136692 (add module level doc for bootstrap:utils:exec)
- #136700 (i686-unknown-hurd-gnu: bump baseline CPU to Pentium 4)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Signed-off-by: onur-ozkan <work@onurozkan.dev>
|
|
|
|
Enable "jump to def" feature on rustc docs
This PR enables the rustdoc "jump to def" feature which is visible on the source code pages.
r? ``@oli-obk``
|
|
|
|
|
|
|
|
Signed-off-by: onur-ozkan <work@onurozkan.dev>
|
|
It doesn't make much sense at stage 1, and it was broken anyway.
|
|
|
|
|
|
|
|
|
|
Makes it explicit that these are in relation to the cc-rs crate.
|
|
bootstrap: add wrapper macros for `feature = "tracing"`-gated `tracing` macros
Follow-up to https://github.com/rust-lang/rust/pull/136091#discussion_r1930219425.
- Add wrapper macros for `error!`, `warn!`, `info!`, `debug!` and `trace!`, which `cfg(feature = "tracing")`-gates the underlying `tracing` macros. They expand to nothing if `"tracing"` feature is not enabled.
- This is not done for `span!` or `event!` because they can return span guards, and you can't really wrap that.
- This is also not possible for `tracing::instrument` attribute proc-macro unless you use another attribute proc-macro to wrap that.
It's not *great*, because `tracing::instrument` and `tracing::{span,event}` can't be wrapped this way.
Can test locally with:
```bash
$ BOOTSTRAP_TRACING=bootstrap=TRACE ./x check src/bootstrap/
```
r? ``@onur-ozkan`` (or reroll)
|
|
Add new tool for dumping feature status based on tidy
sequel to https://github.com/rust-lang/rust/pull/133514
meaning ...
supercedes https://github.com/rust-lang/rust/pull/133351
part of https://github.com/rust-lang/rust/issues/129485
r? `@jieyouxu`
cc `@estebank`
|
|
- Add wrapper macros for `error!`, `warn!`, `info!`, `debug!` and
`trace!`, which `cfg(feature = "tracing")`-gates the underlying
`tracing` macros.
- This is not done for `span!` or `event!` because they can return span
guards, and you can't really wrap that.
- This is also not possible for `tracing::instrument` attribute
proc-macro unless you use another attribute proc-macro to wrap that.
|
|
set rustc dylib on manually constructed rustc command
Fixes #133629
|
|
r=onur-ozkan
bootstrap: only build `crt{begin,end}.o` when compiling to MUSL
only MUSL needs those objects and trying to compile them to other targets, e.g. Windows or macOS, will produce C compilation errors
check the target before shelling out to the C compiler and tweak `make_run` to skip the actual C compilation when the target is not MUSL
fixes #135782
see the linked issue for additional context
|
|
r=jieyouxu
override default config profile on tarballs
This is the same logic used in the Python script https://github.com/rust-lang/rust/blob/613bdd49978298648ed05ace086bd1ecad54b44a/src/bootstrap/bootstrap.py#L1273-L1274
|
|
|
|
This is the same logic used in the Python script https://github.com/rust-lang/rust/blob/613bdd49978298648ed05ace086bd1ecad54b44a/src/bootstrap/bootstrap.py#L1273-L1274
Signed-off-by: onur-ozkan <work@onurozkan.dev>
|
|
only MUSL needs those objects and trying to compile them to other
targets, e.g. Windows or macOS, will produce C compilation errors
check the target before shelling out to the C compiler and tweak
`make_run` to skip the actual C compilation when the target is not MUSL
fixes #135782
|
|
Add target and compile the amdgpu llvm backend.
|
|
Autodiff Upstreaming - rustc_codegen_ssa, rustc_middle
This PR should not be merged until the rustc_codegen_llvm part is merged.
I will also alter it a little based on what get's shaved off from the cg_llvm PR,
and address some of the feedback I received in the other PR (including cleanups).
I am putting it already up to
1) Discuss with `@jieyouxu` if there is more work needed to add tests to this and
2) Pray that there is someone reviewing who can tell me why some of my autodiff invocations get lost.
Re 1: My test require fat-lto. I also modify the compilation pipeline. So if there are any other llvm-ir tests in the same compilation unit then I will likely break them. Luckily there are two groups who currently have the same fat-lto requirement for their GPU code which I have for my autodiff code and both groups have some plans to enable support for thin-lto. Once either that work pans out, I'll copy it over for this feature. I will also work on not changing the optimization pipeline for functions not differentiated, but that will require some thoughts and engineering, so I think it would be good to be able to run the autodiff tests isolated from the rest for now. Can you guide me here please?
For context, here are some of my tests in the samples folder: https://github.com/EnzymeAD/rustbook
Re 2: This is a pretty serious issue, since it effectively prevents publishing libraries making use of autodiff: https://github.com/EnzymeAD/rust/issues/173. For some reason my dummy code persists till the end, so the code which calls autodiff, deletes the dummy, and inserts the code to compute the derivative never gets executed. To me it looks like the rustc_autodiff attribute just get's dropped, but I don't know WHY? Any help would be super appreciated, as rustc queries look a bit voodoo to me.
Tracking:
- https://github.com/rust-lang/rust/issues/124509
r? `@jieyouxu`
|
|
|
|
|
|
Commands that end up invoking cc-rs, i.e. Cargo (through build scripts)
and cmake-rs don't need the CFLAGS from cc-rs itself, as they will just
end up as duplicates.
We do still choose to pass them in certain places, but now it's at least
clear which flags are default, and which flags are extra flags added on.
|
|
Signed-off-by: onur-ozkan <work@onurozkan.dev>
|
|
override build profile for bootstrap tests
Using the release profile for bootstrap self tests puts too much load on the CPU and makes it quite hot on `x test bootstrap` invocation for no good reason. It also makes the compilation take longer than usual (see https://github.com/rust-lang/rust/pull/136048#issuecomment-2616908484). This change turns off the release flag for bootstrap self tests.
|
|
|
|
Signed-off-by: onur-ozkan <work@onurozkan.dev>
|
|
Apply LTO config to rustdoc
Before, the LTO configuration from `config.toml` was not applied to `rustdoc`. This provides a small perf. and binary size [win](https://github.com/rust-lang/rust/pull/112049#issuecomment-2605131041) for doc builds.
Since this is configured with Cargo profiles and not rustflags, it should not break tool build cache (https://github.com/rust-lang/rust/pull/131155). I tried to run `x test miri`, `x test rustdoc` and `x test miri` and nothing was rebuilt.
r? `@onur-ozkan`
|
|
Rollup of 8 pull requests
Successful merges:
- #126604 (Uplift `clippy::double_neg` lint as `double_negations`)
- #135158 (Add `TooGeneric` variant to `LayoutError` and emit `Unknown`)
- #135635 (Move `std::io::pipe` code into its own file)
- #136072 (add two old crash tests)
- #136079 (compiler_fence: fix example)
- #136091 (Add some tracing to core bootstrap logic)
- #136097 (rustc_ast: replace some len-checks + indexing with slice patterns etc.)
- #136101 (triagebot: set myself on vacation)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Put the core unit tests in a separate coretests package
Having standard library tests in the same package as a standard library crate has bad side effects. It causes the test to have a dependency on a locally built standard library crate, while also indirectly depending on it through libtest. Currently this works out fine in the context of rust's build system as both copies are identical, but for example in cg_clif's tests I've found it basically impossible to compile both copies with the exact same compiler flags and thus the two copies would cause lang item conflicts.
This PR moves the tests of libcore to a separate package which doesn't depend on libcore, thus preventing the duplicate crates even when compiler flags don't exactly match between building the sysroot (for libtest) and building the test itself. The rest of the standard library crates do still have this issue however.
|
|
|
|
|
|
|
|
|
|
|
|
Support QNX 7.1 with `io-sock`+libstd and QNX 8.0 (`no_std` only)
Changes of this pull request:
1. Refactor code for qnx nto targets to share more code in file `nto_qnx.rs`
1. Add support for an additional network stack on nto qnx 7.1.
QNX 7.1 supports two network stacks:
1. `io-pkt`, which is default
2. `io-sock`, which is optional on 7.1 but default in QNX 8.0
As one can see in the [io-sock migration notes](https://www.qnx.com/developers/docs/7.1/index.html#com.qnx.doc.neutrino.io_sock/topic/migrate_app.html), this changes the libc API in a way similar to e.g. linux-gnu vs. linux-musl.
This change adds a new target which has a different value for `target_env`, so that e.g. libc can distinguish between both APIs.
2. Add initial support for QNX 8.0, thanks to AkhilTThomas. As it turned out, the problem with forking many processes still exists in QNX 8.0. Because if this, we are now using it for any QNX version (i.e. not check for `target_env` anymore).
|
|
And also register its check step.
Co-authored-by: Jane Losare-Lusby <jlusby42@gmail.com>
|
|
show linker output even if the linker succeeds
Show stderr and stderr by default, controlled by a new `linker_messages` lint.
fixes https://github.com/rust-lang/rust/issues/83436. fixes https://github.com/rust-lang/rust/issues/38206. cc https://rust-lang.zulipchat.com/#narrow/stream/233931-t-compiler.2Fmajor-changes/topic/uplift.20some.20-Zverbose.20calls.20and.20rename.20to.E2.80.A6.20compiler-team.23706/near/408986134
<!-- try-job: dist-x86_64-msvc -->
try-job: aarch64-apple
r? `@bjorn3`
|
|
Bootstrap: Don't move ownership of job object
I've been thinking about this since the last time I looked at bootstrap's use of job objects. We currently pass ownership of the job object to Python. I feel this is unneeded complexity.
The rationale given (in a comment) is that it helps with `ctrl-c` on `x.py`. But using `ctrl-c` when running `x.py` will also cause `bootstrap.exe` to immediately exit so I don't find that convincing.
|
|
|
|
|
|
ld is showing things like this:
```
ld: ignoring duplicate libraries: '-lm'
```
I don't have time or a macbook that lets me investigate these. Just silence them for now.
|
|
Signed-off-by: Florian Bartels <Florian.Bartels@elektrobit.com>
|
|
Signed-off-by: Florian Bartels <Florian.Bartels@elektrobit.com>
|
|
stack on aarch64
Signed-off-by: Florian Bartels <Florian.Bartels@elektrobit.com>
|
