remove invalid `TyCompat` relation for effects
if the current impl uses `Maybe` (`impl const`), the parent impl must use `Maybe` (`impl const`) as well.
I'd like to rename `TyCompat` to `Sub` which is probably clearer. But it would conflict with my other PR.
r? ``@rust-lang/project-const-traits``
Retroactively feature gate `ConstArgKind::Path`
This puts the lowering introduced by #125915 under a feature gate until we fix the regressions introduced by it. Alternative to whole sale reverting the PR since it didn't seem like a very clean revert and I think this is generally a step in the right direction and don't want to get stuck landing and reverting the PR over and over :)
cc #129137 ``@camelid,`` tests taken from there. beta is branching soon so I think it makes sense to not try and rush that fix through since it wont have much time to bake and if it has issues we can't simply revert it on beta.
Fixes#128016
make writes_through_immutable_pointer a hard error
This turns the lint added in https://github.com/rust-lang/rust/pull/118324 into a hard error. This has been reported in cargo's future-compat reports since Rust 1.76 (released in February). Given that const_mut_refs is still unstable, it should be impossible to even hit this error on stable: we did accidentally stabilize some functions that can cause this error, but that got reverted in https://github.com/rust-lang/rust/pull/117905. Still, let's do a crater run just to be sure.
Given that this should only affect unstable code, I don't think it needs an FCP, but let's Cc ``@rust-lang/lang`` anyway -- any objection to making this unambiguous UB into a hard error during const-eval? This can be viewed as part of https://github.com/rust-lang/rust/pull/129195 which is already nominated for discussion.
By keeping track of attributes that have been previously processed.
This fixes the `macro-rules-derive-cfg.stdout` test, and is necessary
for #124141 which removes nonterminals.
Also shrink the `SmallVec` inline size used in `IntervalSet`. 2 gives
slightly better perf than 4 now that there's an `IntervalSet` in
`Parser`, which is cloned reasonably often.
Documents that `BikeshedIntrinsicFrom` models transmute-via-union,
which is slightly more expressive than the transmute-via-cast
implemented by `transmute_copy`. Additionally, we provide an
implementation of transmute-via-union as a method on the
`BikeshedIntrinsicFrom` trait with additional documentation on
the boundary between trait invariants and caller obligations.
Whether or not transmute-via-union is the right kind of transmute
to model remains up for discussion [1]. Regardless, it seems wise
to document the present behavior.
[1] https://rust-lang.zulipchat.com/#narrow/stream/216762-project-safe-transmute/topic/What.20'kind'.20of.20transmute.20to.20model.3F/near/426331967
Rollup of 9 pull requests
Successful merges:
- #128511 (Document WebAssembly target feature expectations)
- #129243 (do not build `cargo-miri` by default on stable channel)
- #129263 (Add a missing compatibility note in the 1.80.0 release notes)
- #129276 (Stabilize feature `char_indices_offset`)
- #129350 (adapt integer comparison tests for LLVM 20 IR changes)
- #129408 (Fix handling of macro arguments within the `dropping_copy_types` lint)
- #129426 (rustdoc-search: use tighter json for names and parents)
- #129437 (Fix typo in a help diagnostic)
- #129457 (kobzol vacation)
r? `@ghost`
`@rustbot` modify labels: rollup
Fix handling of macro arguments within the `dropping_copy_types` lint
This PR fixes the handling of spans with different context (aka macro arguments) than the primary expression within the different `{drop,forget}ing_copy_types` and `{drop,forget}ing_references` lints.
<details>
<summary>Before</summary>
```
warning: calls to `std::mem::drop` with a value that implements `Copy` does nothing
--> drop_writeln.rs:5:5
|
5 | drop(writeln!(&mut msg, "test"));
| ^^^^^--------------------------^
| |
| argument has type `Result<(), std::fmt::Error>`
|
= note: `#[warn(dropping_copy_types)]` on by default
help: use `let _ = ...` to ignore the expression or result
--> /home/[..]/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/macros/mod.rs:688:9
|
68| let _ =
| ~~~~~~~
```
</details>
<details>
<summary>With this PR</summary>
```
warning: calls to `std::mem::drop` with a value that implements `Copy` does nothing
--> drop_writeln.rs:5:5
|
5 | drop(writeln!(&mut msg, "test"));
| ^^^^^--------------------------^
| |
| argument has type `Result<(), std::fmt::Error>`
|
= note: `#[warn(dropping_copy_types)]` on by default
help: use `let _ = ...` to ignore the expression or result
|
5 - drop(writeln!(&mut msg, "test"));
5 + let _ = writeln!(&mut msg, "test");
|
```
</details>
``````@rustbot`````` label +L-dropping_copy_types
- Trim some unnecessary fat from the type declaration.
- Add another attribute, to make it a stronger test of `cfg_attr`
processing. Note that the current output is incorrect, because it
duplicates the added attribute. The next commit will fix this.
This example triggers an assertion failure:
```
fn f() -> u32 {
#[cfg_eval] #[cfg(not(FALSE))] 0
}
```
The sequence of events:
- `configure_annotatable` calls `parse_expr_force_collect`, which calls
`collect_tokens`.
- Within that, we end up in `parse_expr_dot_or_call`, which again calls
`collect_tokens`.
- The return value of the `f` call is the expression `0`.
- This inner call collects tokens for `0` (parser range 10..11) and
creates a replacement covering `#[cfg(not(FALSE))] 0` (parser range
0..11).
- We return to the outer `collect_tokens` call. The return value of the
`f` call is *again* the expression `0`, again with the range 10..11,
but the replacement from earlier covers the range 0..11. The code
mistakenly assumes that any attributes from an inner `collect_tokens`
call fit entirely within the body of the result of an outer
`collect_tokens` call. So it adjusts the replacement parser range
0..11 to a node range by subtracting 10, resulting in -10..1. This is
an invalid range and triggers an assertion failure.
It's tricky to follow, but basically things get complicated when an AST
node is returned from an inner `collect_tokens` call and then returned
again from an outer `collect_token` node without being wrapped in any
kind of additional layer.
This commit changes `collect_tokens` to return early in some extra cases,
avoiding the construction of lazy tokens. In the example above, the
outer `collect_tokens` returns earlier because the `0` token already has
tokens and `self.capture_state.capturing` is `Capturing::No`. This early
return avoids the creation of the invalid range and the assertion
failure.
Fixes#129166. Note: these invalid ranges have been happening for a long
time. #128725 looks like it's at fault only because it introduced the
assertion that catches the invalid ranges.
Fix extern crates not being hidden with `doc(hidden)`
Fixes#126796.
Only the current crate should never be stripped, any other crate should be strippable.
r? ``@notriddle``
Migrate `x86_64-fortanix-unknown-sgx-lvi` `run-make` test to rmake
Part of #121876 and the associated [Google Summer of Code project](https://blog.rust-lang.org/2024/05/01/gsoc-2024-selected-projects.html).
The final Makefile! Every Makefile test is now claimed.
This is difficult to test due to the uncommon architecture it is specific to. I don't think it is in the CI (I didn't find it in `jobs.yml`, but if there is a way to test it, please do.
Locally, on Linux, it compiles and panics at the `llvm_filecheck` part (if I replace the `x86_64-fortanix-unknown-sgx` with `x86_64-unknown-linux-gnu`, of course), which is expected.
For this reason, the Makefile and associated script have been kept, but with a leading underscore.
Allow rust staticlib to work with MSVC's /WHOLEARCHIVE
This fixes#129020 by renaming the `__NULL_IMPORT_DESCRIPTOR` to prevent conflicts.
try-job: dist-i686-msvc
Rollup of 8 pull requests
Successful merges:
- #128432 (WASI: forbid `unsafe_op_in_unsafe_fn` for `std::{os, sys}`)
- #129373 (Add missing module flags for CFI and KCFI sanitizers)
- #129374 (Use `assert_unsafe_precondition!` in `AsciiChar::digit_unchecked`)
- #129376 (Change `assert_unsafe_precondition` docs to refer to `check_language_ub`)
- #129382 (Add `const_cell_into_inner` to `OnceCell`)
- #129387 (Advise against removing the remaining Python scripts from `tests/run-make`)
- #129388 (Do not rely on names to find lifetimes.)
- #129395 (Pretty-print own args of existential projections (dyn-Trait w/ GAT constraints))
r? `@ghost`
`@rustbot` modify labels: rollup
Pretty-print own args of existential projections (dyn-Trait w/ GAT constraints)
Previously we would just drop them. This bug isn't that significant as it can only be triggered by user code that constrains GATs inside trait object types which is currently gated under the interim feature `generic_associated_types_extended` (whose future is questionable) or on stable if the GATs are 'disabled' in dyn-Trait via `where Self: Sized` (in which case the assoc type bindings get ignored anyway (and trigger the warn-by-default lint `unused_associated_type_bounds`)), so yeah.
Affects diagnostic output and output of `std::any::type_name{_of_val}`.
Do not rely on names to find lifetimes.
For some reason, we were trying to find the lifetime parameter from its name, instead of using the def_id we have.
This PR uses it instead. This changes some ui tests, I think to be more sensible.
Advise against removing the remaining Python scripts from `tests/run-make`
After some recent PRs (e.g. #129185), there are only two Python scripts left in `tests/run-make`.
Having come so far, it's tempting to try to get rid of the remaining ones. But after trying that myself, I've come to the conclusion that it's not worth the extra hassle, especially if it means pulling in an XML-parsing crate just for one test.
This PR therefore leaves behind a few signpost comments to explain why getting rid of these particular scripts has low value.
Add missing module flags for CFI and KCFI sanitizers
Set the cfi-normalize-integers and kcfi-offset module flags when Control-Flow Integrity sanitizers are used, so functions generated by the LLVM backend use the same CFI/KCFI options as rustc.
cfi-normalize-integers tells LLVM to also use integer normalization for generated functions when -Zsanitizer-cfi-normalize-integers is used.
kcfi-offset specifies the number of prefix nops between the KCFI type hash and the function entry when -Z patchable-function-entry is used. Note that LLVM assumes all indirectly callable functions use the same number of prefix NOPs with -Zsanitizer=kcfi.
Trying to get rid of this Python script looks tempting, because it's currently
the only Python script in the whole `run-make` suite that we actually run.
But getting rid of it would require pulling in a Rust crate to parse XML
instead, and that's probably not worth the extra hassle for a relatively-minor
test.
