| Age | Commit message (Collapse) | Author | Lines |
|---|
|
- Consolidate calculation of the effective value.
- Check the target `DebuginfoKind` instead of using `is_like_msvc`.
|
|
|
|
|
|
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
|
|
|
|
mark deprecated option as deprecated in rustc_session to remove copypasta and small refactor
This marks deprecated options as deprecated via flag in options table in rustc_session, which removes copypasted deprecation text from rustc_driver_impl.
This also adds warning for deprecated `-C ar` option, which didn't emitted any warnings before.
Makes `inline_threshold` `[UNTRACKED]`, as it do nothing.
Adds few tests.
See individual commits.
|
|
inline_threshold mark deprecated
no-stack-check
print deprecation message for -Car too
inline_threshold deprecated and do nothing: make in untracked
make OptionDesc struct from tuple
|
|
Gated behind an unstable `-Z emscripten-wasm-eh` flag
|
|
|
|
We don't need `NonNull::as_ptr` debuginfo
In order to stop pessimizing the use of local variables in core, skip debug info for MIR temporaries in tiny (single-BB) functions.
For functions as simple as this -- `Pin::new`, etc -- nobody every actually wants debuginfo for them in the first place. They're more like intrinsics than real functions, and stepping over them is good.
|
|
Stop pessimizing the use of local variables in core by skipping debug info for MIR temporaries in tiny (single-BB) functions.
For functions as simple as this -- `Pin::new`, etc -- nobody every actually wants debuginfo for them in the first place. They're more like intrinsics than real functions, and stepping over them is good.
|
|
|
|
rust_for_linux: -Zreg-struct-return commandline flag for X86 (#116973)
Command line flag `-Zreg-struct-return` for X86 (32-bit) for rust-for-linux.
This flag enables the same behavior as the `abi_return_struct_as_int` target spec key.
- Tracking issue: https://github.com/rust-lang/rust/issues/116973
|
|
Remove `-Zshow-span`.
It's very old (added in #12087). It's strange, and it's not clear what its use cases are. It only works with the crate root file because it runs before expansion. I suspect it won't be missed.
r? `@estebank`
|
|
It's very old (added in #12087). It's strange, and it's not clear what
its use cases are. It only works with the crate root file because it
runs before expansion. I suspect it won't be missed.
|
|
Require `type_map::stub` callers to supply file information
This change attaches file information (`DIFile` reference and line number) to struct debug info nodes.
Before:
```
; foo.ll
...
!5 = !DIFile(filename: "<unknown>", directory: "")
...
!16 = !DICompositeType(tag: DW_TAG_structure_type, name: "MyType", scope: !2, file: !5, size: 32, align: 32, elements: !17, templateParams: !19, identifier: "4cb373851db92e732c4cb5651b886dd0")
...
```
After:
```
; foo.ll
...
!3 = !DIFile(filename: "foo.rs", directory: "/home/matt/src/rust98678", checksumkind: CSK_SHA1, checksum: "bcb9f08512c8f3b8181ef4726012bc6807bc9be4")
...
!16 = !DICompositeType(tag: DW_TAG_structure_type, name: "MyType", scope: !2, file: !3, line: 3, size: 32, align: 32, elements: !17, templateParams: !19, identifier: "9e5968c7af39c148acb253912b7f409f")
...
```
Fixes #98678
r? `@wesleywiser`
|
|
|
|
To clarify how it works.
|
|
I was surprised to find that running with `-Zparse-only` only parses the
crate root file. Other files aren't parsed because that happens later
during expansion.
This commit renames the option and updates the help message to make this
clearer.
|
|
|
|
Don't allow `-Zunstable-options` to take a value
Passing an explicit boolean value (`-Zunstable-options=on`, `off` etc.) sometimes appears to work, but actually puts the compiler into an unintended state where unstable _options_ are still forbidden, but unstable values of _some_ stable options are allowed.
This is a result of `-Zunstable-options` being checked in multiple different places, in slightly different ways. Fixing the checks in `config::nightly_options` to understand boolean values would be non-trivial, so for now it's easier to make things consistent by forbidding values in the `-Z` parser.
---
There were a few uses of this in tests, which happened to work because they were tests of unstable values.
|
|
unstable feature usage metrics
example output
```
test-lib on master [?] is 📦 v0.1.0 via 🦀 v1.80.1
❯ cat src/lib.rs
───────┬───────────────────────────────────────────────────────
│ File: src/lib.rs
───────┼───────────────────────────────────────────────────────
1 │ #![feature(unix_set_mark)]
2 │ pub fn add(left: u64, right: u64) -> u64 {
3 │ left + right
4 │ }
5 │
6 │ #[cfg(test)]
7 │ mod tests {
8 │ use super::*;
9 │
10 │ #[test]
11 │ fn it_works() {
12 │ let result = add(2, 2);
13 │ assert_eq!(result, 4);
14 │ }
15 │ }
───────┴───────────────────────────────────────────────────────
test-lib on master [?] is 📦 v0.1.0 via 🦀 v1.80.1
❯ cargo +stage1 rustc -- -Zmetrics-dir=$PWD/metrics
Compiling test-lib v0.1.0 (/home/yaahc/tmp/test-lib)
Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.08s
test-lib on master [?] is 📦 v0.1.0 via 🦀 v1.80.1
❯ cat metrics/unstable_feature_usage.json
───────┬─────────────────────────────────────────────────────────────────────
│ File: metrics/unstable_feature_usage.json
───────┼─────────────────────────────────────────────────────────────────────
1 │ {"lib_features":[{"symbol":"unix_set_mark"}],"lang_features":[]}
```
related to https://github.com/rust-lang/rust/issues/129485
|
|
|
|
Passing an explicit boolean value (`on`, `off` etc.) appears to work, but
actually puts the compiler into an unintended state where unstable _options_
are still forbidden, but unstable values of _some_ stable options are allowed.
|
|
The old name and comment suggest that this parser is only used for options
beginning with `no-`, which is mostly true but not entirely true.
|
|
|
|
|
|
|
|
|
|
rustc_codegen_llvm: Add a new 'pc' option to branch-protection
Add a new 'pc' option to -Z branch-protection for aarch64 that enables the use of PC as a diversifier in PAC branch protection code.
When the pauth-lr target feature is enabled in combination with -Z branch-protection=pac-ret,pc, the new 9.5-a instructions (pacibsppc, retaasppc, etc) will be generated.
|
|
Fix compiler panic with a large number of threads
Hi,
This PR is an attempt to fix the problem described here https://github.com/rust-lang/rust/issues/117638 using the solution suggested in this comment https://github.com/rust-lang/rust/issues/117638#issuecomment-1800925067
Best regards,
Michal
|
|
make codegen help output more consistent
The output of `rustc -C help` generally has one option per line. There was one exception because of a (presumably) forgotten line continuation escape.
|
|
This changes the naming to the new naming, used by `--print
target-tuple`.
It does not change all locations, but many.
|
|
The output of `rustc -C help` generally has one option per line. There was one
exception because of a (presumably) forgotten line continuation escape.
|
|
|
|
Add a new 'pc' option to -Z branch-protection for aarch64 that
enables the use of PC as a diversifier in PAC branch protection code.
When the pauth-lr target feature is enabled in combination
with -Z branch-protection=pac-ret,pc, the new 9.5-a instructions
(pacibsppc, retaasppc, etc) will be generated.
|
|
|
|
Co-authored-by: Jubilee <workingjubilee@gmail.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
MCP: https://github.com/rust-lang/compiler-team/issues/782
Co-authored-by: bjorn3 <17426603+bjorn3@users.noreply.github.com>
|
|
|
|
deprecate -Csoft-float because it is unsound (and not fixable)
See https://github.com/rust-lang/rust/issues/129893 for details. The general sentiment there seems to be that this flag has no use and sound alternatives exist, so let's add this warning and see if anyone out there disagrees.
Also show a different warning on targets where it does nothing (as documented since https://github.com/rust-lang/rust/pull/36261): it seems to correspond to `-mfloat-abi` in GCC/clang, which is an ARM-specific option. To be really sure it does nothing, only forward the flag to LLVM for eabihf targets. This should not change behavior but makes me sleep better ;)
|
|
Revert "Stabilize `-Znext-solver=coherence`"
This is a clean revert of #121848, prepared by running:
```
$ git revert 17b322fa69eed7216dccc9f097eb68237cf62234 -m1
```
Which effectively reverts:
* a138a9261536ac2bdbb7c01a8aa9dc7d43299cae, 69fdd1457d367ce4de044e9784e58a38acf3d847, d93e047c9f1b33892a604273ab3931815f5604a1, 1a893ac648e03732aaa8b5371b602ab683970b0d
see: https://rust-lang.zulipchat.com/#narrow/stream/364551-t-types.2Ftrait-system-refactor/topic/nalgebra.20hang
Closes #130056
r? lcnr
|
|
Add -Z small-data-threshold
This flag allows specifying the threshold size above which LLVM should not consider placing small objects in a `.sdata` or `.sbss` section.
Support is indicated in the target options via the
small-data-threshold-support target option, which can indicate either an
LLVM argument or an LLVM module flag. To avoid duplicate specifications
in a large number of targets, the default value for support is
DefaultForArch, which is translated to a concrete value according to the
target's architecture.
|
|
|
