Rollup merge of #101435 - JakobDegen:bitwidth-tests, r=wesleywiser
Remove unnecessary `EMIT_MIR_FOR_EACH_BITWIDTH`
This commit removes the annotation only for those tests where the 32 bit and 64 bit files were exactly identical. I didn't touch anything in the `mir-opt/const` directory, since having this annotation there seems more principled, even if it doesn't make a difference.
This also removes four additional files related to the `separate_const_switch.rs` test. The associated annotations were removed in #100827 , but I forgot to remove the files as well. (#97564 is the issue tracking an automated check here)
Rollup merge of #101416 - uarif1:doc_non_blocking_stdio, r=joshtriplett
stdio: Document no support for writing to non-blocking stdio/stderr
Printing to stdio/stderr that have been opened with non-blocking
(O_NONBLOCK in linux) can result in an error, which is not handled
by std::io module causing a panic.
Signed-off-by: Usama Arif <usama.arif@bytedance.com>
Rollup merge of #101343 - diminishedprime:patch-3, r=tmandry
Add -api-level to pm command
As of ~Aug 30th, `pm build` commands require an `api-level` flag. This flag should match the fuchsia api-level that's being targeted by the code. Since this is dependent on the version of the SDK that's being used, we may want to change this to something a bit more robust in the future.
Usama Arif [Sun, 4 Sep 2022 17:43:18 +0000 (18:43 +0100)]
stdio: Document no support for writing to non-blocking stdio/stderr
Printing to stdio/stderr that have been opened with non-blocking
(O_NONBLOCK in linux) can result in an error, which is not handled
by std::io module causing a panic.
Signed-off-by: Usama Arif <usama.arif@bytedance.com>
Auto merge of #98332 - oli-obk:assume, r=wesleywiser
Lower the assume intrinsic to a MIR statement
This makes https://github.com/rust-lang/rust/pull/96862#issuecomment-1153739068 easier and will generally allow us to cheaply insert assume intrinsic calls in mir building.
Auto merge of #100801 - Kobzol:track-pgo-profile-paths, r=michaelwoerister
Track PGO profiles in depinfo
This PR makes sure that PGO profiles (`-Cprofile-use` and `-Cprofile-sample-use`) are tracked in depinfo, so that when they change, the compilation session will be invalidated.
This approach was discussed on [Zulip](https://rust-lang.zulipchat.com/#narrow/stream/246057-t-cargo/topic/Tracking.20PGO.20profile.20files.20in.20cargo).
I tried it locally and it seems that the code is recompiled just with this change, and https://github.com/rust-lang/rust/pull/100413 is not even needed. But it's possible that not everything required is recompiled, so we will probably want to land both changes.
Another approach to implement this could be to store the PGO profiles in `sess.parse_sess.file_depinfo` when the session is being created, but then the paths would have to be converted to a string and then to a symbol, which seemed unnecessarily complicated.
Rollup merge of #101491 - notriddle:notriddle/sub-variant-div-item-info, r=GuillaumeGomez
rustdoc: remove outdated CSS `.sub-variant > div > .item-info`
This CSS still matches sometimes, as you can see in <https://doc.rust-lang.org/1.63.0/std/collections/enum.TryReserveErrorKind.html#variant.AllocError.fields>, but since nothing else is setting `margin-top`, putting it back to `initial` does nothing.
This selector was added here, but it was called `.stability` instead of `.item-info` at the time, probably as an override for the selector immediately above it that sets a negative margin:
Auto merge of #100404 - BelovDV:linker_group, r=petrochenkov
change stdlib circular dependencies handling
Remove group_start and group_end, add dependencies to symbols.o
Implements the suggestion from https://github.com/rust-lang/rust/pull/85805#discussion_r666249351
r? `@petrochenkov`
Auto merge of #101485 - GuillaumeGomez:rollup-68p9di4, r=GuillaumeGomez
Rollup of 7 pull requests
Successful merges:
- #101357 (Include enum path in variant suggestion)
- #101434 (Update `SessionDiagnostic::into_diagnostic` to take `Handler` instead of `ParseSess`)
- #101445 (Suggest introducing an explicit lifetime if it does not exist)
- #101457 (Recover from using `;` as separator between fields)
- #101462 (Rustdoc-Json: Store Variant Fields as their own item.)
- #101471 (Report number of delayed bugs properly with `-Ztreat-err-as-bug`)
- #101473 (Add more size assertions for MIR types.)
Michael Howell [Tue, 6 Sep 2022 17:33:58 +0000 (10:33 -0700)]
rustdoc: remove outdated CSS `.sub-variant > div > .item-info`
This CSS still matches sometimes, as you can see in
<https://doc.rust-lang.org/1.63.0/std/collections/enum.TryReserveErrorKind.html#variant.AllocError.fields>,
but since nothing else is setting `margin-top`, putting it back to `initial`
does nothing.
Rollup merge of #101471 - compiler-errors:delay-bug-are-count-too, r=oli-obk
Report number of delayed bugs properly with `-Ztreat-err-as-bug`
Report the number of delayed bugs that went into the `-Ztreat-errr-as-bug=N` being triggered, even if we don't count it in the err_count in regular diagnostic output.
Sometimes we have a session that creates a few diagnostics, perhaps: Error, Delay bug, Error, then Delay bug.
If I ran `-Ztreat-err-as-bug=3`, then I will now see "aborting after 2 errors and 1 delayed bugs" instead of just "after 2 errors" which is confusing since I passed `3`.
Rollup merge of #101462 - aDotInTheVoid:rdj-enum-field-2, r=GuillaumeGomez
Rustdoc-Json: Store Variant Fields as their own item.
Closes #100587
Closes #92945
Successor to #100762
Unlike that one, we don't have merge `StructType` and `Variant`, as after #101386 `Variant` stores enum specific information (discriminant).
Resolves the naming discussion (https://github.com/rust-lang/rust/pull/100762#discussion_r950690526) by having seperate enums for struct and enum kinds
Resolves `#[doc(hidden)]` on tuple structs (https://github.com/rust-lang/rust/pull/100762#discussion_r950833884) by storing as a `Vec<Option<Id>>`
Rollup merge of #101457 - ChayimFriedman2:struct-field-semi, r=fee1-dead
Recover from using `;` as separator between fields
Partially fixes #101440 (only for record structs).
Doing that for tuple structs is harder as their parsing passes through a bunch of helper functions. I don't know how to do that. But [their error message is better anyway](https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=cc6ee8bb2593596c0cea89d49e79bcb4) and suggests using a comma, even if it doesn't suggest replacing the semicolon with it.
Rollup merge of #101434 - JhonnyBillM:replace-session-for-handler-in-into-diagnostic, r=davidtwco
Update `SessionDiagnostic::into_diagnostic` to take `Handler` instead of `ParseSess`
Suggested by the team in [this Zulip Topic](https://rust-lang.zulipchat.com/#narrow/stream/336883-i18n/topic/.23100717.20SessionDiagnostic.20on.20Handler).
`Handler` already has almost all the capabilities of `ParseSess` when it comes to diagnostic emission, in this migration we only needed to add the ability to access `source_map` from the emitter in order to get a `Snippet` and the `start_point`. Not sure if adding these two methods [`span_to_snippet_from_emitter` and `span_start_point_from_emitter`] is the best way to address this gap.
P.S. If this goes in the right direction, then we probably may want to move `SessionDiagnostic` to `rustc_errors` and rename it to `DiagnosticHandler` or something similar.
Auto merge of #100733 - scottmcm:inline-from-from-identity, r=m-ou-se
Inline `<T as From<T>>::from`
I noticed (in https://github.com/rust-lang/rust/pull/100693#issuecomment-1218520141) that the MIR for <https://play.rust-lang.org/?version=nightly&mode=release&edition=2021&gist=67097e0494363ee27421a4e3bdfaf513> has inlined most stuff
```
scope 5 (inlined <Result<i32, u32> as Try>::branch)
```
```
scope 8 (inlined <Result<i32, u32> as Try>::from_output)
```
But yet the do-nothing `from` call was still there:
```
_17 = <u32 as From<u32>>::from(move _18) -> bb9;
```
So let's give this a try and see what perf has to say.
Auto merge of #101479 - Dylan-DPC:rollup-v8ite0y, r=Dylan-DPC
Rollup of 5 pull requests
Successful merges:
- #100658 (TyCtxt::get_attr should check that no duplicates are allowed)
- #101021 (Migrate ``rustc_middle`` diagnostic)
- #101287 (Document eager evaluation of `bool::then_some` argument)
- #101412 (Some more cleanup in `core`)
- #101427 (Fix ICE, generalize 'move generics to trait' suggestion for >0 non-rcvr arguments)
Rollup merge of #101412 - WaffleLapkin:improve_std_ptr_code_leftovers, r=scottmcm
Some more cleanup in `core`
- remove some integer casts from slice iter (proposed in https://github.com/rust-lang/rust/pull/100819#discussion_r951113196)
- replace `as usize` casts with `usize::from` in slice sort (proposed in https://github.com/rust-lang/rust/pull/100822#discussion_r950768698)
Rollup merge of #101287 - Adam-Gleave:doc_bool_then_some, r=scottmcm
Document eager evaluation of `bool::then_some` argument
I encountered this earlier today and thought maybe `bool::then_some` could use a little addition to the documentation.
It's pretty obvious with familiarity and from looking at the implementation, but the argument for `then_some` is eagerly evaluated, which means if you do the following (as I did), you can have a problem:
```rust
// Oops!
let _ = something
.has_another_thing()
.then_some(something.another_thing_or_panic());
```
A note, similar to other methods with eagerly-evaluated arguments and a lazy alternative (`Option::or`, for example), could help point this out to people who forget (like me)!
Auto merge of #101362 - compiler-errors:unnecessary-let, r=cjgillot
Suggest removing unnecessary prefix let in patterns
Helps with #101291, though I think `@estebank` probably wants this:
> Finally, I think it'd be nice if we could detect that we don't know for sure and "just" swallow the rest of the expression (find the next ; accounting for nested braces) or the end of the item (easier).
... to be implemented before we close that issue out completely.
Auto merge of #101241 - camsteffen:refactor-binding-annotations, r=cjgillot
`BindingAnnotation` refactor
* `ast::BindingMode` is deleted and replaced with `hir::BindingAnnotation` (which is moved to `ast`)
* `BindingAnnotation` is changed from an enum to a tuple struct e.g. `BindingAnnotation(ByRef::No, Mutability::Mut)`
* Associated constants added for convenience `BindingAnnotation::{NONE, REF, MUT, REF_MUT}`
One goal is to make it more clear that `BindingAnnotation` merely represents syntax `ref mut` and not the actual binding mode. This was especially confusing since we had `ast::BindingMode`->`hir::BindingAnnotation`->`thir::BindingMode`.
I wish there were more symmetry between `ByRef` and `Mutability` (variant) naming (maybe `Mutable::Yes`?), and I also don't love how long the name `BindingAnnotation` is, but this seems like the best compromise. Ideas welcome.
Auto merge of #101464 - JohnTitor:rollup-unsjgm6, r=JohnTitor
Rollup of 7 pull requests
Successful merges:
- #99291 (Add let else drop order tests)
- #101402 (Add a Machine hook for inline assembly)
- #101404 (Fix cleanup for uninitialized stdout)
- #101418 (Revert "Mention rust-analyzer maintainers when `proc_macro` bridge is changed")
- #101425 (Point at type parameter in plain path expr)
- #101426 (Don't duplicate file descriptors into stdio fds)
- #101447 (Remove generics_def_id_map from the resolver.)
Rollup merge of #101402 - saethlin:inline-asm-hook, r=oli-obk
Add a Machine hook for inline assembly
I'm sketching out some support in Miri to "execute" inline assembly. I want this because there are codebases which have very simple inline assembly like hand-written syscall wrappers, and it would be nice to test such code without modification.
Rollup merge of #99291 - est31:let_else_tests, r=joshtriplett
Add let else drop order tests
Add a systematic matrix based test that checks temporary drop order in various settings, `let-else-drop-order.rs`, as requested [here](https://github.com/rust-lang/rust/pull/93628#issuecomment-1055738523).
The drop order of let and let else is supposed to be the and in order to ensure this, the test checks that this holds for a number of cases.
The test also ensures that we drop the temporaries of the condition before executing the else block.
Add matrix based test for documenting the let / let else temporary drop order
The drop order of let and let else is supposed to be the same,
and in order to ensure this, the test checks that this holds for
the given list of cases.
The test also ensures that we drop the temporaries of the
condition before executing the else block.
We made the test matrix based so it can check all the possible
combinations and find out possible edge cases.
Auto merge of #101439 - Dylan-DPC:rollup-2wf1mtj, r=Dylan-DPC
Rollup of 6 pull requests
Successful merges:
- #101142 (Improve HIR stats)
- #101367 (Suggest `{Option,Result}::{copied,clone}()` to satisfy type mismatch)
- #101391 (more clippy::perf fixes)
- #101409 (Don't fire `rust_2021_incompatible_closure_captures` in `edition = 2021` crates)
- #101420 (Fix `hir::Local` doc to match with the variable name used: `init`)
- #101429 (Don't suggest reborrow if usage is inside a closure)
Rollup merge of #101429 - compiler-errors:issue-101119, r=lcnr
Don't suggest reborrow if usage is inside a closure
I can't think of why we would ever be able to *successfully* suggest a mutable reborrow `&mut *` due to a move happening due to a closure, so just suppress it.
Auto merge of #101414 - mystor:pm_nested_cross_thread, r=eddyb
proc_macro/bridge: use the cross-thread executor for nested proc-macros
While working on some other changes in the bridge, I noticed that when
running a nested proc-macro (which is currently only possible using
the unstable `TokenStream::expand_expr`), any symbols held by the
proc-macro client would be invalidated, as the same thread would be used
for the nested macro by default, and the interner doesn't handle nested
use.
After discussing with `@eddyb,` we decided the best approach might be to
force the use of the cross-thread executor for nested invocations, as it
will never re-use thread-local storage, avoiding the issue. This
shouldn't impact performance, as expand_expr is still unstable, and
infrequently used.
This was chosen rather than making the client symbol interner handle
nested invocations, as that would require replacing the internal
interner `Vec` with a `BTreeMap` (as valid symbol id ranges could now be
disjoint), and the symbol interner is known to be fairly perf-sensitive.
This patch adds checks to the execution strategy to use the cross-thread
executor when doing nested invocations. An alternative implementation
strategy could be to track this information in the `ExtCtxt`, however a
thread-local in the `proc_macro` crate was chosen to add an assertion so
that `rust-analyzer` is aware of the issue if it implements
`expand_expr` in the future.
projects / rust.git / log