| Age | Commit message (Collapse) | Author | Lines |
|---|
|
It will run at the project root, so resolving absolute/top-level paths
is unnecessary.
Signed-off-by: onur-ozkan <work@onurozkan.dev>
|
|
rustc_target: Add pauth-lr aarch64 target feature
Add the pauth-lr target feature, corresponding to aarch64 FEAT_PAuth_LR. This feature has been added in LLVM 19.
It is currently not supported by the Linux hwcap and so we cannot add runtime feature detection for it at this time.
r? `@Amanieu`
|
|
Add an unstable `const_sockaddr_setters` feature
Unstably add `const` to the `sockaddr_setters` methods. Included API:
```rust
// core::net
impl SocketAddr {
pub const fn set_ip(&mut self, new_ip: IpAddr);
pub const fn set_port(&mut self, new_port: u16);
}
impl SocketAddrV4 {
pub const fn set_ip(&mut self, new_ip: Ipv4Addr);
pub const fn set_port(&mut self, new_port: u16);
}
impl SocketAddrV6 {
pub const fn set_ip(&mut self, new_ip: Ipv6Addr);
pub const fn set_port(&mut self, new_port: u16);
}
```
Tracking issue: <https://github.com/rust-lang/rust/issues/131714>
|
|
Rollup of 3 pull requests
Successful merges:
- #131875 (Add WASM | WASI | Emscripten groups to triagebot.toml)
- #132019 (Document `PartialEq` impl for `OnceLock`)
- #132182 (Downgrade `untranslatable_diagnostic` and `diagnostic_outside_of_impl` to `allow`)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Downgrade `untranslatable_diagnostic` and `diagnostic_outside_of_impl` to `allow`
Current implementation of translatable diagnostics infrastructure unfortunately causes some friction for compiler contributors. While we don't have a redesign that causes less friction in place, let's downgrade the internal `untranslatable_diagnostic` and `diagnostic_outside_of_impl` lints so we don't indicate to contributors that they *have* to use the current translation infra.
I purposefully left `#[allow(untranslatable_diagnostic)]` and `#[allow(diagnostic_outside_of_impl)]` instances untouched because that seems like unnecessary additional churn.
See <https://github.com/rust-lang/rust/issues/132181> for context.
r? `@davidtwco` (or wg-diagnostics/compiler)
|
|
r=Mark-Simulacrum
Document `PartialEq` impl for `OnceLock`
Adds documentation to `std::sync::OnceLock`'s `PartialEq` implementation: specifies publicly that `OnceLock`s are compared based on their contents, and nothing else.
Created in response to, but not directly related to, https://github.com/rust-lang/rust/issues/131959.
## ne
This doesn't create and document `PartialEq::ne`. There's precedent for this in [`RefCell`](https://doc.rust-lang.org/std/cell/struct.RefCell.html#impl-PartialEq-for-RefCell%3CT%3E).
|
|
r=Mark-Simulacrum
Add WASM | WASI | Emscripten groups to triagebot.toml
Tracking issue: https://github.com/rust-lang/compiler-team/issues/799
~~This is blocked on amending the notification group section so that the instructions links point somewhere: https://github.com/rust-lang/rustc-dev-guide/pull/2100~~
|
|
(Big performance change) Do not run lints that cannot emit
Before this change, adding a lint was a difficult matter because it always had some overhead involved. This was because all lints would run, no matter their default level, or if the user had `#![allow]`ed them. This PR changes that. This change would improve both the Rust lint infrastructure and Clippy, but Clippy will see the most benefit, as it has about 900 registered lints (and growing!)
So yeah, with this little patch we filter all lints pre-linting, and remove any lint that is either:
- Manually `#![allow]`ed in the whole crate,
- Allowed in the command line, or
- Not manually enabled with `#[warn]` or similar, and its default level is `Allow`
As some lints **need** to run, this PR also adds **loadbearing lints**. On a lint declaration, you can use the ``@eval_always` = true` marker to label it as loadbearing. A loadbearing lint will never be filtered (it will always run)
Fixes #106983
|
|
`allow`
See <https://github.com/rust-lang/rust/issues/132181> for more context.
|
|
Rollup of 5 pull requests
Successful merges:
- #132124 (coverage: Consolidate creation of covmap/covfun records)
- #132140 (Enable LSX feature for LoongArch Linux targets)
- #132169 (Deny calls to non-`#[const_trait]` methods in MIR constck)
- #132174 (x86 target features: make pclmulqdq imply sse2)
- #132180 (Print unsafety of attribute in AST pretty print)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Print unsafety of attribute in AST pretty print
This PR fixes the AST pretty print, which was missing the unsafety for unsafe attributes.
Related to https://github.com/rust-lang/rust/pull/131558#discussion_r1807736204
|
|
x86 target features: make pclmulqdq imply sse2
Based on comments in https://github.com/rust-lang/stdarch/issues/1661
Fixes https://github.com/rust-lang/stdarch/issues/1661
|
|
Deny calls to non-`#[const_trait]` methods in MIR constck
This is a (potentially temporary) fix that closes off the mismatch in assumptions between MIR constck and typeck which does the const traits checking. Before this PR, MIR constck assumed that typeck correctly handled all calls to trait methods in const contexts if effects is enabled. That is not true because typeck only correctly handles callees that are const. For non-const callees (such as methods in a non-const_trait), typeck had never created an error.
https://github.com/rust-lang/rust/blob/45089ec19ebebec88bace6ec237244ff0eaa7ad3/compiler/rustc_hir_typeck/src/callee.rs#L876-L877
I called this potentially temporary because the const checks could be moved to HIR entirely. Alongside the recent refactor in const stability checks where that component could be placed would need more discussion. (cc ```@compiler-errors``` ```@RalfJung)```
Tests are updated, mainly due to traits not being const in core, so tests that call them correctly error.
This fixes https://github.com/rust-lang/project-const-traits/issues/12.
|
|
Enable LSX feature for LoongArch Linux targets
Enable 128-bit vector (LSX) feature for `loongarch64-unknown-linux-{gnu, musl}` targets.
try-job: dist-loongarch64-linux
try-job: dist-loongarch64-musl
|
|
coverage: Consolidate creation of covmap/covfun records
This code for creating covmap/covfun records during codegen was split across multiple functions and files for dubious historical reasons. Having it all in one place makes it easier to follow.
This PR also includes two semi-related cleanups:
- Getting the codegen context's `coverage_cx` state is made infallible, since it should always exist when running the code paths that need it.
- The value of `covfun_section_name` is saved in the codegen context, since it never changes at runtime, and the code that needs it has access to the context anyway.
---
Background: Coverage instrumentation generates two kinds of metadata that are embedded in the final binary. There is per-CGU information that goes in the `__llvm_covmap` linker section, and per-function information that goes in the `__llvm_covfun` section (except on Windows, where slightly different section names are used).
|
|
Enable the llvm offload build configuration
Tracking:
- https://github.com/rust-lang/rust/issues/131513
|
|
|
|
|
|
|
|
Rollup of 3 pull requests
Successful merges:
- #132114 (Use `Enabled{Lang,Lib}Feature` instead of n-tuples)
- #132163 (Update Fuchsia CI script for package serving)
- #132168 (Effects cleanup)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
|
|
Effects cleanup
- removed extra bits from predicates queries that are no longer needed in the new system
- removed the need for `non_erasable_generics` to take in tcx and DefId, removed unused arguments in callers
r? compiler-errors
|
|
Update Fuchsia CI script for package serving
This updates the "start" and "stop" methods
of the test runner to use the standalone package
server.
r? `@tmandry`
|
|
Use `Enabled{Lang,Lib}Feature` instead of n-tuples
Instead of passing around e.g. `(gate_name, attr_span, stable_since)` 3-tuples for enabled lang features or `(gate_name, attr_span)` 2-tuples for enabled lib features, use `Enabled{Lang,Lib}Feature` structs with named fields.
Also did some minor code-golfing of involved iterator chains to hopefully make them easier to follow.
Follow-up to https://github.com/rust-lang/rust/pull/132098#issuecomment-2434523431 cc `@RalfJung.`
|
|
Revert #127731 "Emit error when calling/declaring functions with unavailable …"
This reverts #127731 due to the unexpected [perf regressions](https://github.com/rust-lang/rust/pull/127731#issuecomment-2438687094) and to give time to mitigate the regressions before re-landing it.
r? `@RalfJung` cc `@veluca93`
|
|
|
|
- removed extra bits from predicates queries that are no longer needed in the new system
- removed the need for `non_erasable_generics` to take in tcx and DefId, removed unused arguments in callers
|
|
Update cargo
14 commits in cf53cc54bb593b5ec3dc2be4b1702f50c36d24d5..e75214ea4936d2f2c909a71a1237042cc0e14b07
2024-10-18 13:56:15 +0000 to 2024-10-25 16:34:32 +0000
- refactor(env): remove unnecessary clones (rust-lang/cargo#14730)
- test(install): Verify 2024 edition / resolver=3 doesn't affect resolution (rust-lang/cargo#14724)
- Fix: trace `config` `[env]` table in dep-info. (rust-lang/cargo#14701)
- Added unstable-schema generation for Cargo.toml (rust-lang/cargo#14683)
- fix: add source replacement info when no matching package found (rust-lang/cargo#14715)
- feat(complete): Include descriptions in zsh (rust-lang/cargo#14726)
- refactor(fingerprint): avoid unnecessary fopen calls (rust-lang/cargo#14728)
- docs(resolver): Make room for v3 resolver (rust-lang/cargo#14725)
- test: add fixes in the sat resolver (rust-lang/cargo#14707)
- docs(ci): Don't constrainty latest_deps job by MSRV (rust-lang/cargo#14711)
- refactor: use `Iterator::is_sorted` (rust-lang/cargo#14702)
- refactor(rustfix): minor refactors (rust-lang/cargo#14710)
- chore(deps): update msrv (rust-lang/cargo#14705)
- fix(renovate): Switch matchPackageNames to matchDepNames (rust-lang/cargo#14704)
|
|
|
|
Const stability checks v2
The const stability system has served us well ever since `const fn` were first stabilized. It's main feature is that it enforces *recursive* validity -- a stable const fn cannot internally make use of unstable const features without an explicit marker in the form of `#[rustc_allow_const_fn_unstable]`. This is done to make sure that we don't accidentally expose unstable const features on stable in a way that would be hard to take back. As part of this, it is enforced that a `#[rustc_const_stable]` can only call `#[rustc_const_stable]` functions. However, some problems have been coming up with increased usage:
- It is baffling that we have to mark private or even unstable functions as `#[rustc_const_stable]` when they are used as helpers in regular stable `const fn`, and often people will rather add `#[rustc_allow_const_fn_unstable]` instead which was not our intention.
- The system has several gaping holes: a private `const fn` without stability attributes whose inherited stability (walking up parent modules) is `#[stable]` is allowed to call *arbitrary* unstable const operations, but can itself be called from stable `const fn`. Similarly, `#[allow_internal_unstable]` on a macro completely bypasses the recursive nature of the check.
Fundamentally, the problem is that we have *three* disjoint categories of functions, and not enough attributes to distinguish them:
1. const-stable functions
2. private/unstable functions that are meant to be callable from const-stable functions
3. functions that can make use of unstable const features
Functions in the first two categories cannot use unstable const features and they can only call functions from the first two categories.
This PR implements the following system:
- `#[rustc_const_stable]` puts functions in the first category. It may only be applied to `#[stable]` functions.
- `#[rustc_const_unstable]` by default puts functions in the third category. The new attribute `#[rustc_const_stable_indirect]` can be added to such a function to move it into the second category.
- `const fn` without a const stability marker are in the second category if they are still unstable. They automatically inherit the feature gate for regular calls, it can now also be used for const-calls.
Also, all the holes mentioned above have been closed. There's still one potential hole that is hard to avoid, which is when MIR building automatically inserts calls to a particular function in stable functions -- which happens in the panic machinery. Those need to be manually marked `#[rustc_const_stable_indirect]` to be sure they follow recursive const stability. But that's a fairly rare and special case so IMO it's fine.
The net effect of this is that a `#[unstable]` or unmarked function can be constified simply by marking it as `const fn`, and it will then be const-callable from stable `const fn` and subject to recursive const stability requirements. If it is publicly reachable (which implies it cannot be unmarked), it will be const-unstable under the same feature gate. Only if the function ever becomes `#[stable]` does it need a `#[rustc_const_unstable]` or `#[rustc_const_stable]` marker to decide if this should also imply const-stability.
Adding `#[rustc_const_unstable]` is only needed for (a) functions that need to use unstable const lang features (including intrinsics), or (b) `#[stable]` functions that are not yet intended to be const-stable. Adding `#[rustc_const_stable]` is only needed for functions that are actually meant to be directly callable from stable const code. `#[rustc_const_stable_indirect]` is used to mark intrinsics as const-callable and for `#[rustc_const_unstable]` functions that are actually called from other, exposed-on-stable `const fn`. No other attributes are required.
Also see the updated dev-guide at https://github.com/rust-lang/rustc-dev-guide/pull/2098.
I think in the future we may want to tweak this further, so that in the hopefully common case where a public function's const-stability just exactly mirrors its regular stability, we never have to add any attribute. But right now, once the function is stable this requires `#[rustc_const_stable]`.
### Open question
There is one point I could see we might want to do differently, and that is putting `#[rustc_const_unstable]` functions (but not intrinsics) in category 2 by default, and requiring an extra attribute for `#[rustc_const_not_exposed_on_stable]` or so. This would require a bunch of extra annotations, but would have the advantage that turning a `#[rustc_const_unstable]` into `#[rustc_const_stable]` will never change the way the function is const-checked. Currently, we often discover in the const stabilization PR that a function needs some other unstable const things, and then we rush to quickly deal with that. In this alternative universe, we'd work towards getting rid of the `rustc_const_not_exposed_on_stable` before stabilization, and once that is done stabilization becomes a trivial matter. `#[rustc_const_stable_indirect]` would then only be used for intrinsics.
I think I like this idea, but might want to do it in a follow-up PR, as it will need a whole bunch of annotations in the standard library. Also, we probably want to convert all const intrinsics to the "new" form (`#[rustc_intrinsic]` instead of an `extern` block) before doing this to avoid having to deal with two different ways of declaring intrinsics.
Cc `@rust-lang/wg-const-eval` `@rust-lang/libs-api`
Part of https://github.com/rust-lang/rust/issues/129815 (but not finished since this is not yet sufficient to safely let us expose `const fn` from hashbrown)
Fixes https://github.com/rust-lang/rust/issues/131073 by making it so that const-stable functions are always stable
try-job: test-various
|
|
This updates the "start" and "stop" methods
of the test runner to use the standalone package
server.
|
|
|
|
Rollup of 3 pull requests
Successful merges:
- #132106 (Pass Ident by reference in ast Visitor)
- #132130 (remove `change-id` from CI script)
- #132137 (library: consistently use American spelling for 'behavior')
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
This reverts commit 5af56cac38fa48e4228e5e123d060e85eb1acbf7.
|
|
|
|
Then we can rename the _raw functions to drop their suffix, and instead
explicitly use is_stable_const_fn for the few cases where that is really what
you want.
|
|
Run the full stage 2 `run-make` test suite in `x86_64-gnu-debug`
Run the full `run-make` test suite in the `x86_64-gnu-debug` CI job. This is currently the *only* CI job where `//@ needs-force-clang-based-test` will be satisfied, so some `run-make` tests will literally never be run otherwise. Before this PR, the CI job only ran `run-make` tests which contains the substring `clang` in its test name, which is both (1) a footgun because it's very easy to forget and (2) it masks tests that would otherwise fail (even failing to compile) because the test is skipped if doesn't have a `clang` in its test name.
With the environment of `x86_64-gnu-debug`, two `run-make` tests failed before this PR:
1. `tests/run-make/issue-84395-lto-embed-bitcode/rmake.rs`: this was broken for a long time because `objcopy` in llvm bin tools was renamed to `llvm-objcopy`. This test was converted into a rmake.rs test, rather straight forward.
2. `tests/run-make/cross-lang-lto-riscv-abi/rmake.rs`: this was broken for a long time and never worked. The old version inspected human-readable output of `llvm-readobj --file-header` looking for substring `EF_RISCV_FLOAT_ABI_DOUBLE`, but the human-readable output will only contain something like `Flags: 0x5, RVC, double-float ABI`, hence it will never match. This test was fixed by instead using the `object` crate to actually decode the ELF headers looking for the specific `e_flags` based on reading the RISCV ELF psABI docs.
This PR is best reviewed commit-by-commit, two commits setup the support library for functionality and two commits are for each of the failing `run-make` tests.
I had to bump the `x86_64-gnu-debug` job to be ran with a runner with larger disk space.
Part of #132034.
try-job: x86_64-gnu-debug
|
|
library: consistently use American spelling for 'behavior'
We use "behavior" a lot more often than "behaviour", but some "behaviour" have even snuck into user-facing docs. This makes the spelling consistent.
|
|
remove `change-id` from CI script
It's not necessary to set `change-id` for CI since https://github.com/rust-lang/rust/pull/130356.
|
|
Pass Ident by reference in ast Visitor
`MutVisitor`'s version of `visit_ident` passes around `&Ident`, but `Visitor` copies `Ident`. This PR changes that
r? `@petrochenkov`
related to #128974
|
|
|
|
|
|
|
|
Fundamentally, we have *three* disjoint categories of functions:
1. const-stable functions
2. private/unstable functions that are meant to be callable from const-stable functions
3. functions that can make use of unstable const features
This PR implements the following system:
- `#[rustc_const_stable]` puts functions in the first category. It may only be applied to `#[stable]` functions.
- `#[rustc_const_unstable]` by default puts functions in the third category. The new attribute `#[rustc_const_stable_indirect]` can be added to such a function to move it into the second category.
- `const fn` without a const stability marker are in the second category if they are still unstable. They automatically inherit the feature gate for regular calls, it can now also be used for const-calls.
Also, several holes in recursive const stability checking are being closed.
There's still one potential hole that is hard to avoid, which is when MIR
building automatically inserts calls to a particular function in stable
functions -- which happens in the panic machinery. Those need to *not* be
`rustc_const_unstable` (or manually get a `rustc_const_stable_indirect`) to be
sure they follow recursive const stability. But that's a fairly rare and special
case so IMO it's fine.
The net effect of this is that a `#[unstable]` or unmarked function can be
constified simply by marking it as `const fn`, and it will then be
const-callable from stable `const fn` and subject to recursive const stability
requirements. If it is publicly reachable (which implies it cannot be unmarked),
it will be const-unstable under the same feature gate. Only if the function ever
becomes `#[stable]` does it need a `#[rustc_const_unstable]` or
`#[rustc_const_stable]` marker to decide if this should also imply
const-stability.
Adding `#[rustc_const_unstable]` is only needed for (a) functions that need to
use unstable const lang features (including intrinsics), or (b) `#[stable]`
functions that are not yet intended to be const-stable. Adding
`#[rustc_const_stable]` is only needed for functions that are actually meant to
be directly callable from stable const code. `#[rustc_const_stable_indirect]` is
used to mark intrinsics as const-callable and for `#[rustc_const_unstable]`
functions that are actually called from other, exposed-on-stable `const fn`. No
other attributes are required.
|
|
Emit future-incompatibility lint when calling/declaring functions with vectors that require missing target feature
On some architectures, vector types may have a different ABI depending on whether the relevant target features are enabled. (The ABI when the feature is disabled is often not specified, but LLVM implements some de-facto ABI.)
As discussed in https://github.com/rust-lang/lang-team/issues/235, this turns out to very easily lead to unsound code.
This commit makes it a post-monomorphization error to declare or call functions using those vector types in a context in which the corresponding target features are disabled, if using an ABI for which the difference is relevant. This ensures that these functions are always called with a consistent ABI.
See the [nomination comment](https://github.com/rust-lang/rust/pull/127731#issuecomment-2288558187) for more discussion.
r? RalfJung
Part of https://github.com/rust-lang/rust/issues/116558
|
|
|
|
ci: aarch64-gnu-debug job
- Adds a new CI job which checks that the compiler builds with `--enable-debug` and tests that `needs-force-clang-based-tests` pass (where cross-language LTO is tested).
- Add a test confirming that `-Zbranch-protection=pac-ret` and cross-language LTO work together.
r? `@Mark-Simulacrum`
try-job: aarch64-gnu-debug
|
|
|
|
Signed-off-by: onur-ozkan <work@onurozkan.dev>
|
|
Rollup of 4 pull requests
Successful merges:
- #131457 (Expand `ptr::fn_addr_eq()` documentation.)
- #132085 (Update StableMIR doc to reflect current status)
- #132118 (Add support for `~const` item bounds)
- #132125 (coverage: Emit LLVM intrinsics using the normal helper method)
r? `@ghost`
`@rustbot` modify labels: rollup
|
