| Age | Commit message (Collapse) | Author | Lines |
|---|
|
CastilloDel:reject-unstable-with-accepted-features, r=jieyouxu
Emit an error for unstable attributes that reference already stable features
Closes https://github.com/rust-lang/rust/issues/129814
|
|
Don't assume traits used as type are trait objs in 2021 edition
Fixes #127548
When you use a trait as a type, the compiler automatically assumes you meant to use a trait object, which is not always the case.
This PR fixes the bug where you don't need a trait object, so the error message was changed to:
```
error[E0782]: expected a type, found a trait
```
Also fixes some ICEs:
Fixes https://github.com/rust-lang/rust/issues/120241
Fixes https://github.com/rust-lang/rust/issues/120482
Fixes https://github.com/rust-lang/rust/issues/125512
|
|
Check ABI target compatibility for function pointers
Tracking issue: https://github.com/rust-lang/rust/issues/130260
Related tracking issue: #87678
Compatibility of an ABI for a target was previously only performed on function definitions and `extern` blocks. This PR adds it also to function pointers to be consistent.
This might have broken some of the `tests/ui/` depending on the platform, so a try run seems like a good idea.
Also this might break existing code, because we now emit extra errors. Does this require a crater run?
# Example
```rust
// build with: --target=x86_64-unknown-linux-gnu
// These raise E0570
extern "thiscall" fn foo() {}
extern "thiscall" { fn bar() }
// This did not raise any error
fn baz(f: extern "thiscall" fn()) { f() }
```
# Open Questions
* [x] Should this report a future incompatibility warning like #87678 ?
* [ ] Is this the best place to perform the check?
|
|
std: fix stdout-before-main
Fixes #130210.
Since #124881, `ReentrantLock` uses `ThreadId` to identify threads. This has the unfortunate consequence of breaking uses of `Stdout` before main: Locking the `ReentrantLock` that synchronizes the output will initialize the thread ID before the handle for the main thread is set in `rt::init`. But since that would overwrite the current thread ID, `thread::set_current` triggers an abort.
This PR fixes the problem by using the already initialized thread ID for constructing the main thread handle and allowing `set_current` calls that do not change the thread's ID.
|
|
Stabilize const `ptr::write*` and `mem::replace`
Since `const_mut_refs` and `const_refs_to_cell` have been stabilized, we may now also stabilize the ability to write to places during const evaluation inside our library API. So, we now propose the `const fn` version of `ptr::write` and its variants. This allows us to also stabilize `mem::replace` and `ptr::replace`.
- const `mem::replace`: https://github.com/rust-lang/rust/issues/83164#issuecomment-2338660862
- const `ptr::write{,_bytes,_unaligned}`: https://github.com/rust-lang/rust/issues/86302#issuecomment-2330275266
Their implementation requires an additional internal stabilization of `const_intrinsic_forget`, which is required for `*::write*` and thus `*::replace`. Thus we const-stabilize the internal intrinsics `forget`, `write_bytes`, and `write_via_move`.
|
|
Add suggestion for removing invalid path sep `::` in fn def
Add suggestion for removing invalid path separator `::` in function definition.
for example: `fn invalid_path_separator::<T>() {}`
fixes #130791
|
|
Fixes #130210.
Since #124881, `ReentrantLock` uses `ThreadId` to identify threads. This has the unfortunate consequence of breaking uses of `Stdout` before main: Locking the `ReentrantLock` that synchronizes the output will initialize the thread ID before the handle for the main thread is set in `rt::init`. But since that would overwrite the current thread ID, `thread::set_current` triggers an abort.
This PR fixes the problem by using the already initialized thread ID for constructing the main thread handle and allowing `set_current` calls that do not change the thread's ID.
|
|
Add missing error annotations and .stderr file
Acknowledge comments
|
|
Const-stabilizes:
- `write`
- `write_bytes`
- `write_unaligned`
In the following paths:
- `core::ptr`
- `core::ptr::NonNull`
- pointer `<*mut T>`
Const-stabilizes the internal `core::intrinsics`:
- `write_bytes`
- `write_via_move`
|
|
Remove deprecation note in the `non_local_definitions` lint
This PR removes the edition deprecation note emitted by the `non_local_definitions` lint.
Specifically this part:
```
= note: this lint may become deny-by-default in the edition 2024 and higher, see the tracking issue <https://github.com/rust-lang/rust/issues/120363>
```
because it [didn't make the cut](https://github.com/rust-lang/rust/issues/120363#issuecomment-2407833300) for the 2024 edition.
`@rustbot` label +L-non_local_definitions
|
|
Make unused_parens's suggestion considering expr's attributes.
For the expr with attributes,
like `let _ = (#[inline] || println!("Hello!"));`,
the suggestion's span should contains the attributes, or the suggestion will remove them.
fixes #129833
|
|
Support clobber_abi in MSP430 inline assembly
This supports `clobber_abi` which is one of the requirements of stabilization mentioned in #93335.
Refs: Section 3.2 "Register Conventions" in [MSP430 Embedded Application Binary Interface](https://www.ti.com/lit/an/slaa534a/slaa534a.pdf)
cc ``@cr1901``
r? ``@Amanieu``
``@rustbot`` label +O-msp430
|
|
For the expr with attributes, like `let _ = (#[inline] || println!("Hello!"));`, the suggestion's span should contains the attributes, or the suggestion will remove them.
fixes #129833
|
|
Add intrinsics `fmuladd{f16,f32,f64,f128}`. This computes `(a * b) +
c`, to be fused if the code generator determines that (i) the target
instruction set has support for a fused operation, and (ii) that the
fused operation is more efficient than the equivalent, separate pair
of `mul` and `add` instructions.
https://llvm.org/docs/LangRef.html#llvm-fmuladd-intrinsic
MIRI support is included for f32 and f64.
The codegen_cranelift uses the `fma` function from libc, which is a
correct implementation, but without the desired performance semantic. I
think this requires an update to cranelift to expose a suitable
instruction in its IR.
I have not tested with codegen_gcc, but it should behave the same
way (using `fma` from libc).
|
|
|
|
Rollup of 6 pull requests
Successful merges:
- #129079 (Create `_imp__` symbols also when doing ThinLTO)
- #131208 (ABI: Pass aggregates by value on AIX)
- #131394 (fix(rustdoc): add space between struct fields and their descriptions)
- #131519 (Use Default visibility for rustc-generated C symbol declarations)
- #131541 (compiletest: Extract auxiliary-crate properties to their own module/struct)
- #131542 (next-solver: remove outdated FIXMEs)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
|
|
Use Default visibility for rustc-generated C symbol declarations
Non-default visibilities should only be used for definitions, not declarations, otherwise linking can fail.
This is based on https://github.com/rust-lang/rust/pull/123994.
Issue https://github.com/rust-lang/rust/issues/123427
When I changed `default-hidden-visibility` to `default-visibility` in https://github.com/rust-lang/rust/pull/130005, I updated all places in the code that used `default-hidden-visibility`, replicating the hidden-visibility bug to also happen for protected visibility.
Without this change, trying to build rustc with `-Z default-visibility=protected` fails with a link error.
|
|
ABI: Pass aggregates by value on AIX
On AIX we pass aggregates byval. Adds new ABI for AIX for powerpc64.
https://github.com/llvm/llvm-project/blob/313ad85dfa40a18f2edefd7ce2edc0528d5a554a/clang/lib/CodeGen/Targets/PPC.cpp#L216
Fixes the following 2 testcases on AIX:
```
tests/ui/abi/extern/extern-pass-TwoU16s.rs
tests/ui/abi/extern/extern-pass-TwoU8s.rs
```
|
|
Create `_imp__` symbols also when doing ThinLTO
When generating a rlib crate on Windows we create `dllimport` / `_imp__` symbols for each global. This effectively makes the rlib contain an import library for itself and allows them to both be dynamically and statically linked. However when doing ThinLTO we do not generate these and thus we end up with missing symbols. Microsoft's `link` can fix these up (and emits warnings), but `lld` seems to currently be unable to.
This PR also does this generation for ThinLTO avoiding those issues with `lld` and also avoids the warnings on `link`.
This is an workaround for https://github.com/rust-lang/rust/issues/81408.
cc `@lqd`
|
|
Retire the `unnamed_fields` feature for now
`#![feature(unnamed_fields)]` was implemented in part in #115131 and #115367, however work on that feature has (afaict) stalled and in the mean time there have been some concerns raised (e.g.[^1][^2]) about whether `unnamed_fields` is worthwhile to have in the language, especially in its current desugaring. Because it represents a compiler implementation burden including a new kind of anonymous ADT and additional complication to field selection, and is quite prone to bugs today, I'm choosing to remove the feature.
However, since I'm not one to really write a bunch of words, I'm specifically *not* going to de-RFC this feature. This PR essentially *rolls back* the state of this feature to "RFC accepted but not yet implemented"; however if anyone wants to formally unapprove the RFC from the t-lang side, then please be my guest. I'm just not totally willing to summarize the various language-facing reasons for why this feature is or is not worthwhile, since I'm coming from the compiler side mostly.
Fixes #117942
Fixes #121161
Fixes #121263
Fixes #121299
Fixes #121722
Fixes #121799
Fixes #126969
Fixes #131041
Tracking:
* https://github.com/rust-lang/rust/issues/49804
[^1]: https://rust-lang.zulipchat.com/#narrow/stream/213817-t-lang/topic/Unnamed.20struct.2Funion.20fields
[^2]: https://github.com/rust-lang/rust/issues/49804#issuecomment-1972619108
|
|
Consider outermost const-anon in `non_local_def` lint
This PR change the logic for finding the parent of the `impl` definition in the `non_local_definitions` lint to consider multiple level of const-anon items, instead of only one currently.
I also took the opportunity to cleanup the related code.
cc ``@traviscross``
Fixes https://github.com/rust-lang/rust/issues/131474
|
|
When making changes that have a large impact on coverage counter creation, this
makes it easier to see whether the number of physical counters has changed.
(The highest counter ID seen in coverage maps is not necessarily the same as
the number of physical counters actually used by the instrumented code, but
it's the best approximation we can get from looking only at the coverage maps,
and it should be reasonably accurate in most cases.)
|
|
|
|
compiletest: Remove the magic hacks for finding output with `lto=thin`
This hack was intended to handle the case where `-Clto=thin` causes the compiler to emit multiple output files (when producing LLVM-IR or assembly).
The hack only affects 4 tests, of which 3 are just meta-tests for the hack itself. The one remaining test that motivated the hack currently doesn't even need it!
(`tests/codegen/issues/issue-81408-dllimport-thinlto-windows.rs`)
|
|
rustdoc-json: Add tests for unsafe/safe extern blocks (RFC 3484)
Closes https://github.com/rust-lang/rust/issues/126786, turns out this all Just Works (TM)
Tracking issue: #123743
r? `@GuillaumeGomez`
|
|
This hack was intended to handle the case where `-Clto=thin` causes the
compiler to emit multiple output files (when producing LLVM-IR or assembly).
The hack only affects 4 tests, of which 3 are just meta-tests for the hack
itself. The one remaining test that motivated the hack currently doesn't even
need it!
(`tests/codegen/issues/issue-81408-dllimport-thinlto-windows.rs`)
|
|
Non-default visibilities should only be used for definitions, not
declarations, otherwise linking can fail.
Co-authored-by: Collin Baker <collinbaker@chromium.org>
|
|
|
|
Compiler & its UI tests: Rename remaining occurrences of "object safe" to "dyn compatible"
Follow-up to #130826.
Part of #130852.
1. 1st commit: Fix stupid oversights. Should've been part of #130826.
2. 2nd commit: Rename the unstable feature `object_safe_for_dispatch` to `dyn_compatible_for_dispatch`. Might not be worth the churn, you decide.
3. 3rd commit: Apply the renaming to all UI tests (contents and paths).
|
|
r=spastorino
Precise capturing in traits
This PR begins to implement `feature(precise_capturing_in_traits)`, which enables using the `impl Trait + use<..>` syntax for RPITITs. It implements this by giving the desugared GATs variance, and representing the uncaptured lifetimes as bivariant, like how opaque captures work.
Right now, I've left out implementing a necessary extension to the `refining_impl_trait` lint, and also I've made it so that all RPITITs always capture the parameters that come from the trait, because I'm not totally yet convinced that it's sound to not capture these args. It's certainly required to capture the type and const parameters from the trait (e.g. Self), or else users could bivariantly relate two RPITIT args that come from different impls, but region parameters don't affect trait selection in the same way, so it *may* be possible to relax this in the future. Let's stay conservative for now, though.
I'm not totally sure what tests could be added on top of the ones I already added, since we really don't need to exercise the `precise_capturing` feature but simply what makes it special for RPITITs.
r? types
Tracking issue:
* #130044
|
|
rustc_target: Add sme-b16b16 as an explicit aarch64 target feature
LLVM 20 split out what used to be called b16b16 and correspond to aarch64
FEAT_SVE_B16B16 into sve-b16b16 and sme-b16b16.
Add sme-b16b16 as an explicit feature and update the codegen accordingly.
Resolves https://github.com/rust-lang/rust/pull/129894.
|
|
codegen_ssa: consolidate tied target checks
Fixes #105110.
Fixes #105111.
`rustc_codegen_llvm` and `rustc_codegen_gcc` duplicated logic for checking if tied target features were partially enabled. This PR consolidates these checks into `rustc_codegen_ssa` in the `codegen_fn_attrs` query, which also is run pre-monomorphisation for each function, which ensures that this check is run for unused functions, as would be expected.
Also adds a test confirming that enabling one tied feature doesn't imply another - the appropriate error for this was already being emitted. I did a bisect and narrowed it down to two patches it was likely to be - something in #128796, probably #128221 or #128679.
|
|
|
|
|
|
|
|
Introduce SolverRelating type relation to the new solver
Redux of #128744.
Splits out relate for the new solver so that implementors don't need to implement it themselves.
r? lcnr
|
|
impossible obligations fast path
fixes the remaining performance regression in nalgebra for #130654
r? `@compiler-errors`
Fixes #124894
|
|
structurally resolve adts and tuples expectations too
r? lcnr
|
|
fix/update teach_note from 'escaping mutable ref/ptr' const-check
The old note was quite confusing since it talked about statics, but the message is also shown for consts. So let's reword to something that is true for both of them.
|
|
LLVM 20 split out what used to be called b16b16 and correspond to aarch64
FEAT_SVE_B16B16 into sve-b16b16 and sme-b16b16.
Add sme-b16b16 as an explicit feature and update the codegen accordingly.
|
|
|
|
|
|
|
|
Rollup of 7 pull requests
Successful merges:
- #123951 (Reserve guarded string literals (RFC 3593))
- #130827 (Library: Rename "object safe" to "dyn compatible")
- #131383 (Add docs about slicing slices at the ends)
- #131403 (Fix needless_lifetimes in rustc_serialize)
- #131417 (Fix methods alignment on mobile)
- #131449 (Decouple WASIp2 sockets from WasiFd)
- #131462 (Mention allocation errors for `open_buffered`)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
|
|
|
|
Fix methods alignment on mobile
I realized that on mobile, the methods are not aligned the same depending if they have documentation or not:
| before | after |
|-|-|
|  |  |
r? `@notriddle`
|
|
Reserve guarded string literals (RFC 3593)
Implementation for RFC 3593, including:
- lexer / parser changes
- diagnostics
- migration lint
- tests
We reserve `#"`, `##"`, `###"`, `####`, and any other string of four or more repeated `#`. This avoids infinite lookahead in the lexer, though we still use infinite lookahead in the parser to provide better forward compatibility diagnostics.
This PR does not implement any special lexing of the string internals:
- strings preceded by one or more `#` are denied
- regardless of the number of trailing `#`
- string contents are lexed as if it was just a bare `"string"`
Tracking issue: #123735
RFC: rust-lang/rfcs#3593
|
|
|
