| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Selectively disable sanitizer instrumentation
Add `no_sanitize` attribute that allows to opt out from sanitizer
instrumentation in an annotated function.
|
|
Generator Resume Arguments
cc https://github.com/rust-lang/rust/issues/43122 and https://github.com/rust-lang/rust/issues/56974
Blockers:
* [x] Fix miscompilation when resume argument is live across a yield point (https://github.com/rust-lang/rust/pull/68524#issuecomment-578459069)
* [x] Fix 10% compile time regression in `await-call-tree` benchmarks (https://github.com/rust-lang/rust/pull/68524#issuecomment-578487162)
* [x] Fix remaining 1-3% regression (https://github.com/rust-lang/rust/pull/68524#issuecomment-579566255) - resolved (https://github.com/rust-lang/rust/pull/68524#issuecomment-581144901)
* [x] Make dropck rules account for resume arguments (https://github.com/rust-lang/rust/pull/68524#issuecomment-578541137)
Follow-up work:
* Change async/await desugaring to make use of this feature
* Rewrite [`box_region.rs`](https://github.com/rust-lang/rust/blob/3d8778d767f0dde6fe2bc9459f21ead8e124d8cb/src/librustc_data_structures/box_region.rs) to use resume arguments (this shows up in profiles too)
|
|
|
|
|
|
|
|
|
|
Forbid using `0` as issue number
Fixes #67496
r? @Centril
|
|
stop using BytePos for computing spans in librustc_parse/parser/mod.rs
Computing spans using logic such as `self.token.span.lo() + BytePos(1)` can cause internal compiler errors like #68730 when non-ascii characters are given as input.
#68735 partially addressed this problem, but only for one case. Moreover, its usage of `next_point()` does not actually align with what `bump_with()` expects. For example, given the token `>>=`, we should pass the span consisting of the final two characters `>=`, but `next_point()` advances the span beyond the end of the `=`.
This pull request instead computes the start of the new span by doing `start_point(self.token.span).hi()`. This matches `self.token.span.lo() + BytePos(1)` in the common case where the characters are ascii, and it gracefully handles multibyte characters.
Fixes #68783.
|
|
use def_path_str for missing_debug_impls message
The lint message will now use the full, correct path to the `Debug`
trait, even in `no_std`.
|
|
or_patterns: add regression test for #68785
Fixes https://github.com/rust-lang/rust/issues/68785.
(Fixed by https://github.com/rust-lang/rust/pull/67668.)
cc https://github.com/rust-lang/rust/issues/54883
r? @estebank
|
|
Towards unified `fn` grammar
Part of https://github.com/rust-lang/rust/pull/68728.
- Syntactically, `fn` items in `extern { ... }` blocks can now have bodies (`fn foo() { ... }` as opposed to `fn foo();`). As above, we use semantic restrictions instead.
- Syntactically, `fn` items in free contexts (directly in a file or a module) can now be without bodies (`fn foo();` as opposed to `fn foo() { ... }`. As above, we use semantic restrictions instead, including for non-ident parameter patterns.
- We move towards unifying the `fn` front matter; this is fully realized in https://github.com/rust-lang/rust/pull/68728.
r? @petrochenkov
|
|
Implement `unused_parens` for `const` and `static` items
Fixes #67942
|
|
It does not have unwinding support
|
|
|
|
Account for HR lifetimes when suggesting introduction of named lifetime
```
error[E0106]: missing lifetime specifier
--> src/test/ui/suggestions/fn-missing-lifetime-in-item.rs:2:32
|
2 | struct S2<F: Fn(&i32, &i32) -> &i32>(F);
| ---- ---- ^ expected named lifetime parameter
|
= help: this function's return type contains a borrowed value, but the signature does not say whether it is borrowed from argument 1 or argument 2
= note: for more information on higher-ranked polymorphism, visit https://doc.rust-lang.org/nomicon/hrtb.html
help: consider making the bound lifetime-generic with a new `'a` lifetime
|
2 | struct S2<F: for<'a> Fn(&'a i32, &'a i32) -> &'a i32>(F);
| ^^^^^^^ ^^^^^^^ ^^^^^^^ ^^^
help: consider introducing a named lifetime parameter
|
2 | struct S2<'a, F: Fn(&'a i32, &'a i32) -> &'a i32>(F);=
| ^^^ ^^^^^^^ ^^^^^^^ ^^^
```
Follow up to #68267. Addresses the diagnostics part of #49287.
|
|
|
|
Add `no_sanitize` attribute that allows to opt out from sanitizer
instrumentation in an annotated function.
|
|
|
|
Address #49287
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
On suggesting `#![recursion_limit = "X"]`, note current crate name
This would have saved me much confusion e.g. when reading the log output in https://github.com/rust-lang/rust/pull/68788#issuecomment-581852191.
r? @estebank
|
|
Make more arithmetic functions unstably const
This is a smaller version of #66884 (thanks @9999years) that constifies many of the arithmetic functions on integer primitives from #53718 that were blocked on #49146.
This makes the following things unstably const.
- `feature = const_int_unchecked_arith`
- `intrinsics::unchecked_add`
- `intrinsics::unchecked_sub`
- `intrinsics::unchecked_mul`
- `intrinsics::unchecked_div`
- `intrinsics::unchecked_rem`
- `feature = const_checked_int_methods`
- `checked_add`
- `checked_sub`
- `checked_mul`
- `checked_div` (Uses `intrinsics::unchecked_div` internally)
- `checked_rem` (Uses `intrinsics::unchecked_rem` internally)
- `checked_neg`
- `checked_shl`
- `checked_shr`
- `checked_abs`
- `feature = const_saturating_int_methods`
- `saturating_mul`
- `saturating_neg` (Uses `intrinsics::unchecked_sub` internally)
- `saturating_abs` (Uses `intrinsics::unchecked_sub` internally)
- `feature = const_wrapping_int_methods`
- `wrapping_div`
- `wrapping_rem`
- `feature = const_overflowing_int_methods`
- `overflowing_div`
- `overflowing_rem`
- `feature = const_euclidean_int_methods`
- `checked_div_euclid`
- `checked_rem_euclid`
- `wrapping_div_euclid`
- `wrapping_rem_euclid`
- `overflowing_div_euclid`
- `overflowing_rem_euclid`
Exponentiation and operations on the `NonZero` types are left to a later PR.
r? @oli-obk
cc @rust-lang/wg-const-eval @rust-lang/libs
|
|
|
|
|
|
|
|
Rollup of 7 pull requests
Successful merges:
- #68282 (Instrument C / C++ in MemorySanitizer example)
- #68758 (Fix 59191 - ICE when macro replaces crate root with non-module item)
- #68805 (bootstrap: fix clippy warnings)
- #68810 (Remove Copy impl from OnceWith)
- #68815 (remove redundant imports (clippy::single_component_path_imports))
- #68818 (fix couple of perf related clippy warnings)
- #68819 (Suggest `split_at_mut` on multiple mutable index access)
Failed merges:
r? @ghost
|
|
|
|
|
|
also refactor `FnKind` and `visit_assoc_item` visitors
|
|
Remove the `overlapping_marker_traits` feature
See #29864
This has been replaced by `#[feature(marker_trait_attr)]`
A few notes:
* Due to PR #68057 not yet being in the bootstrap compiler, it's
necessary to continue using `#![feature(overlapping_marker_traits)]`
under `#[cfg(bootstrap)]` to work around type inference issues.
* I've updated tests that used `overlapping_marker_traits` to now use
`marker_trait_attr` where applicable
The test `src/test/ui/overlap-marker-trait.rs` doesn't make any sense
now that `overlapping_marker_traits`, so I removed it.
The test `src/test/ui/traits/overlap-permitted-for-marker-traits-neg.rs`
now fails, since it's no longer possible to have multiple overlapping
negative impls of `Send`. I believe that this is the behavior we want
(assuming that `Send` is not going to become a `#[marker]` trait, so I
renamed the test to `overlap-permitted-for-marker-traits-neg`
|
|
The lint message will now use the full, correct path to the `Debug`
trait, even in `no_std`.
|
|
Suggest `split_at_mut` on multiple mutable index access
cc #58792.
|
|
Fix 59191 - ICE when macro replaces crate root with non-module item
Hi,
This should fix #59191! My friend and I are working on learning the rustc codebase through contributions, so please feel free to mention anything amiss or that could be done better.
The code adds an explicit case for when a macro applied to the crate root (via an inner attribute) replaces it with something nonsensical, like a function. The crate root must be a module, and the error message reflects this.
---
I should note that there are a few other weird edge cases here, like if they do output a module, it succeeds but uses that module's name as a prefix for all names in the crate. I'm assuming that's an issue for stabilizing #54726, though.
|
|
Co-Authored-By: 9999years <rbt@sent.as>
|
|
See #29864
This has been replaced by `#[feature(marker_trait_attr)]`
A few notes:
* Due to PR #68057 not yet being in the bootstrap compiler, it's
necessary to continue using `#![feature(overlapping_marker_traits)]`
under `#[cfg(bootstrap)]` to work around type inference issues.
* I've updated tests that used `overlapping_marker_traits` to now use
`marker_trait_attr` where applicable
The test `src/test/ui/overlap-marker-trait.rs` doesn't make any sense
now that `overlapping_marker_traits`, so I removed it.
The test `src/test/ui/traits/overlap-permitted-for-marker-traits-neg.rs`
now fails, since it's no longer possible to have multiple overlapping
negative impls of `Send`. I believe that this is the behavior we want
(assuming that `Send` is not going to become a `#[marker]` trait, so I
renamed the test to `overlap-permitted-for-marker-traits-neg`
|
|
Tweak obligation error output
- Point at arguments or output when fn obligations come from them, or ident when they don't
- Point at `Sized` bound (fix #47990)
- When object unsafe trait uses itself in associated item suggest using `Self` (fix #66424, fix #33375, partially address #38376, cc #61525)
- Point at reason in object unsafe trait with `Self` in supertraits or `where`-clause (cc #40533, cc #68377)
- On implicit type parameter `Sized` obligations, suggest `?Sized` (fix #57744, fix #46683)
|
|
|
|
|
|
|
|
Split `join_codegen_and_link()` into two steps
`join_codegen_and_link()` is split to `join_codegen()` and `link()`.
|
|
|
|
`join_codegen_and_link()` is split to `join_codegen()` and `link()`.
|
|
Implement MIR lowering for or-patterns
This is the last thing needed to get meaningful run-pass tests for or-patterns. There probably need to be more tests before stabilizing this, but the most important cases should have been covered.
Note: we can generate exponentially large MIR CFGs when using or-patterns containing bindings, type ascriptions, or that are for a match arm with a guard. `src/test/mir-opt/exponential-or.rs` shows the best case for what we currently do.
cc #54883
closes #60350
closes #67514
cc @Centril
r? @pnkfelix
|
