| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
|
|
this mirrors the behavior of rustdoc-js-std tests.
previously this required COMPILETEST_FORCE_STAGE0.
|
|
adjust the way we build miri-script in RA, to fix proc-macros
|
|
|
|
|
|
this also makes the rust.docs-minification option work
as advertised in config.toml
nothing fancy this time, this is intended to be perma-unstable.
it's only really here for the benefit of rustdoc devs.
mitegates https://github.com/rust-lang/rust/issues/135345
|
|
|
|
Rename `BitSet` to `DenseBitSet`
r? `@Mark-Simulacrum` as you requested this in https://github.com/rust-lang/rust/pull/134438#discussion_r1890659739 after such a confusion.
This PR renames `BitSet` to `DenseBitSet` to make it less obvious as the go-to solution for bitmap needs, as well as make its representation (and positives/negatives) clearer. It also expands the comments there to hopefully make it clearer when it's not a good fit, with some alternative bitsets types.
(This migrates the subtrees cg_gcc and clippy to use the new name in separate commits, for easier review by their respective owners, but they can obvs be squashed)
|
|
add `-Zmin-function-alignment`
tracking issue: https://github.com/rust-lang/rust/issues/82232
This PR adds the `-Zmin-function-alignment=<align>` flag, that specifies a minimum alignment for all* functions.
### Motivation
This feature is requested by RfL [here](https://github.com/rust-lang/rust/issues/128830):
> i.e. the equivalents of `-fmin-function-alignment` ([GCC](https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html#index-fmin-function-alignment_003dn), Clang does not support it) / `-falign-functions` ([GCC](https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html#index-falign-functions), [Clang](https://clang.llvm.org/docs/ClangCommandLineReference.html#cmdoption-clang1-falign-functions)).
>
> For the Linux kernel, the behavior wanted is that of GCC's `-fmin-function-alignment` and Clang's `-falign-functions`, i.e. align all functions, including cold functions.
>
> There is [`feature(fn_align)`](https://github.com/rust-lang/rust/issues/82232), but we need to do it globally.
### Behavior
The `fn_align` feature does not have an RFC. It was decided at the time that it would not be necessary, but maybe we feel differently about that now? In any case, here are the semantics of this flag:
- `-Zmin-function-alignment=<align>` specifies the minimum alignment of all* functions
- the `#[repr(align(<align>))]` attribute can be used to override the function alignment on a per-function basis: when `-Zmin-function-alignment` is specified, the attribute's value is only used when it is higher than the value passed to `-Zmin-function-alignment`.
- the target may decide to use a higher value (e.g. on x86_64 the minimum that LLVM generates is 16)
- The highest supported alignment in rust is `2^29`: I checked a bunch of targets, and they all emit the `.p2align 29` directive for targets that align functions at all (some GPU stuff does not have function alignment).
*: Only with `build-std` would the minimum alignment also be applied to `std` functions.
---
cc `@ojeda`
r? `@workingjubilee` you were active on the tracking issue
|
|
|
|
Move shared helper scripts used by Docker builds under docker/scripts.
|
|
|
|
|
|
bump `rustc-perf` submodule
This updates the `rustc-perf` submodule to pull in the recent changes, in particular the error handling in https://github.com/rust-lang/rustc-perf/pull/2021 fixing the error we saw in a recent run.
I think I did this correctly, submodules are so annoying.
r? kobzol
(opening as draft to do a perf run and check that nothing has changed indeed)
|
|
|
|
|
|
|
|
|
|
r=jieyouxu
support target specific `optimized-compiler-builtins`
Makes it possible to control `optimized-compiler-builtins` for per target.
This was raised in the [zulip discussion](https://rust-lang.zulipchat.com/#narrow/channel/326414-t-infra.2Fbootstrap/topic/Building.20and.20packaging.20Rust.20with.20x86_64-unknown-uefi.20support/near/492765883) yesterday.
|
|
r=onur-ozkan
re-add a warning for old master branch, but with much simpler logic
instead of calling into git or checking the modification time of files, simply print the warning if there is a very large number of "modified" files.
also make the wording much softer, so false positives are less alarming.
(warning was removed in https://github.com/rust-lang/rust/issues/134935)
|
|
bootstrap: `std::io::ErrorKind::CrossesDevices` is finally stable
|
|
|
|
The Deref brings in the documentation from slice, so it has the same
issue as slice.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"too" should be "to" here.
|
|
|
|
|
|
This was removed for not being used [1], but now we need it.
[1]: https://github.com/rust-lang/rust/pull/133478#discussion_r1874358362
|
|
|
|
|
|
|
|
|
|
|
|
This documents how to determine which settings are used in CI, since I
see this question come up regularly. We currently don't have a great way
to answer the question, but at least there is something.
|
|
|
|
|
|
|
|
Move the dist-aarch64-linux CI job to an aarch64 runner instead of
cross-compiling it from an x86 one. This will make it possible to
perform optimisations such as LTO, PGO and BOLT later on.
|
|
Implement `#[rust_analyzer::skip]` for bodies
|
|
|
|
|
|
|
|
Improve hover module path rendering
|
|
|
