| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
r=Urgau,davidtwco
Extends AArch64 branch protection support to include GCS
Extends existing support for AArch64 branch protection to include support for [Guarded Control Stacks](https://community.arm.com/arm-community-blogs/b/architectures-and-processors-blog/posts/arm-a-profile-architecture-2022#guarded-control-stack-gcs:~:text=Extraction%20or%20tracking.-,Guarded%20Control%20Stack%20(GCS),-With%20the%202022).
|
|
|
|
- Adds option to rustc config to enable GCS
- Passes `guarded-control-stack` flag to llvm if enabled
|
|
this uses some # directives to make sure the code works on x86_64, and does not produce errors on other platforms
|
|
|
|
Signed-off-by: xihuwenhua <xihuwenhua@outlook.com>
|
|
Add `-Zindirect-branch-cs-prefix`
Cc: ``@azhogin`` ``@Darksonn``
This goes on top of https://github.com/rust-lang/rust/pull/135927, i.e. please skip the first commit here. Please feel free to inherit it there.
In fact, I am not sure if there is any use case for the flag without `-Zretpoline*`. GCC and Clang allow it, though.
There is a `FIXME` for two `ignore`s in the test that I took from another test I did in the past -- they may be needed or not here since I didn't run the full CI. Either way, it is not critical.
Tracking issue: https://github.com/rust-lang/rust/issues/116852.
MCP: https://github.com/rust-lang/compiler-team/issues/868.
|
|
This removes the #[no_sanitize] attribute, which was behind an unstable
feature named no_sanitize. Instead, we introduce the sanitize attribute
which is more powerful and allows to be extended in the future (instead
of just focusing on turning sanitizers off).
This also makes sanitize(kernel_address = ..) attribute work with
-Zsanitize=address
To do it the same as how clang disables address sanitizer, we now
disable ASAN on sanitize(kernel_address = "off") and KASAN on
sanitize(address = "off").
The same was added to clang in https://reviews.llvm.org/D44981.
|
|
This is intended to be used for Linux kernel RETPOLINE builds.
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
|
|
|
|
This is more in-line with what Apple's tooling expects, and allows us to
better support custom compiler drivers (such as certain Homebrew and
Nixpkgs compilers) that prefer their own `-isysroot` flag.
Effectively, we now invoke the compiler driver as-if it was invoked as
`xcrun -sdk $sdk_name $tool`.
|
|
r=ChrisDenton
Stabilize `duration_constructors_lite` feature
This closes [tracking issue](https://github.com/rust-lang/rust/issues/140881) and stabilises `Duration::from_hours` and `Duration::from_mins` while not touching a `duration_constructors` feature from the related [tracking issue (2)](https://github.com/rust-lang/rust/issues/120301)
|
|
Stabilize loongarch32 inline asm
r? ````````@Amanieu````````
|
|
unstable-book: Add stubs for environment variables; document some of the important ones
This uses a very hacky regex that will probably miss some variables. But having some docs seems better than none at all.
In particular, this documents the following env vars explicitly (cc ````````@madsmtm```````` ````````@flba-eb```````` - do the docs for SDKROOT and QNX_TARGET look right?):
- COLORTERM
- QNX_TARGET
- SDKROOT
- TERM
and generates stubs for the following env vars:
- RUST_BACKTRACE
- RUSTC_BLESS
- RUSTC_BREAK_ON_ICE
- RUSTC_CTFE_BACKTRACE
- RUSTC_FORCE_RUSTC_VERSION
- RUSTC_GRAPHVIZ_FONT
- RUSTC_ICE
- RUSTC_LOG
- RUSTC_RETRY_LINKER_ON_SEGFAULT
- RUSTC_TRANSLATION_NO_DEBUG_ASSERT
- RUST_DEP_GRAPH_FILTER
- RUST_DEP_GRAPH
- RUST_FORBID_DEP_GRAPH_EDGE
- RUST_MIN_STACK
- RUST_TARGET_PATH
- UNSTABLE_RUSTDOC_TEST_LINE
- UNSTABLE_RUSTDOC_TEST_PATH
rendered: 
|
|
Co-authored-by: Florian Bartels <108917393+flba-eb@users.noreply.github.com>
Co-authored-by: Mads Marquart <mads@marquart.dk>
|
|
|
|
|
|
|
|
|
|
|
|
- Update ui.md
- Update type-alias-impl-trait.md
- Update README.md
|
|
Add PrintTAFn flag for targeted type analysis printing
## Summary
This PR adds a new `PrintTAFn` flag to the `-Z autodiff` option that allows printing type analysis information for a specific function, rather than all functions.
## Changes
### New Flag
- Added `PrintTAFn=<function_name>` option to `-Z autodiff`
- Usage: `-Z autodiff=Enable,PrintTAFn=my_function_name`
### Implementation Details
- **Rust side**: Added `PrintTAFn(String)` variant to `AutoDiff` enum
- **Parser**: Updated `parse_autodiff` to handle `PrintTAFn=<function_name>` syntax with proper error handling
- **FFI**: Added `set_print_type_fun` function to interface with Enzyme's `FunctionToAnalyze` command line option
- **Documentation**: Updated help text and documentation for the new flag
### Files Modified
- `compiler/rustc_session/src/config.rs`: Added `PrintTAFn(String)` variant
- `compiler/rustc_session/src/options.rs`: Updated parser and help text (now shows `PrintTAFn` in the list)
- `compiler/rustc_codegen_llvm/src/llvm/enzyme_ffi.rs`: Added FFI function and static variable
- `compiler/rustc_codegen_llvm/src/back/lto.rs`: Added handling for new flag
- `src/doc/rustc-dev-guide/src/autodiff/flags.md`: Updated documentation
- `src/doc/unstable-book/src/compiler-flags/autodiff.md`: Updated documentation
## Testing
The flag can be tested with:
```bash
rustc +enzyme -Z autodiff=Enable,PrintTAFn=square test.rs
```
This will print type analysis information only for the function named "square" instead of all functions.
## Error Handling
The parser includes proper error handling:
- Missing argument: `PrintTAFn` without `=<function_name>` will show an error
- Unknown options: Invalid autodiff options will be reported
r? ```@ZuseZ4```
|
|
|
|
|
|
Tweak `-Zmacro-stats` measurement.
It currently reports net size, i.e. size(output) - size(input). After some use I think this is sub-optimal, and it's better to just report size(output). Because for derive macros the input size is always 1, and for attribute macros it's almost always 1.
r? ```@petrochenkov```
|
|
r=oli-obk,traviscross
Add `#[loop_match]` for improved DFA codegen
tracking issue: https://github.com/rust-lang/rust/issues/132306
project goal: https://github.com/rust-lang/rust-project-goals/issues/258
This PR adds the `#[loop_match]` attribute, which aims to improve code generation for state machines. For some (very exciting) benchmarks, see https://github.com/rust-lang/rust-project-goals/issues/258#issuecomment-2732965199
Currently, a very restricted syntax pattern is accepted. We'd like to get feedback and merge this now before we go too far in a direction that others have concerns with.
## current state
We accept code that looks like this
```rust
#[loop_match]
loop {
state = 'blk: {
match state {
State::A => {
#[const_continue]
break 'blk State::B
}
State::B => { /* ... */ }
/* ... */
}
}
}
```
- a loop should have the same semantics with and without `#[loop_match]`: normal `continue` and `break` continue to work
- `#[const_continue]` is only allowed in loops annotated with `#[loop_match]`
- the loop body needs to have this particular shape (a single assignment to the match scrutinee, with the body a labelled block containing just a match)
## future work
- perform const evaluation on the `break` value
- support more state/scrutinee types
## maybe future work
- allow `continue 'label value` syntax, which `#[const_continue]` could then use.
- allow the match to be on an arbitrary expression (e.g. `State::Initial`)
- attempt to also optimize `break`/`continue` expressions that are not marked with `#[const_continue]`
r? ``@traviscross``
|
|
Signed-off-by: Karan Janthe <karanjanthe@gmail.com>
|
|
Remove the deprecated unstable `concat_idents!` macro
In [rust-lang/rust#137653], the lang and libs-API teams did a joint FCP to deprecate
and eventually remove the long-unstable `concat_idents!` macro. The
deprecation is landing in 1.88, so do the removal here (target version
1.90).
This macro has been superseded by the more recent `${concat(...)}`
metavariable expression language feature, which avoids some of the
limitations of `concat_idents!`. The metavar expression is unstably
available under the [`macro_metavar_expr_concat`] feature.
History is mildly interesting here: `concat_idents!` goes back to 2011
when it was introduced with 513276e595f8 ("Add #concat_idents[] and
#ident_to_str[]"). The syntax looks a bit different but it still works
about the same:
let asdf_fdsa = "<.<";
assert(#concat_idents[asd,f_f,dsa] == "<.<");
assert(#ident_to_str[use_mention_distinction]
== "use_mention_distinction");
(That test existed from introduction until its removal here.)
Closes: https://github.com/rust-lang/rust/issues/29599
[rust-lang/rust#137653]: https://github.com/rust-lang/rust/pull/137653
[`macro_metavar_expr_concat`]: https://github.com/rust-lang/rust/issues/124225
|
|
In [137653], the lang and libs-API teams did a joint FCP to deprecate
and eventually remove the long-unstable `concat_idents!` macro. The
deprecation is landing in 1.88, so do the removal here (target version
1.90).
This macro has been superseded by the more recent `${concat(...)}`
metavariable expression language feature, which avoids some of the
limitations of `concat_idents!`. The metavar expression is unstably
available under the [`macro_metavar_expr_concat`] feature.
History is mildly interesting here: `concat_idents!` goes back to 2011
when it was introduced with 513276e595f8 ("Add #concat_idents[] and
about the same:
let asdf_fdsa = "<.<";
assert(#concat_idents[asd,f_f,dsa] == "<.<");
assert(#ident_to_str[use_mention_distinction]
== "use_mention_distinction");
(That test existed from introduction until its removal here.)
Closes: https://www.github.com/rust-lang/rust/issues/29599
[137653]: https://www.github.com/rust-lang/rust/pull/137653
[`macro_metavar_expr_concat`]: https://www.github.com/rust-lang/rust/issues/124225
|
|
It currently reports net size, i.e. size(output) - size(input). After
some use I think this is sub-optimal, and it's better to just report
size(output). Because for derive macros the input size is always 1, and
for attribute macros it's almost always 1.
|
|
Co-authored-by: Folkert de Vries <folkert@folkertdev.nl>
|
|
it should not suggest just `#[align]`
|
|
Add `-Z hint-mostly-unused` to tell rustc that most of a crate will go unused
This hint allows the compiler to optimize its operation based on this assumption, in order to compile faster. This is a hint, and does not guarantee any particular behavior.
This option can substantially speed up compilation if applied to a large dependency where the majority of the dependency does not get used. This flag may slow down compilation in other cases.
Currently, this option makes the compiler defer as much code generation as possible from functions in the crate, until later crates invoke those functions. Functions that never get invoked will never have code generated for them. For instance, if a crate provides thousands of functions, but only a few of them will get called, this flag will result in the compiler only doing code generation for the called functions. (This uses the same mechanisms as cross-crate inlining of functions.) This does not affect `extern` functions, or functions marked as `#[inline(never)]`.
This option has already existed in nightly as `-Zcross-crate-inline-threshold=always` for some time, and has gotten testing in that form. However, this option is still unstable, to give an opportunity for wider testing in this form.
Some performance numbers, based on a crate with many dependencies having just *one* large dependency set to `-Z hint-mostly-unused` (using Cargo's `profile-rustflags` option):
A release build went from 4m07s to 2m04s.
A non-release build went from 2m26s to 1m28s.
|
|
Unimplement unsized_locals
Implements https://github.com/rust-lang/compiler-team/issues/630
Tracking issue here: https://github.com/rust-lang/rust/issues/111942
Note that this just removes the feature, not the implementation, and does not touch `unsized_fn_params`. This is because it is required to support `Box<dyn FnOnce()>: FnOnce()`.
There may be more that should be removed (possibly in follow up prs)
- the `forget_unsized` function and `forget` intrinsic.
- the `unsized_locals` test directory; I've just fixed up the tests for now
- various codegen support for unsized values and allocas
cc ``@JakobDegen`` ``@oli-obk`` ``@Noratrieb`` ``@programmerjake`` ``@bjorn3``
``@rustbot`` label F-unsized_locals
Fixes rust-lang/rust#79409
|
|
Rollup of 9 pull requests
Successful merges:
- rust-lang/rust#128425 (Make `missing_fragment_specifier` an unconditional error)
- rust-lang/rust#135927 (retpoline and retpoline-external-thunk flags (target modifiers) to enable retpoline-related target features)
- rust-lang/rust#140770 (add `extern "custom"` functions)
- rust-lang/rust#142176 (tests: Split dont-shuffle-bswaps along opt-levels and arches)
- rust-lang/rust#142248 (Add supported asm types for LoongArch32)
- rust-lang/rust#142267 (assert more in release in `rustc_ast_lowering`)
- rust-lang/rust#142274 (Update the stdarch submodule)
- rust-lang/rust#142276 (Update dependencies in `library/Cargo.lock`)
- rust-lang/rust#142308 (Upgrade `object`, `addr2line`, and `unwinding` in the standard library)
Failed merges:
- rust-lang/rust#140920 (Extract some shared code from codegen backend target feature handling)
r? `@ghost`
`@rustbot` modify labels: rollup
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
|
|
|
|
It collects data about macro expansions and prints them in a table after
expansion finishes. It's very useful for detecting macro bloat,
especially for proc macros.
Details:
- It measures code snippets by pretty-printing them and then measuring
lines and bytes. This required a bunch of additional pretty-printing
plumbing, in `rustc_ast_pretty` and `rustc_expand`.
- The measurement is done in `MacroExpander::expand_invoc`.
- The measurements are stored in `ExtCtxt::macro_stats`.
|
|
|
|
This hint allows the compiler to optimize its operation based on this
assumption, in order to compile faster. This is a hint, and does not
guarantee any particular behavior.
This option can substantially speed up compilation if applied to a large
dependency where the majority of the dependency does not get used. This flag
may slow down compilation in other cases.
Currently, this option makes the compiler defer as much code generation as
possible from functions in the crate, until later crates invoke those
functions. Functions that never get invoked will never have code generated for
them. For instance, if a crate provides thousands of functions, but only a few
of them will get called, this flag will result in the compiler only doing code
generation for the called functions. (This uses the same mechanisms as
cross-crate inlining of functions.) This does not affect `extern` functions, or
functions marked as `#[inline(never)]`.
Some performance numbers, based on a crate with many dependencies having
just *one* large dependency set to `-Z hint-mostly-unused` (using
Cargo's `profile-rustflags` option):
A release build went from 4m07s to 2m04s.
A non-release build went from 2m26s to 1m28s.
|
|
|
|
|
|
This uses a very hacky regex that will probably miss some variables. But
having some docs seems better than none at all.
This uses a very hacky regex that will probably miss some variables. But having some docs seems better than none at all.
In particular, this generates stubs for the following env vars:
- COLORTERM
- QNX_TARGET
- RUST_BACKTRACE
- RUSTC_BLESS
- RUSTC_BOOTSTRAP
- RUSTC_BREAK_ON_ICE
- RUSTC_CTFE_BACKTRACE
- RUSTC_FORCE_RUSTC_VERSION
- RUSTC_GRAPHVIZ_FONT
- RUSTC_ICE
- RUSTC_LOG
- RUSTC_OVERRIDE_VERSION_STRING
- RUSTC_RETRY_LINKER_ON_SEGFAULT
- RUSTC_TRANSLATION_NO_DEBUG_ASSERT
- RUST_DEP_GRAPH_FILTER
- RUST_DEP_GRAPH
- RUST_FORBID_DEP_GRAPH_EDGE
- RUST_MIN_STACK
- RUST_TARGET_PATH
- SDKROOT
- TERM
- UNSTABLE_RUSTDOC_TEST_LINE
- UNSTABLE_RUSTDOC_TEST_PATH
[rendered]()
|
|
|
|
|
|
|
|
|
|
|
|
This does not yet handle the case of mixed deref patterns with normal
constructors; it'll ICE in `Constructor::is_covered_by`. That'll be
fixed in a later commit.
|
|
`deref_patterns`: let string and byte string literal patterns peel references and smart pointers before matching
This follows up on #140028. Together, they allow using string and byte string literal patterns to match on smart pointers when `deref_patterns` is enabled. In particular, string literals can now match on `String`, subsuming the functionality of the `string_deref_patterns` feature.
More generally, this works by letting literals peel references (and smart pointers) before matching, similar to most other patterns, providing an answer to #44849. Though it's only partially implemented at this point: this doesn't yet let named const patterns peel before matching. The peeling logic is general enough to support named consts, but the typing rules for named const patterns would need adjustments to feel consistent (e.g. arrays would need rules to be usable as slices, and `const STR: &'static str` wouldn't be able to match on a `String` unless a rule was added to let it be used where a `str` is expected, similar to what #140028 did for literals).
This also allows string and byte string patterns to match on mutable references, following up on https://github.com/rust-lang/rust/pull/140028#discussion_r2053927512. Rather than forward the mutability of the scrutinee to literal patterns, I've opted to peel `&mut`s from the scrutinee. From a design point of view, this makes the behavior consistent with what would be expected from deref coercions using the methodology in the next paragraph. From a diagnostics point of view, this avoids labeling string and byte string patterns as "mutable references", which I think could be confusing. See [`byte-string-type-errors.rs`](https://github.com/rust-lang/rust/compare/master...dianne:rust:lit-deref-pats-p2?expand=1#diff-4a0dd9b164b67c706751f3c0b5762ddab08bcef05a91972beb0190c6c1cd3706) for how the diagnostics look.
At a high level, the peeling logic implemented here tries to mimic how deref coercions work for expressions: we peel references (and smart pointers) from the scrutinee until the pattern can match against it, and no more. This is primarily tested by [`const-pats-do-not-mislead-inference.rs`](https://github.com/rust-lang/rust/compare/master...dianne:rust:lit-deref-pats-p2?expand=1#diff-19afc05b8aae9a30fe4a3a8c0bc2ab2c56b58755a45cdf5c12be0d5e83c4739d). To illustrate the connection, I wasn't sure if this made sense to include in the test file, but I've translated those tests to make sure they give the same inference results as deref coercions: [(playground)](https://play.rust-lang.org/?version=stable&mode=debug&edition=2024&gist=1869744cb9cdfed71a686990aadf9fe1). In each case, a reference to the scrutinee is coerced to have the type of the pattern (under a reference).
Tracking issue for deref patterns: #87121
r? `@oli-obk`
cc `@Nadrieril`
|
