Conversation
`rust-analyzer` subtree update Subtree update of `rust-analyzer` to c97b011. Created using https://github.com/rust-lang/josh-sync. r? @ghost
…dead Implement RFC 3678: Final trait methods Tracking: rust-lang/rust#131179 This PR is based on rust-lang/rust#130802, with some minor changes and conflict resolution. Futhermore, this PR excludes final methods from the vtable of a dyn Trait. And some excerpt from the original PR description: > Implements the surface part of rust-lang/rfcs#3678. > > I'm using the word "method" in the title, but in the diagnostics and the feature gate I used "associated function", since that's more accurate. cc @joshtriplett
core: Implement feature `float_exact_integer_constants` Accepted ACP - rust-lang/libs-team#713 (comment) Tracking issue - rust-lang/rust#152466 Implement accepted ACP for `MAX_EXACT_INTEGER` and `MIN_EXACT_INTEGER` on `f16`, `f32`, `f64`, and `f128` Add tests to `coretests/tests/floats/mod.rs`
…petrochenkov Avoid ICE in From/TryFrom diagnostic under -Znext-solver Fixes rust-lang/rust#152518. Under `-Znext-solver=globally`, `trait_ref.args` may contain fewer elements than expected. The diagnostic logic in `fulfillment_errors.rs` assumed at least two elements and unconditionally called `type_at(1)`, which could lead to an index out-of-bounds panic during error reporting. This change adds a defensive check before accessing the second argument to avoid the ICE. A UI regression test has been added.
Remove `rustc_query_system` The end point of the PR sequence rust-lang/rust#152160, rust-lang/rust#152419, rust-lang/rust#152516. r? @Zalathar
misc doc improvements These are things I collected as I was looking at code and docs
…omez Fix mis-constructed `file_span` when generating scraped examples Fixes rust-lang/rust#152601. Seemingly relative with rust-lang/rust#147399 but I could not reproduce the original ICE. This PR removes the `file_span` logic from scraped example generation. The original implementation did not read or write items using `file_span`; it only used it to locate a source file, `context.href_from_span`. However, the span was validated against the wrong file, which could trigger ICEs on inputs such as multibyte characters due to an incorrectly constructed span. Since scraped examples do not use the span and the `url` is already given, the safest and simplest fix is to remove it. Tested against the crate and MCVE documented in the original issue. P.S. there seems to be some bug when rendering call sites, but since fixing mis-behavior is a change rather than a bug-fix that would be implemented in another PR.
Suppress unstable-trait notes under `-Zforce-unstable-if-unmarked` - Fixes rust-lang/rust#152692. --- rust-lang/rust#151036 adds extra diagnostic text (“the nightly-only, unstable trait”) to note when a not-implemented trait is unstable. However, that extra text is usually unhelpful when building a crate graph with `-Zforce-unstable-if-unmarked` (such as the compiler or stdlib), because *any* trait not explicitly marked stable will be treated as unstable. (For typical compiler contributors using the stage0 compiler, this fix won't take effect until the next bootstrap beta bump.)
`probe_op` silence ambiguity errors if tainted see the `proc-macro/quote/not-repeatable.rs` test for a case where this is useful r? types
Port #![default_lib_allocator] to the new attribute parser Tracking issue: rust-lang/rust#131229 r? @JonathanBrouwer
Rollup of 11 pull requests Successful merges: - rust-lang/rust#152700 (miri subtree update) - rust-lang/rust#152715 (`rust-analyzer` subtree update) - rust-lang/rust#151783 (Implement RFC 3678: Final trait methods) - rust-lang/rust#152512 (core: Implement feature `float_exact_integer_constants`) - rust-lang/rust#152661 (Avoid ICE in From/TryFrom diagnostic under -Znext-solver) - rust-lang/rust#152703 (Remove `rustc_query_system`) - rust-lang/rust#152206 (misc doc improvements) - rust-lang/rust#152664 (Fix mis-constructed `file_span` when generating scraped examples) - rust-lang/rust#152698 (Suppress unstable-trait notes under `-Zforce-unstable-if-unmarked`) - rust-lang/rust#152727 (`probe_op` silence ambiguity errors if tainted) - rust-lang/rust#152728 (Port #![default_lib_allocator] to the new attribute parser)
…rochenkov,jieyouxu Fix wrong par_slice implementation rust-lang/rust#152375 (comment)
…ti865
Revert "Fix an ICE in the vtable iteration for a trait reference"
The ICE fix appears to be unsound, causing a miscompilation involving `dyn Trait` and `async {}` which induces segfaults in safe Rust code. As the patch only hid an ICE, it does not seem worth the risk.
This addresses the problem in rust-lang/rust#152735 but it may still merit team discussion even if this PR is merged.
This reverts commit 8afd63610b0a261d3c39e24140c6a87d3bff075c, reversing changes made to 19122c03c7bea6bde1dfa5c81fca5810953d9f39.
…,jieyouxu Support JSON target specs in bootstrap JSON target specs were destabilized in rust-lang/rust#150151 and rust-lang/rust#151534. However, this broke trying to build rustc itself with a JSON target spec. This is because in a few places bootstrap is manually calling `rustc` without the ability for the user to provide additional flags (primarily, `-Zunstable-options` to enable JSON targets). There's a few different ways to fix this. One would be to change these calls to `rustc` to include flags provided by the user (such as `RUSTFLAGS_NOT_BOOTSTRAP`). Just to keep things simple, this PR proposes to just unconditionally pass `-Zunstable-options`. Another consideration here is how maintainable this is. A possible improvement here would be to have a function somewhere (BootstrapCommand, TargetSelection, free function) that would handle appropriately adding the `--target` flag. For example, that's what cargo does in [`CompileKind::add_target_arg`](https://github.com/rust-lang/cargo/blob/592058c7ce08a2ba2628b01e7dc4ce1e72b6bdff/src/cargo/core/compiler/compile_kind.rs#L144-L154). I have only tested building the compiler and a few tools like rustdoc. I have not tested doing things like building other tools, running tests, etc. This would be much easier if there was a Docker image for testing the use case of building rustc with a custom target spec (and even better if that ran in CI). After the next beta branch, using target JSON specs will become more cumbersome because target specs with the `.json` extension will now require passing `-Zjson-target-spec` (from rust-lang/cargo#16557). This does not affect target specs without the `.json` extension (such as those from RUST_TARGET_PATH). From my testing, it should be sufficient to pass `CARGOFLAGS_NOT_BOOTSTRAP="-Zjson-target-spec"`. I think that should be fine, since this is not a particularly common use case AFAIK. We could extend bootstrap to auto-detect if the target is a file path, and pass `-Zjson-target-spec` appropriately. I tried something similar in ehuss/rust@f0bdd35, which could be adapted if desired. It would be nice if all of this is documented somewhere. https://rustc-dev-guide.rust-lang.org/building/new-target.html does not really say how to build the compiler with a custom json target. Fixes rust-lang/rust#151729
Stabilize `if let` guards (`feature(if_let_guard)`) ## Summary This proposes the stabilization of `if let` guards (tracking issue: rust-lang/rust#51114, RFC: rust-lang/rfcs#2294). This feature allows `if let` expressions to be used directly within match arm guards, enabling conditional pattern matching within guard clauses. ## What is being stabilized The ability to use `if let` expressions within match arm guards. Example: ```rust enum Command { Run(String), Stop, Pause, } fn process_command(cmd: Command, state: &mut String) { match cmd { Command::Run(name) if let Some(first_char) = name.chars().next() && first_char.is_ascii_alphabetic() => { // Both `name` and `first_char` are available here println!("Running command: {} (starts with '{}')", name, first_char); state.push_str(&format!("Running {}", name)); } Command::Run(name) => { println!("Cannot run command '{}'. Invalid name.", name); } Command::Stop if state.contains("running") => { println!("Stopping current process."); state.clear(); } _ => { println!("Unhandled command or state."); } } } ``` ## Motivation The primary motivation for `if let` guards is to reduce nesting and improve readability when conditional logic depends on pattern matching. Without this feature, such logic requires nested `if let` statements within match arms: ```rust // Without if let guards match value { Some(x) => { if let Ok(y) = compute(x) { // Both `x` and `y` are available here println!("{}, {}", x, y); } } _ => {} } // With if let guards match value { Some(x) if let Ok(y) = compute(x) => { // Both `x` and `y` are available here println!("{}, {}", x, y); } _ => {} } ``` ## Implementation and Testing The feature has been implemented and tested comprehensively across different scenarios: ### Core Functionality Tests **Scoping and variable binding:** - [`scope.rs`](https://github.com/rust-lang/rust/blob/5796073c134eaac30475f9a19462c4e716c9119c/tests/ui/rfcs/rfc-2294-if-let-guard/scope.rs) - Verifies that bindings created in `if let` guards are properly scoped and available in match arms - [`shadowing.rs`](https://github.com/rust-lang/rust/blob/5796073c134eaac30475f9a19462c4e716c9119c/tests/ui/rfcs/rfc-2294-if-let-guard/shadowing.rs) - Tests that variable shadowing works correctly within guards - [`scoping-consistency.rs`](https://github.com/rust-lang/rust/blob/5796073c134eaac30475f9a19462c4e716c9119c/tests/ui/rfcs/rfc-2294-if-let-guard/scoping-consistency.rs) - Ensures temporaries in guards remain valid for the duration of their match arms **Type system integration:** - [`type-inference.rs`](https://github.com/rust-lang/rust/blob/5796073c134eaac30475f9a19462c4e716c9119c/tests/ui/rfcs/rfc-2294-if-let-guard/type-inference.rs) - Confirms type inference works correctly in `if let` guards - [`typeck.rs`](https://github.com/rust-lang/rust/blob/5796073c134eaac30475f9a19462c4e716c9119c/tests/ui/rfcs/rfc-2294-if-let-guard/typeck.rs) - Verifies type mismatches are caught appropriately **Pattern matching semantics:** - [`exhaustive.rs`](https://github.com/rust-lang/rust/blob/5796073c134eaac30475f9a19462c4e716c9119c/tests/ui/rfcs/rfc-2294-if-let-guard/exhaustive.rs) - Validates that `if let` guards are correctly handled in exhaustiveness analysis - [`move-guard-if-let.rs`](https://github.com/rust-lang/rust/blob/5796073c134eaac30475f9a19462c4e716c9119c/tests/ui/rfcs/rfc-2294-if-let-guard/move-guard-if-let.rs) and [`move-guard-if-let-chain.rs`](https://github.com/rust-lang/rust/blob/5796073c134eaac30475f9a19462c4e716c9119c/tests/ui/rfcs/rfc-2294-if-let-guard/move-guard-if-let-chain.rs) - Test that conditional moves in guards are tracked correctly by the borrow checker ### Error Handling and Diagnostics - [`warns.rs`](https://github.com/rust-lang/rust/blob/5796073c134eaac30475f9a19462c4e716c9119c/tests/ui/rfcs/rfc-2294-if-let-guard/warns.rs) - Tests warnings for irrefutable patterns and unreachable code in guards - [`parens.rs`](https://github.com/rust-lang/rust/blob/5796073c134eaac30475f9a19462c4e716c9119c/tests/ui/rfcs/rfc-2294-if-let-guard/parens.rs) - Ensures parentheses around `let` expressions are properly rejected - [`macro-expanded.rs`](https://github.com/rust-lang/rust/blob/5796073c134eaac30475f9a19462c4e716c9119c/tests/ui/rfcs/rfc-2294-if-let-guard/macro-expanded.rs) - Verifies macro expansions that produce invalid constructs are caught - [`guard-mutability-2.rs`](https://github.com/rust-lang/rust/blob/5796073c134eaac30475f9a19462c4e716c9119c/tests/ui/rfcs/rfc-2294-if-let-guard/guard-mutability-2.rs) - Tests mutability and ownership violations in guards - [`ast-validate-guards.rs`](https://github.com/rust-lang/rust/blob/5796073c134eaac30475f9a19462c4e716c9119c/tests/ui/rfcs/rfc-2497-if-let-chains/ast-validate-guards.rs) - Validates AST-level syntax restrictions ### Drop Order and Temporaries **Key insight:** Unlike `let_chains` in regular `if` expressions, `if let` guards do not have drop order inconsistencies because: 1. Match guards are clearly scoped to their arms 2. There is no "else block" equivalent that could cause temporal confusion - [`drop-order.rs`](https://github.com/rust-lang/rust/blob/5796073c134eaac30475f9a19462c4e716c9119c/tests/ui/rfcs/rfc-2294-if-let-guard/drop-order.rs) - Check drop order of temporaries create in match guards - [`compare-drop-order.rs`](https://github.com/rust-lang/rust/blob/aef3f5fdf052fbbc16e174aef5da6d50832ca316/tests/ui/rfcs/rfc-2294-if-let-guard/compare-drop-order.rs) - Compares drop order between `if let` guards and nested `if let` in match arms, confirming they behave identically across all editions - rust-lang/rust#140981 - A complicated drop order test involved `let chain` was made by @est31 - [`drop-order-comparisons-let-chains.rs`](https://github.com/rust-lang/rust/blob/902b4d28783e03e231d8513082cc30c4fcce5d95/tests/ui/drop/drop-order-comparisons-let-chains.rs) - Compares drop order between `let chains` in `if let guard` and regular `if` expressions - [`if-let-guards.rs`](https://github.com/rust-lang/rust/blob/5650d716e0589e2e145ce9027f35bd534e5f862a/tests/ui/drop/if-let-guards.rs) - Test correctness of drop order for bindings and temporaries - [`if-let-guards-2`](https://github.com/rust-lang/rust/blob/3a6c8c8f3d7ae654fdb6ce1255182bda21680655/tests/ui/drop/if-let-guards-2.rs) - The same test as above but more comprehensive and tests more interactions between different features and their drop order, checking that drop order is correct, created by @traviscross ## Edition Compatibility This feature stabilizes on all editions, unlike `let chains` which was limited to edition 2024. This is safe because: 1. `if let` guards don't suffer from the drop order issues that affected `let chains` in regular `if` expressions 2. The scoping is unambiguous - guards are clearly tied to their match arms 3. Extensive testing confirms identical behavior across all editions ## Interactions with Future Features The lang team has reviewed potential interactions with planned "guard patterns" and determined that stabilizing `if let` guards now does not create obstacles for future work. The scoping and evaluation semantics established here align with what guard patterns will need. ## Unresolved Issues - [x] - rust-lang/rust#140981 - [x] - added tests description by @jieyouxu request - [x] - Concers from @scottmcm about stabilizing this across all editions - [x] - check if drop order in all edition when using `let chains` inside `if let` guard is the same - [x] - interactions with guard patters - [x] - pattern bindings drops before guard bindings rust-lang/rust#143376 - [x] - documentaion (rust-lang/reference#1957) - [ ] (non-blocking) add tests for [this](rust-lang/rust#145237) and [this](rust-lang/rust#141295 (comment)) --- **Related:** - Tracking Issue: rust-lang/rust#51114 - RFC: rust-lang/rfcs#2294 - Documentation PR: rust-lang/reference#1957
Simplify the canonical enum clone branches to a copy statement
I have overhauled MatchBranchSimplification in this PR. This pass tries to unify statements one by one, which is more readable and extensible.
This PR also unifies the following pattern that is mostly generated by GVN into one basic block that contains the copy statement:
```rust
match a {
Foo::A(_) => *a,
Foo::B => Foo::B
}
```
Fixes rust-lang/rust#128081.
Perform many const checks in typeck Some smaller diagnostic changes, the biggest ones avoided by rust-lang/rust#148641 We should be able to move various checks in mir const checking to using `span_bug!` instead of reporting an error, just like mir typeck does as a sanity check. I would like to start doing so separately though, as this PR is a big enough (in what effects it causes, pun intended). r? @fee1-dead
…gillot Simplify `size/align_of_val<T: Sized>` to `size/align_of<T>` instead This is relevant to things like `Box<[u8; 1024]>` where the drop looks at the `size_of_val` (since obviously it might be DST in general) but where we don't actually need to do that since it's always that same value for the `Sized` type. (Equivalent to rust-lang/rust#152681, but flipped in the rebase so it can land before rust-lang/rust#152641 instead of depending on it.)
Just pass `Layout` directly to `box_new_uninit` *[View all comments](https://triagebot.infra.rust-lang.org/gh-comments/rust-lang/rust/pull/152737)* We have a constant for it already (used in `RawVec` for basically the same polymorphization) so let's use it. This is a simple follow-up to rust-lang/rust#148190 from one of the comments.
…i, r=RalfJung rustc_target: callconv: powerpc64: Use the ABI set in target options instead of guessing All PowerPC64 targets except AIX explicitly set the ABI in the target options. We can therefore stop hardcoding the ABI to be used based on the target environment or OS, except for the AIX special case. The fallback based on endianness is kept for the sake of compatibility with custom targets. This makes it so that big endian targets not explicitly accounted for before (powerpc64-unknown-openbsd) and targets that don't use the expected default ABI (big-endian ELFv2 Glibc targets) use the correct ABI in the calling convention code. The second commit is a tiny change to validate the `llvm_abiname` set on PowerPC64(LE) targets. See the commit messages for details. CC @RalfJung who pointed out the missing `llvm_abiname` validation
Fix ICE in const eval of packed SIMD types with non-power-of-two element counts fixes rust-lang/rust#151537 const evaluation of packed SIMD types with non-power-of-two element counts (like `Simd<_, 3>`) was hitting an ICE. the issue was in `check_simd_ptr_alignment` - it asserted that `backend_repr` must be `BackendRepr::SimdVector`, but for packed SIMD types with non-power-of-two counts the compiler uses `BackendRepr::Memory` instead (as mentioned in `rustc_abi/src/layout.rs:1511`). was fixed by making `check_simd_ptr_alignment` accept both `BackendRepr::SimdVector` and `BackendRepr::Memory` for SIMD types. added a check to ensure we're dealing with a SIMD type, and the alignment logic works the same for both representations. also i added a test that reproduces the original ICE.
Simplify internals of `{Rc,Arc}::default`
This commit simplifies the internal implementation of `Default` for these two pointer types to have the same performance characteristics as before (a side effect of changes in rust-lang/rust#131460) while avoid use of internal private APIs of Rc/Arc. To preserve the same codegen as before some non-generic functions needed to be tagged as `#[inline]` as well, but otherwise the same IR is produced before/after this change.
The motivation of this commit is I was studying up on the state of initialization of `Arc` and `Rc` and figured it'd be nicer to reduce the use of internal APIs and instead use public stable APIs where possible, even in the implementation itself.
…chenkov,JonathanBrouwer
reduce the amount of panics in `{TokenStream, Literal}::from_str` calls
*[View all comments](https://triagebot.infra.rust-lang.org/gh-comments/rust-lang/rust/pull/147859)*
Before this PR, calling `TokenStream::from_str` or `Literal::from_str` with an invalid argument would always cause a compile error, even if the `TokenStream` is not used afterwards at all.
This PR changes this so it returns a `LexError` instead in some cases.
This is very theoretically a breaking change, but the doc comment on the impl already says
```
/// NOTE: some errors may cause panics instead of returning `LexError`. We reserve the right to
/// change these errors into `LexError`s later.
```
Fixes some cases of rust-lang/rust#58736.
…st, r=joboet Test(lib/win/proc): Skip `raw_attributes` doctest under Win7 The current doctest for `ProcThreadAttributeListBuilder::raw_attribute` uses `CreatePseudoConsole`, which is only available on Windows 10 October 2018 Update and above. On older versions of Windows, the test fails due to trying to link against a function that is not present in the kernel32 DLL. This therefore ensures the test is still built, but not run under the Win7 target. @rustbot label T-libs A-process A-doctests O-windows-7
fix typo in `carryless_mul` macro invocation This wouldn't really impact anyone, but it's slightly confusing, so let's fix it.
…caller, r=dingxiangfei2009
fix(codegen): Use `body_codegen_attrs` For Caller In `adjust_target_feature_sig`
### Summary:
#### Problem:
Coercing a `#[target_feature]` `const fn` to a function pointer inside a `const` body triggers an ICE (debug builds only):
```rust
#[target_feature(enable = "sse2")]
const fn with_target_feature() {}
const X: () = unsafe {
let _: unsafe fn() = with_target_feature; // ICE
};
```
```text
assertion failed: def_kind.has_codegen_attrs()
unexpected `def_kind` in `codegen_fn_attrs`: Const
```
#### Root Cause:
Introduced in rust-lang/rust#135504 (2025-01-14, commit `8fee6a77394`). `adjust_target_feature_sig` unconditionally calls `codegen_fn_attrs(caller)` to get the caller's target features. `codegen_fn_attrs` requires that the `DefId` satisfies `has_codegen_attrs()`. `DefKind::Const`, `AssocConst`, and `InlineConst` do not — they have no codegen attributes by design. The debug assertion fires.
In release builds the call "worked" accidentally: `codegen_fn_attrs` on a const would reach the query machinery and happen to return empty attributes, producing a correct (but unguaranteed) result. The bug was latent until debug builds exposed it.
#### Solution:
Replace `codegen_fn_attrs(caller)` with `body_codegen_attrs(caller)`. `body_codegen_attrs` exists precisely for this case: it delegates to `codegen_fn_attrs` for function-like `DefKind`s and returns `CodegenFnAttrs::EMPTY` for const items. A const body has no target features, so returning empty is semantically correct.
Also fix the pre-existing variable name `callee_features` → `caller_features` (the variable holds the *caller*'s features, not the callee's).
### Changes:
- `compiler/rustc_middle/src/ty/context.rs`: `adjust_target_feature_sig` — use `body_codegen_attrs` for `caller`; rename `callee_features` → `caller_features`.
- `tests/ui/target-feature/const-target-feature-fn-ptr-coercion.rs`: regression test covering `Const`, `AssocConst`, and `InlineConst` caller contexts.
Fixes rust-lang/rust#152340.
Fix warnings in rs{begin,end}.rs files
As can be seen locally and in CI logs (dist-i686-mingw) that code used to trigger `static_mut_refs` warning.
…=oli-obk Remove `impl IntoQueryParam<P> for &'a P`. `IntoQueryParam` is a trait that lets query callers be a bit sloppy with the passed-in key. - Types similar to `DefId` will be auto-converted to `DefId`. Likewise for `LocalDefId`. - Reference types will be auto-derefed. The auto-conversion is genuinely useful; the auto-derefing much less so. In practice it's only used for passing `&DefId` to queries that accept `DefId`, which is an anti-pattern because `DefId` is marked with `#[rustc_pass_by_value]`. This commit removes the auto-deref impl and makes the necessary sigil adjustments. (I generally avoid using `*` to deref manually at call sites, preferring to deref via `&` in patterns or via `*` in match expressions. Mostly because that way a single deref often covers multiple call sites.) r? @cjgillot
…JonathanBrouwer Start migration for `LintDiagnostic` items by adding API and migrating `LinkerOutput` lint This is more or less the same approach as rust-lang/rust#152811, but in a much smaller size to make it reviewable. A lot of PRs will follow though. :) This PR creates the equivalent of `lint_level` working with `Diagnostic` and add new methods on `MultiSpan` to make it work as well (in particular because we need to copy messages/spans from one context to another). r? @JonathanBrouwer
remove unneeded reboxing Just a small thing I noticed while experimenting with replacing `box_syntax` with `deref_patterns` in the compiler.
Fix typo in armv7a-vex-v5.md Remove duplicate "to" in armv7-vex-v5.md
…uwer Rollup of 14 pull requests Successful merges: - rust-lang/rust#150468 (rustc_target: callconv: powerpc64: Use the ABI set in target options instead of guessing) - rust-lang/rust#151628 (Fix ICE in const eval of packed SIMD types with non-power-of-two element counts) - rust-lang/rust#151871 (don't use env with infer vars) - rust-lang/rust#152591 (Simplify internals of `{Rc,Arc}::default`) - rust-lang/rust#152865 (Fixed ByteStr not padding within its Display trait when no specific alignment is mentioned) - rust-lang/rust#147859 (reduce the amount of panics in `{TokenStream, Literal}::from_str` calls) - rust-lang/rust#152705 (Test(lib/win/proc): Skip `raw_attributes` doctest under Win7) - rust-lang/rust#152767 (fix typo in `carryless_mul` macro invocation) - rust-lang/rust#152837 (fix(codegen): Use `body_codegen_attrs` For Caller In `adjust_target_feature_sig`) - rust-lang/rust#152871 (Fix warnings in rs{begin,end}.rs files) - rust-lang/rust#152879 (Remove `impl IntoQueryParam<P> for &'a P`.) - rust-lang/rust#152933 (Start migration for `LintDiagnostic` items by adding API and migrating `LinkerOutput` lint) - rust-lang/rust#152937 (remove unneeded reboxing) - rust-lang/rust#152953 (Fix typo in armv7a-vex-v5.md)
This updates the rust-version file to c78a29473a68f07012904af11c92ecffa68fcc75.
Pull recent changes from https://github.com/rust-lang/rust via Josh. Upstream ref: rust-lang/rust@c78a294 Filtered ref: d21f4bf Upstream diff: rust-lang/rust@1396514...c78a294 This merge was created using https://github.com/rust-lang/josh-sync.
rustbot
added
the
S-waiting-on-review
rustbot
removed
the
S-waiting-on-review
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
6 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Latest update from rustc.