| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
|
|
Unsafe extern blocks
This implements RFC 3484.
Tracking issue #123743 and RFC https://github.com/rust-lang/rfcs/pull/3484
This is better reviewed commit by commit.
|
|
coverage: Carve out hole spans in a separate early pass
When extracting spans from MIR for use in coverage instrumentation, we sometimes need to identify *hole spans* (currently just closures), and carve up the other spans so that they don't overlap with holes.
This PR simplifies the main coverage-span-refiner by extracting the hole-carving process into a separate early pass. That pass produces a series of independent buckets, and we run the span-refiner on each bucket separately.
There is almost no difference in the resulting mappings, other than in some edge cases involving macros.
|
|
|
|
|
|
This is the counterpart of `Span::trim_start`.
|
|
|
|
|
|
Implement `needs_async_drop` in rustc and optimize async drop glue
This PR expands on #121801 and implements `Ty::needs_async_drop` which works almost exactly the same as `Ty::needs_drop`, which is needed for #123948.
Also made compiler's async drop code to look more like compiler's regular drop code, which enabled me to write an optimization where types which do not use `AsyncDrop` can simply forward async drop glue to `drop_in_place`. This made size of the async block from the [async_drop test](https://github.com/zetanumbers/rust/blob/67980dd6fb11917d23d01a19c2cf4cfc3978aac8/tests/ui/async-await/async-drop.rs) to decrease by 12%.
|
|
Make `std::env::{set_var, remove_var}` unsafe in edition 2024
Allow calling these functions without `unsafe` blocks in editions up until 2021, but don't trigger the `unused_unsafe` lint for `unsafe` blocks containing these functions.
Fixes #27970.
Fixes #90308.
CC #124866.
|
|
Allow calling these functions without `unsafe` blocks in editions up
until 2021, but don't trigger the `unused_unsafe` lint for `unsafe`
blocks containing these functions.
Fixes #27970.
Fixes #90308.
CC #124866.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Because explicit macro imports are better than implicit macro imports.
|
|
For something that wasn't obvious to me.
|
|
Rollup of 7 pull requests
Successful merges:
- #124570 (Miscellaneous cleanups)
- #124772 (Refactor documentation for Apple targets)
- #125011 (Add opt-for-size core lib feature flag)
- #125218 (Migrate `run-make/no-intermediate-extras` to new `rmake.rs`)
- #125225 (Use functions from `crt_externs.h` on iOS/tvOS/watchOS/visionOS)
- #125266 (compiler: add simd_ctpop intrinsic)
- #125348 (Small fixes to `std::path::absolute` docs)
Failed merges:
- #125296 (Fix `unexpected_cfgs` lint on std)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
compiler: add simd_ctpop intrinsic
Fairly straightforward addition.
cc `@rust-lang/opsem` new (extremely boring) intrinsic
|
|
|
|
r=pnkfelix
Add an experimental feature gate for global registration
See #125119 for the tracking issue.
|
|
|
|
|
|
This commit adds a new nonterminal `expr_2021` in macro patterns, and
`expr_fragment_specifier_2024` feature flag. For now, `expr` and
`expr_2021` are treated the same, but in future PRs we will update
`expr` to match to new grammar.
Co-authored-by: Vincezo Palazzo <vincenzopalazzodev@gmail.com>
|
|
Support Result<T, E> across FFI when niche optimization can be used (v2)
This PR is identical to #122253, which was approved and merged but then removed from master by a force-push due to a [CI bug](https://rust-lang.zulipchat.com/#narrow/stream/242791-t-infra/topic/ci.20broken.3F).
r? ghost
Original PR description:
---
Allow allow enums like `Result<T, E>` to be used across FFI if the T/E can be niche optimized and the non-niche-optimized type is FFI safe.
Implementation of https://github.com/rust-lang/rfcs/pull/3391
Tracking issue: https://github.com/rust-lang/rust/issues/110503
Additional ABI and codegen tests were added in https://github.com/rust-lang/rust/pull/115372
|
|
Change `SIGPIPE` ui from `#[unix_sigpipe = "..."]` to `-Zon-broken-pipe=...`
In the stabilization [attempt](https://github.com/rust-lang/rust/pull/120832) of `#[unix_sigpipe = "sig_dfl"]`, a concern was [raised ](https://github.com/rust-lang/rust/pull/120832#issuecomment-2007394609) related to using a language attribute for the feature: Long term, we want `fn lang_start()` to be definable by any crate, not just libstd. Having a special language attribute in that case becomes awkward.
So as a first step towards the next stabilization attempt, this PR changes the `#[unix_sigpipe = "..."]` attribute to a compiler flag `-Zon-broken-pipe=...` to remove that concern, since now the language is not "contaminated" by this feature.
Another point was [also raised](https://github.com/rust-lang/rust/pull/120832#issuecomment-1987023484), namely that the ui should not leak **how** it does things, but rather what the **end effect** is. The new flag uses the proposed naming. This is of course something that can be iterated on further before stabilization.
Tracking issue: https://github.com/rust-lang/rust/issues/97889
|
|
In the stabilization attempt of `#[unix_sigpipe = "sig_dfl"]`, a concern
was raised related to using a language attribute for the feature: Long
term, we want `fn lang_start()` to be definable by any crate, not just
libstd. Having a special language attribute in that case becomes
awkward.
So as a first step towards towards the next stabilization attempt, this
PR changes the `#[unix_sigpipe = "..."]` attribute to a compiler flag
`-Zon-broken-pipe=...` to remove that concern, since now the language
is not "contaminated" by this feature.
Another point was also raised, namely that the ui should not leak
**how** it does things, but rather what the **end effect** is. The new
flag uses the proposed naming. This is of course something that can be
iterated on further before stabilization.
|
|
Add diagnostic item for `std::iter::Iterator::enumerate`
Adds a diagnostic item for the `std::iter:Iterator::enumerate` trait method. This change, along with PR https://github.com/rust-lang/rust/pull/124308, will be used by the clippy `unused_enumerate_index` lint to move away from paths to using diagnostic items.
see: https://github.com/rust-lang/rust-clippy/issues/5393
|
|
|
|
|
|
`#[collapse_debuginfo]`
`-Z debug-macros` is "stabilized" by enabling it by default and removing.
`-Z collapse-macro-debuginfo` is stabilized as `-C collapse-macro-debuginfo`.
It now supports all typical boolean values (`parse_opt_bool`) in addition to just yes/no.
Default value of `collapse_debuginfo` was changed from `false` to `external` (i.e. collapsed if external, not collapsed if local).
`#[collapse_debuginfo]` attribute without a value is no longer supported to avoid guessing the default.
|
|
chore: fix some typos in comments
|
|
Signed-off-by: whosehang <whosehang@outlook.com>
|
|
|
|
|
|
Do `check_coroutine_obligations` once per typeck root
We only need to do `check_coroutine_obligations` once per typeck root, especially since the new solver can't really (easily) associate which obligations correspond to which coroutines.
This requires us to move the checks for sized coroutine fields into `mir_coroutine_witnesses`, but that's fine imo.
r? lcnr
|
|
panic_str only exists for the migration to 2021 panic macros
The only caller is `expect_failed`, which is already a cold inline(never) function, so inlining into that function should be fine. (And indeed `panic_str` was `#[inline]` anyway.)
The existence of panic_str risks someone calling it when they should call `panic` instead, and I can't see a reason why this footgun should exist.
I also extended the comment in `panic` to explain why it needs a `'static` string -- I know I've wondered about this in the past and it took me quite a while to understand.
|
|
Add simple async drop glue generation
This is a prototype of the async drop glue generation for some simple types. Async drop glue is intended to behave very similar to the regular drop glue except for being asynchronous. Currently it does not execute synchronous drops but only calls user implementations of `AsyncDrop::async_drop` associative function and awaits the returned future. It is not complete as it only recurses into arrays, slices, tuples, and structs and does not have same sensible restrictions as the old `Drop` trait implementation like having the same bounds as the type definition, while code assumes their existence (requires a future work).
This current design uses a workaround as it does not create any custom async destructor state machine types for ADTs, but instead uses types defined in the std library called future combinators (deferred_async_drop, chain, ready_unit).
Also I recommend reading my [explainer](https://zetanumbers.github.io/book/async-drop-design.html).
This is a part of the [MCP: Low level components for async drop](https://github.com/rust-lang/compiler-team/issues/727) work.
Feature completeness:
- [x] `AsyncDrop` trait
- [ ] `async_drop_in_place_raw`/async drop glue generation support for
- [x] Trivially destructible types (integers, bools, floats, string slices, pointers, references, etc.)
- [x] Arrays and slices (array pointer is unsized into slice pointer)
- [x] ADTs (enums, structs, unions)
- [x] tuple-like types (tuples, closures)
- [ ] Dynamic types (`dyn Trait`, see explainer's [proposed design](https://github.com/zetanumbers/posts/blob/main/async-drop-design.md#async-drop-glue-for-dyn-trait))
- [ ] coroutines (https://github.com/rust-lang/rust/pull/123948)
- [x] Async drop glue includes sync drop glue code
- [x] Cleanup branch generation for `async_drop_in_place_raw`
- [ ] Union rejects non-trivially async destructible fields
- [ ] `AsyncDrop` implementation requires same bounds as type definition
- [ ] Skip trivially destructible fields (optimization)
- [ ] New [`TyKind::AdtAsyncDestructor`](https://github.com/zetanumbers/posts/blob/main/async-drop-design.md#adt-async-destructor-types) and get rid of combinators
- [ ] [Synchronously undroppable types](https://github.com/zetanumbers/posts/blob/main/async-drop-design.md#exclusively-async-drop)
- [ ] Automatic async drop at the end of the scope in async context
|
|
|
|
|
|
r=Nadrieril
Match ergonomics 2024: Implement eat-one-layer
r? `@Nadrieril`
cc #123076
`@rustbot` label A-edition-2024 A-patterns
|
|
Move `SourceMap` initialization
So it happens at the same time as `SessionGlobals` initialization, rather than shortly afterward.
r? `@WaffleLapkin`
|
|
Explainer: https://zetanumbers.github.io/book/async-drop-design.html
https://github.com/rust-lang/rust/pull/121801
|
|
r=Nadrieril
Match ergonomics 2024: `mut` doesn't reset binding mode
r? ``@Nadrieril``
cc https://github.com/rust-lang/rust/issues/123076
``@rustbot`` label A-edition-2024 A-patterns
|
|
|
|
|
|
|
