| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Rollup of 5 pull requests
Successful merges:
- rust-lang/rust#147245 (only replace the intended comma in pattern suggestions)
- rust-lang/rust#147269 (Add regression test for 123953)
- rust-lang/rust#147277 (Extract common logic for iterating over features)
- rust-lang/rust#147292 (Respect `-Z` unstable options in `rustdoc --test`)
- rust-lang/rust#147300 (Add xtensa arch to object file creation)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Don't normalize higher-ranked assumptions if they're not used
See the comment in the code.
Normalizing these assumptions may cause us to register things like new placeholder outlives obligations that cause higher-ranked lifetime errors, and this is problematic if we're not even using these assumptions in borrowck.
Fixes rust-lang/rust#147244
Fixes rust-lang/rust#147285
|
|
Add regression test for 123953
close: rust-lang/rust#123953
|
|
karolzwolak:only-replace-intended-bar-not-all-in-pattern, r=lcnr
only replace the intended comma in pattern suggestions
Only suggest to replace the intended comma, not all bars in the pattern.
Fixes rust-lang/rust#143330.
This continues rust-lang/rust#143331, the credit for making the fix goes to `@A4-Tacks.` I just blessed tests and added a regression test.
|
|
Fix backtraces with `-C panic=abort` on linux; emit unwind tables by default
The linux backtrace unwinder relies on unwind tables to work properly, and generating and printing a backtrace is done by for example the default panic hook.
Begin emitting unwind tables by default again with `-C panic=abort` (see history below) so that backtraces work.
Closes https://github.com/rust-lang/rust/issues/81902 which is **regression-from-stable-to-stable**
Closes https://github.com/rust-lang/rust/issues/94815
### History
Backtraces with `-C panic=abort` used to work in Rust 1.22 but broke in Rust 1.23, because in 1.23 we stopped emitting unwind tables with `-C panic=abort` (see https://github.com/rust-lang/rust/pull/45031 and https://github.com/rust-lang/rust/issues/81902#issuecomment-3046487084).
In 1.45 a workaround in the form of `-C force-unwind-tables=yes` was added (see https://github.com/rust-lang/rust/pull/69984).
`-C panic=abort` was added in [Rust 1.10](https://blog.rust-lang.org/2016/07/07/Rust-1.10/#what-s-in-1-10-stable) and the motivation was binary size and compile time. But given how confusing that behavior has turned out to be, it is better to make binary size optimization opt-in with `-C force-unwind-tables=no` rather than default since the current default breaks backtraces.
Besides, if binary size is a primary concern, there are many other tricks that can be used that has a higher impact.
# Release Note Entry Draft:
## Compatibility Notes
* [Fix backtraces with `-C panic=abort` on Linux by generating unwind tables by default](https://github.com/rust-lang/rust/pull/143613). Build with `-C force-unwind-tables=no` to keep omitting unwind tables.
try-job: aarch64-apple
try-job: armhf-gnu
try-job: aarch64-msvc-1
|
|
|
|
Introduce debuginfo to statements in MIR
The PR introduces support for debug information within dead statements. Currently, only the reference statement is supported, which is sufficient to fix rust-lang/rust#128081.
I don't modify Stable MIR, as I don't think we need debug information when using it.
This PR represents the debug information for the dead reference statement via `#dbg_value`. For example, `let _foo_b = &foo.b` becomes `#dbg_value(ptr %foo, !22, !DIExpression(DW_OP_plus_uconst, 4, DW_OP_stack_value), !26)`. You can see this here: https://rust.godbolt.org/z/d43js6adv.
The general principle for handling debug information is to never provide less debug information than the optimized LLVM IR.
The current rules for dropping debug information in this PR are:
- If the LLVM IR cannot represent a reference address, it's replaced with poison or simply dropped. For example, see: https://rust.godbolt.org/z/shGqPec8W. I'm using poison in all such cases now.
- All debuginfos is dropped when merging multiple successor BBs. An example is available here: https://rust.godbolt.org/z/TE1q3Wq6M.
I doesn't drop debuginfos in `MatchBranchSimplification`, because LLVM also pick one branch for it.
|
|
r=saethlin
Extending `#[rustc_force_inline]` to be applicable to inherent methods
`#[rustc_force_inline]` is an internal-only attribute similar to `#[inline(always)]` but which emits an error if inlining cannot occur. rustc_force_inline uses the MIR inliner to do this and has limitations on where it can be applied to ensure that an error is always emitted if inlining can't happen (e.g. it can't be applied to trait methods because calls to those can't always be resolved).
`#[rustc_force_inline]` is motivated by AArch64 pointer authentication intrinsics where it is vital for the security properties of these intrinsics that they do not exist in standalone functions that could be used as gadgets in an exploit (if they could, then you could sign whatever pointers you want, for example, which is bad, but if you force inlining, then you can't jump to a reusable function containing only these instructions).
Since its initial implementation, `#[rustc_force_inline]` could only be applied to free functions. This can be relaxed to also allow inherent methods while still preserving the desired properties. In a work-in-progress patch for manual pointer authentication intrinsics, it is useful to introduce types with inherent methods that would need to be force inlined.
r? `@saethlin`
|
|
dyn traits
|
|
|
|
|
|
The linux backtrace unwinder relies on unwind tables to work properly,
and generating and printing a backtrace is done by for example the
default panic hook.
Begin emitting unwind tables by default again with `-C panic=abort` (see
history below) so that backtraces work.
History
=======
Backtraces with `-C panic=abort` used to work in Rust 1.22 but broke in
Rust 1.23, because in 1.23 we stopped emitting unwind tables with `-C
panic=abort` (see 24cc38e3b00).
In 1.45 (see cda994633ee) a workaround in the form
of `-C force-unwind-tables=yes` was added.
`-C panic=abort` was added in [Rust
1.10](https://blog.rust-lang.org/2016/07/07/Rust-1.10/#what-s-in-1-10-stable)
and the motivation was binary size and compile time. But given how
confusing that behavior has turned out to be, it is better to make
binary size optimization opt-in with `-C force-unwind-tables=no` rather
than default since the current default breaks backtraces.
Besides, if binary size is a primary concern, there are many other
tricks that can be used that has a higher impact.
|
|
Test: Ambigious bindings in same namespace with the same res
Add a test based on the discussion [here](https://rust-lang.zulipchat.com/#narrow/channel/421156-gsoc/topic/Project.3A.20Parallel.20Macro.20Expansion/near/542316157) and related to https://github.com/rust-lang/rust/issues/145575#issuecomment-3228868375.
This is the most reduced form I could create that passes on nightly but fails with rust-lang/rust#145108 (see [#gsoc > Project: Parallel Macro Expansion @ 💬](https://rust-lang.zulipchat.com/#narrow/channel/421156-gsoc/topic/Project.3A.20Parallel.20Macro.20Expansion/near/542335131)).
Also not sure about the test names.
r? `@petrochenkov`
|
|
Rollup of 9 pull requests
Successful merges:
- rust-lang/rust#146281 (Support `#[rustc_align_static]` inside `thread_local!`)
- rust-lang/rust#146535 (mbe: Implement `unsafe` attribute rules)
- rust-lang/rust#146585 (indexing: reword help)
- rust-lang/rust#147004 (Tweak handling of "struct like start" where a struct isn't supported)
- rust-lang/rust#147221 (Forbid `//@ compile-flags: -Cincremental=` in tests)
- rust-lang/rust#147225 (Don't enable shared memory by default with Wasm atomics)
- rust-lang/rust#147227 (implement `Box::take`)
- rust-lang/rust#147233 (Initialize llvm submodule if not already the case to run citool)
- rust-lang/rust#147236 (Update books)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
- Changes parser to allow application to inherent methods.
- Adds tests to confirm extended functionality works just as the existing.
|
|
Forbid `//@ compile-flags: -Cincremental=` in tests
Tests should not try to manually enable incremental compilation with `-Cincremental`, because that typically results in stray directories being created in the repository root.
Also, if the incremental directory is not cleared, there is a risk of interference between successive runs of the same test.
Instead, use the `//@ incremental` directive, which instructs compiletest to handle the details of passing `-Cincremental` with a fresh directory.
|
|
Tweak handling of "struct like start" where a struct isn't supported
This improves the case where someone tries to write a `match` expr where the patterns have type ascription syntax. Makes them less verbose, by giving up on the first encounter in the block, and makes them more accurate by only treating them as a struct literal if successfully parsed as such.
Before, encountering something like `match a { b:` would confuse the parser and think everything after `match` *must* be a struct, and if it wasn't it would generate a cascade of unnecessary diagnostics.
|
|
indexing: reword help
After looking at https://github.com/rust-lang/rust/issues/40850, I thought I'd try to improve wording around error E0608 a bit. Hopefully I've succeeded.
|
|
mbe: Implement `unsafe` attribute rules
This implements `unsafe attr` rules for declarative `macro_rules!` attributes, as specified in [RFC 3697](https://github.com/rust-lang/rfcs/pull/3697).
An invocation of an attribute that uses an `unsafe attr` rule requires the `unsafe(attr(...))` syntax.
An invocation of an attribute that uses an ordinary `attr` rule must *not* use the `unsafe(attr(...))` syntax.
`unsafe` is only supported on an `attr` rule, not any other kind of `macro_rules!` rule.
Tracking issue for `macro_rules!` attributes: https://github.com/rust-lang/rust/issues/143547
|
|
r=Mark-Simulacrum
Support `#[rustc_align_static]` inside `thread_local!`
Tracking issue: rust-lang/rust#146177
```rust
thread_local! {
#[rustc_align_static(64)]
static SO_ALIGNED: u64 = const { 0 };
}
```
This increases the amount of recursion the macro performs (once per attribute in addition to the previous once per item), making it easier to hit the recursion limit. I’ve added workarounds to limit the impact in the case of long doc comments, but this still needs a crater run just in case.
r? libs
``@rustbot`` label A-attributes A-macros A-thread-locals F-static_align T-libs
|
|
Split Bound index into Canonical and Bound
See [#t-types/trait-system-refactor > perf `async-closures/post-mono-higher-ranked-hang.rs`](https://rust-lang.zulipchat.com/#narrow/channel/364551-t-types.2Ftrait-system-refactor/topic/perf.20.60async-closures.2Fpost-mono-higher-ranked-hang.2Ers.60/with/541535613) for context
Things compile and tests pass, but not sure if this actually solves the perf issue (edit: it does). Opening up this to do a perf (and maybe crater) run.
r? lcnr
|
|
|
|
Tests should not try to manually enable incremental compilation with
`-Cincremental`, because that typically results in stray directories being
created in the repository root.
Instead, use the `//@ incremental` directive, which instructs compiletest to
handle the details of passing `-Cincremental` with a fresh directory.
|
|
|
|
|
|
|
|
|
|
|
|
Rollup of 8 pull requests
Successful merges:
- rust-lang/rust#146593 (Allow specifying multiple bounds for same associated item, except in trait objects)
- rust-lang/rust#147177 ([DebugInfo] Fix MSVC tuple child creation)
- rust-lang/rust#147195 (iter repeat: add tests for new count and last behavior)
- rust-lang/rust#147202 (Swap order of `resolve_coroutine_interiors` and `handle_opaque_type_uses`)
- rust-lang/rust#147204 (Refactor ArrayWindows to use a slice)
- rust-lang/rust#147219 (Add proper error handling for closure in impl)
- rust-lang/rust#147226 (include `outer_inclusive_binder` of pattern types)
- rust-lang/rust#147230 (Fix typo in 'unfulfilled_lint_expectation' to plural)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
include `outer_inclusive_binder` of pattern types
Fixes https://github.com/rust-lang/trait-system-refactor-initiative/issues/237
r? ```@lcnr```
|
|
Add proper error handling for closure in impl
Fixes https://github.com/rust-lang/rust/issues/147146
Fixes https://github.com/rust-lang/rust/issues/146620
Not sure if it can cause any regressions or anything, as for test also have no idea where to store this one
cc ```@theemathas```
r? compiler
|
|
Swap order of `resolve_coroutine_interiors` and `handle_opaque_type_uses`
r? ```@BoxyUwU```
if the comment says x should be last, it helps if it's actually last hehe :P
Fixes https://github.com/rust-lang/trait-system-refactor-initiative/issues/239
|
|
Allow specifying multiple bounds for same associated item, except in trait objects
Supersedes https://github.com/rust-lang/rust/pull/143146, fixes https://github.com/rust-lang/rust/issues/143143.
This PR proposes to stop enforcing E0719 in all contexts other than trait object types.
E0719 forbids constraining the same associated item twice within the same angle-bracket delimited associated item bound list (the `…` inside `T: Trait<…>`). For example, the following are forbidden:
| Forbidden | Working alternative |
|--------------------------------------------|--------------------------------------------------------------------|
| `T: Trait<Gat<u32> = u32, Gat<u64> = u64>` | `T: Trait<Gat<u32> = u32> + Trait<Gat<u64> = u64>` |
| `T: Iterator<Item = u32, Item = i32>` | `T: Iterator<Item = u32> + Iterator<Item = i32>` (trivially false) |
| `T: Iterator<Item = u32, Item = u32>` | `T: Iterator<Item = u32>` |
| `T: Iterator<Item: Send, Item: Sync>` | `T: Iterator<Item: Send + Sync>` |
| `T: Trait<ASSOC = 3, ASSOC = 4>` | `T: Trait<ASSOC = 3> + Trait<ASSOC = 4>` (trivially false) |
| `T: Trait<ASSOC = 3, ASSOC = 3>` | `T: Trait<ASSOC = 3>` |
With this PR, all those previously forbidden examples would start working, as well as their APIT and RPIT equivalents.
Types like `dyn Iterator<Item = u32, Item = u32>` will continue to be rejected, however. See https://github.com/rust-lang/rust/pull/143146#issuecomment-3274421752 for the reason why.
```@rustbot``` label T-lang T-types needs-fcp
|
|
|
|
|
|
|
|
Don't create a top-level `true` directory when running UI tests
The funny thing about writing `-Cincremental=true` is that it *does* enable incremental compilation ... using an incremental compilation dir of `./true`.
And for UI tests, that ends up creating a `true` directory in the repository root, which is annoying.
Fortunately, compiletest has an existing `//@ incremental` directive that takes care of creating an empty incremental directory, and passing it to `-Cincremental`.
---
I have manually checked that reverting rust-lang/rust#146649 still causes the updated test to fail.
|
|
Remove `no-remap-src-base` from tests
Previously in the `//`-compiletest-directive times, `no-remap-src-base` was implemented as a special `no-*` directive parsing. In the migration from `//` -> `//`@`,` the `// no-remap-src-base` directive was lost, most likely because it had no effect -- the default is not remapping `src-base`.
So remove occurrences of `no-remap-src-base`, as these are not valid directives.
r? `@Zalathar` (since we discussed this on discord, or compiler)
|
|
add tests
fixes https://github.com/rust-lang/trait-system-refactor-initiative/issues/105
the index test is for rust-lang/rust#146637
r? types
|
|
add regression test
closes rust-lang/rust#128887
the errors in that issue are due to two separate issues:
- MIR inlining causing the trait solver to hit the recursion limit (partially fixed in rust-lang/rust#129714)
- using subtyping in method selection for paths (fixed in https://github.com/rust-lang/rust/pull/129073)
We moved any remaining issues due to MIR inlining into https://github.com/rust-lang/rust/issues/131960, but keeping rust-lang/rust#128887 open as well seems unhelpful and confusing.
|
|
|
|
Co-authored-by: beef <ent3rm4n@gmail.com>
|
|
Previously in the `//`-compiletest-directive times, this was implemented
as a special `no-*` directive parsing. In the migration from `//` ->
`//@`, the `// no-remap-src-base` directive was lost, most likely
because it had no effect -- the default is not remapping `src-base`.
So remove occurrences of `no-remap-src-base`, as these are not valid
directives.
|
|
Rollup of 6 pull requests
Successful merges:
- rust-lang/rust#143069 (Add fast-path for accessing the current thread id)
- rust-lang/rust#146518 (Improve the documentation around `ZERO_AR_DATE`)
- rust-lang/rust#146596 (Add a dummy codegen backend)
- rust-lang/rust#146617 (Don’t suggest foreign `doc(hidden)` types in "the following other types implement trait" diagnostics)
- rust-lang/rust#146635 (cg_llvm: Stop using `as_c_char_ptr` for coverage-related bindings)
- rust-lang/rust#147184 (Fix the bevy implied bounds hack for the next solver)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
|
|
|
|
Fix the bevy implied bounds hack for the next solver
The diff is trivial, of course, and basically what you already suggested. Mostly dug around a bunch to learn. I hope this is roughly what you had in mind.
Fixes https://github.com/rust-lang/trait-system-refactor-initiative/issues/236.
r? `@lcnr`
|
|
Don’t suggest foreign `doc(hidden)` types in "the following other types implement trait" diagnostics
Fixes https://github.com/rust-lang/rust/issues/132024.
``@rustbot`` label A-diagnostics T-compiler
|
|
remove unnecessary test directives
that's... odd
|
|
|
