| Age | Commit message (Collapse) | Author | Lines |
|---|
|
add m68k-unknown-none-elf target
r? `@workingjubilee`
The existing `m68k-unknown-linux-gnu` target builds `std` by default, requires atomics, and has a base cpu with an fpu. A smaller/more embedded target is desirable both to have a baseline target for the ISA, as well to make debugging easier for working on the llvm backend. Currently this target is using the `M68010` as the minimum CPU due, but as missing features are merged into the `M68k` llvm backend I am hoping to lower this further.
I have been able to build very small crates using a toolchain built against this target (together with a later version of `object`) using the configuration described in the target platform-support documentation, although getting anything of substantial complexity to build quickly hits errors in the llvm backend
|
|
Rollup of 3 pull requests
Successful merges:
- #135115 (cg_llvm: Use constants for DWARF opcodes, instead of FFI calls)
- #135118 (Clarified the documentation on `core::iter::from_fn` and `core::iter::successors`)
- #135121 (Mark `slice::reverse` unstably const)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Mark `slice::reverse` unstably const
Tracking issue #135120
This is unblocked by the stabilization of `const_swap`
|
|
Clarified the documentation on `core::iter::from_fn` and `core::iter::successors`
This PR clarifies the closure requirements for `core::iter::from_fn` and `core::iter::successors`.
`std::iter::successors` in particular is a bit difficult to understand if you are not already familiar with the signature of [`checked_mul`](https://docs.rs/num/latest/num/trait.CheckedMul.html) used in the example.
See https://github.com/rust-lang/rust/issues/135087
|
|
cg_llvm: Use constants for DWARF opcodes, instead of FFI calls
Split off from #134009 to incorporate feedback from https://github.com/rust-lang/rust/pull/134009#discussion_r1903133906.
Most of the constant values now come from gimli, which is already a compiler dependency.
I noticed that `DW_OP_LLVM_fragment` is an LLVM detail that is not defined by DWARF and could hypothetically change, so I added a static assertion on the C++ side to detect that if it ever happens.
r? workingjubilee
|
|
Add a notion of "some ABIs require certain target features"
I think I finally found the right shape for the data and checks that I recently added in https://github.com/rust-lang/rust/pull/133099, https://github.com/rust-lang/rust/pull/133417, https://github.com/rust-lang/rust/pull/134337: we have a notion of "this ABI requires the following list of target features, and it is incompatible with the following list of target features". Both `-Ctarget-feature` and `#[target_feature]` are updated to ensure we follow the rules of the ABI. This removes all the "toggleability" stuff introduced before, though we do keep the notion of a fully "forbidden" target feature -- this is needed to deal with target features that are actual ABI switches, and hence are needed to even compute the list of required target features.
We always explicitly (un)set all required and in-conflict features, just to avoid potential trouble caused by the default features of whatever the base CPU is. We do this *before* applying `-Ctarget-feature` to maintain backward compatibility; this poses a slight risk of missing some implicit feature dependencies in LLVM but has the advantage of not breaking users that deliberately toggle ABI-relevant target features. They get a warning but the feature does get toggled the way they requested.
For now, our logic supports x86, ARM, and RISC-V (just like the previous logic did). Unsurprisingly, RISC-V is the nicest. ;)
As a side-effect this also (unstably) allows *enabling* `x87` when that is harmless. I used the opportunity to mark SSE2 as required on x86-64, to better match the actual logic in LLVM and because all x86-64 chips do have SSE2. This infrastructure also prepares us for requiring SSE on x86-32 when we want to use that for our ABI (and for float semantics sanity), see https://github.com/rust-lang/rust/issues/133611, but no such change is happening in this PR.
r? `@workingjubilee`
|
|
rustc-dev-guide subtree update
This PR performs the first update of rustc-dev-guide code from its repository.
r? `@BoxyUwU`
|
|
|
|
Co-authored-by: Jubilee <workingjubilee@gmail.com>
|
|
Subtree sync for rustc_codegen_cranelift
Aside from a Cranelift update, nothing major this time.
r? `@ghost`
`@rustbot` label +A-codegen +A-cranelift +T-compiler
|
|
(#2192)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
sync_cg_clif-2025-01-05
|
|
|
|
|
|
|
|
|
|
|
|
|
|
The `gimli` crate is already a dependency of `thorin-dwp`, which is already a
dependency of `rustc_codegen_ssa`.
|
|
|
|
Weekly `cargo update`
Automation to keep dependencies in `Cargo.lock` current.
The following is the output from `cargo update`:
```txt
compiler & tools dependencies:
Locking 4 packages to latest compatible versions
Updating bstr v1.11.1 -> v1.11.3
Updating spdx v0.10.7 -> v0.10.8
Updating syn v2.0.93 -> v2.0.94
Updating tempfile v3.14.0 -> v3.15.0
note: pass `--verbose` to see 35 unchanged dependencies behind latest
library dependencies:
Locking 0 packages to latest compatible versions
note: pass `--verbose` to see 3 unchanged dependencies behind latest
rustbook dependencies:
Locking 5 packages to latest compatible versions
Updating bstr v1.11.1 -> v1.11.3
Updating cc v1.2.6 -> v1.2.7
Updating syn v2.0.93 -> v2.0.94
Updating tempfile v3.14.0 -> v3.15.0
Updating winnow v0.6.20 -> v0.6.22
```
|
|
|
|
Target: Add mips mti baremetal support
Do the same thing as gcc, which use the vendor `mti` to mark the toolchain as MIPS32r2 default.
We support both big endian and little endian flavor:
mips-mti-none-elf
mipsel-mti-none-elf
|
|
Co-authored-by: Oli Scherer <github35764891676564198441@oli-obk.de>
|
|
|
|
|
|
Rollup of 4 pull requests
Successful merges:
- #134925 (deny usage of special FileCheck prefixes as revision names)
- #134996 (Add UWP (msvc) target support page)
- #135104 (do not in-place-iterate over flatmap/flatten)
- #135110 (library: fix adler{ -> 2}.debug)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
library: fix adler{ -> 2}.debug
Fixes
```
Checking stage0 library artifacts {alloc, core, panic_abort, panic_unwind, proc_macro, std, sysroot, test, unwind} (x86_64-unknown-linux-gnu)
warning: profile package spec `adler` in profile `release` did not match any packages
Did you mean `adler2`?
```
r? `@bjorn3`
|
|
r=Mark-Simulacrum
do not in-place-iterate over flatmap/flatten
The implementation is unsound when a partially consumed iterator has some elements buffered in the front/back parts and cloning the Iterator removes the capacity from the backing vec::IntoIter.
This is a fix for #135103 that removes the specialization trait impls without removing some supporting parts. I've kept it small so it can be easily backported. I'll either remove the remaining parts or think of a way to recover the optimization in a separate PR.
|
|
Add UWP (msvc) target support page
- Added Platform Support page for `x86_64-uwp-windows-msvc`, `i686-uwp-windows-msvc`, `thumbv7a-uwp-windows-msvc` and `aarch64-uwp-windows-msvc`
- Adding myself as a maintainer
- Removing the ticks for `thumbv7a-pc-windows-msvc` and `thumbv7a-uwp-windows-msvc` as they do not currently build due to #134565 and https://github.com/rust-lang/backtrace-rs/pull/685
- Fixed a few minor issues to let most of the UWP targets compile
- Happy new year to all!
r? jieyouxu
|
|
r=jieyouxu
deny usage of special FileCheck prefixes as revision names
Adds a check that ensures special FileCheck prefixes are not used as revision names.
Fix #130982
|
|
Fixes
```
Checking stage0 library artifacts {alloc, core, panic_abort, panic_unwind, proc_macro, std, sysroot, test, unwind} (x86_64-unknown-linux-gnu)
warning: profile package spec `adler` in profile `release` did not match any packages
Did you mean `adler2`?
```
|
|
compiler & tools dependencies:
Locking 4 packages to latest compatible versions
Updating bstr v1.11.1 -> v1.11.3
Updating spdx v0.10.7 -> v0.10.8
Updating syn v2.0.93 -> v2.0.94
Updating tempfile v3.14.0 -> v3.15.0
note: pass `--verbose` to see 35 unchanged dependencies behind latest
library dependencies:
Locking 0 packages to latest compatible versions
note: pass `--verbose` to see 3 unchanged dependencies behind latest
rustbook dependencies:
Locking 5 packages to latest compatible versions
Updating bstr v1.11.1 -> v1.11.3
Updating cc v1.2.6 -> v1.2.7
Updating syn v2.0.93 -> v2.0.94
Updating tempfile v3.14.0 -> v3.15.0
Updating winnow v0.6.20 -> v0.6.22
|
|
[Debuginfo] Force enum `DISCR_*` to `static const u64` to allow for inspection via LLDB
see [here](https://rust-lang.zulipchat.com/#narrow/channel/317568-t-compiler.2Fwg-debugging/topic/Revamping.20Debuginfo/near/486614878) for more info.
This change mainly helps `*-msvc` debugged with LLDB. Currently, LLDB cannot inspect `static` struct fields, so the intended visualization for enums is only borderline functional, and niche enums with ranges of discriminant cannot be determined at all .
LLDB *can* inspect `static const` values (though for whatever reason, non-enum/non-u64 consts don't work).
This change adds the `LLVMRustDIBuilderCreateQualifiedType` to the rust FFI layer to wrap the discr type with a `const` modifier, as well as forcing all generated integer enum `DISCR_*` values to be u64's. Those values will only ever be used by debugger visualizers anyway, so it shouldn't be a huge deal, but I left a fixme comment for it just in case.. The `tag` also still properly reflects the discriminant type, so no information is lost.
|
|
Rollup of 6 pull requests
Successful merges:
- #135046 (turn rustc_box into an intrinsic)
- #135061 (crashes: add latest batch of tests)
- #135070 (std: sync to dep versions of backtrace)
- #135088 (Force code generation in assembly generation smoke-tests)
- #135091 (Bump backtrace to 0.3.75)
- #135094 (bootstrap: If dir_is_empty fails, show the non-existent directory path)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Co-authored-by: Jubilee <workingjubilee@gmail.com>
|
|
|
|
The implementation is unsound when a partially consumed iterator has
some elements buffered in the front/back parts and cloning the Iterator
removes the capacity from the backing vec::IntoIter.
|
|
bootstrap: correctly handle doc paths within submodules
Fixes #135041 by passing the correct submodule path when requiring submodules. This PR changes `is_path_in_submodule` to `submodule_path_of`. `submodule_path_of` returns the path of the containing submodule when given a path nested inside a submodule we handle, and `None` otherwise.
I tested this manually locally by unregistering the `src/tools/cargo` submodule, then running `./x doc src/tools/cargo/src/doc`. This command fails on master with
```
thread 'main' panicked at src/bootstrap/src/utils/helpers.rs:441:5:
std::fs::read_dir(dir) failed with No such file or directory (os error 2)
```
since the require submodule fails as `src/tools/cargo/src/doc` is not a known submodule. Now we use the submodule path if such a nested-in-submodule-path is passed, and thus running this command with cargo submodule unregistered still succeeds:
```
Rustbook (x86_64-unknown-linux-gnu) - cargo
Doc path: /home/joe/repos/rust/build/x86_64-unknown-linux-gnu/doc/cargo/index.html
Build completed successfully in 0:00:11
```
r? `@onur-ozkan`
|
|
r=jieyouxu
bootstrap: If dir_is_empty fails, show the non-existent directory path
This should help when trying to debug issues.
|
|
Bump backtrace to 0.3.75
I prefer when we can ship the same version of backtrace on crates.io, and this will be the next published version.
Compare: https://github.com/rust-lang/backtrace-rs/compare/4d7906b...0.3.75
Mostly internal-to-backtrace changes, plus a tiny code size win.
r? `@ghost`
|
|
Force code generation in assembly generation smoke-tests
In llvm/llvm-project@7b23f413d1f76532825e470b523e971818d453ca , `.text` started being suppressed from LLVM assembly in cases where it wasn't strictly necessary. Currently, the sample functions in these two tests are frequently decided to be IR-only functions, resulting in no code generation, so LLVM drops the `.text` directive.
Adding `#[no_mangle]` forces these tests back to their original intent - assembly code is generated, and so a `.text` directive is generated as well.
`@rustbot` label: +llvm-main
r? `@workingjubilee`
I'll attach a buildbot link once it finishes consuming this PR
|
