| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
|
|
|
|
r=fee1-dead
Remove now NOP attrs `#[rustc_dump{,_env}_program_clauses]`
Likely NOP since #113303.
r? `@fee1-dead`
|
|
|
|
r=estebank,davidtwco
Place tail expression behind terminating scope
This PR implements #123739 so that we can do further experiments in nightly.
A little rewrite has been applied to `for await` lowering. It was previously `unsafe { Pin::unchecked_new(into_async_iter(..)) }`. Under the edition 2024 rule, however, `into_async_iter` gets dropped at the end of the `unsafe` block. This presumably the first Edition 2024 migration rule goes by hoisting `into_async_iter(..)` into `match` one level above, so it now looks like the following.
```rust
match into_async_iter($iter_expr) {
ref mut iter => match unsafe { Pin::unchecked_new(iter) } {
...
}
}
```
|
|
|
|
|
|
rustc_span: Optimize more hygiene operations using `Span::map_ctxt`
I missed these in https://github.com/rust-lang/rust/pull/125017.
|
|
Introduce `{IndexNewtype,SyntaxContext}::from_u16` for convenience because small indices are sometimes encoded as `u16`.
Use `SpanData::span` instead of `Span::new` where appropriate.
Add a clarifying comment about decoding span parents.
|
|
|
|
rustc_span: Add conveniences for working with span formats
This is the refactoring part of https://github.com/rust-lang/rust/pull/125017.
|
|
Add a new concat metavar expr
Revival of #111930
Giving it another try now that #117050 was merged.
With the new rules, meta-variable expressions must be referenced with a dollar sign (`$`) and this can cause misunderstands with `$concat`.
```rust
macro_rules! foo {
( $bar:ident ) => {
const ${concat(VAR, bar)}: i32 = 1;
};
}
// Will produce `VARbar` instead of `VAR_123`
foo!(_123);
```
In other words, forgetting the dollar symbol can produce undesired outputs.
cc #29599
cc https://github.com/rust-lang/rust/issues/124225
|
|
|
|
|
|
|
|
|
|
|
|
Whilst incorrect implementations of this trait can cause miscompilation,
they cannot cause memory unsafety in rustc.
|
|
|
|
|
|
|
|
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.
|
