Upstream sync #42
Merged
Upstream sync #42
Conversation
This file contains 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
…r=jsha Fix mobile toggles position Before:  After:  r? `@jsha`
…askrgr Rollup of 7 pull requests Successful merges: - rust-lang#90383 (Extend check for UnsafeCell in consts to cover unions) - rust-lang#91375 (config.rs: Add support for a per-target default_linker option.) - rust-lang#91480 (rustdoc: use smaller number of colors to distinguish items) - rust-lang#92338 (Add try_reserve and try_reserve_exact for OsString) - rust-lang#92405 (Add a couple needs-asm-support headers to tests) - rust-lang#92435 (Sync rustc_codegen_cranelift) - rust-lang#92440 (Fix mobile toggles position) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup
…Gomez Add Attribute::meta_kind The `AttrItem::meta` function is being called on a lot of places, however almost always the caller is only interested in the `kind` of the result `MetaItem`. Before, the `path` had to be cloned in order to get the kind, now it does not have to be. There is a larger related "problem". In a lot of places, something wants to know contents of attributes. This is accessed through `Attribute::meta_item_list`, which calls `AttrItem::meta` (now `AttrItem::meta_kind`), among other methods. When this function is called, the meta item list has to be recreated from scratch. Everytime something asks a simple question (like is this item/list of attributes `#[doc(hidden)]`?), the tokens of the attribute(s) are cloned, parsed and the results are allocated on the heap. That seems really unnecessary. What would be the best way to cache this? Turn `meta_item_list` into a query perhaps? Related PR: rust-lang#92227 r? rust-lang/rustdoc
Fixes rust-lang#73026 See also: rust-lang#64467, rust-lang#89468 The issue stems from a `FatalError` being silently raised in `panictry_buffer`. Normally this is not a problem, because `panictry_buffer` emits the causes of the error, but they are not themselves fatal, so they get filtered out by the silent emitter. To fix this, we use a parser entrypoint which doesn't use `panictry_buffer`, and we handle the error ourselves.
Remove existing problematic cases.
…lacrum Update libssh2-sys Updates libssh2-sys from 0.2.19 to 0.2.23. This brings in libssh2 1.10 ([RELEASE-NOTES](https://github.com/libssh2/libssh2/blob/libssh2-1.10.0/RELEASE-NOTES)). One of the major changes is to add support for OpenSSH agent on Windows. Closes rust-lang/cargo#10237
…Simulacrum Lock bootstrap (x.py) build directory Closes rust-lang#76661, closes rust-lang#80849, `x.py` creates a lock file at `project_root/lock.db` r? `@jyn514` , because he was one that told me about this~
…8472 Implement split_at_spare_mut without Deref to a slice so that the spare slice is valid ~I'm not sure I understand what's going on here correctly. And I'm pretty sure this safety comment needs to be changed. I'm just referring to the same thing that `as_mut_ptr_range` does.~ (Thanks `@RalfJung` for the guidance and clearing things up) I tried to run https://github.com/rust-lang/miri-test-libstd on alloc with -Zmiri-track-raw-pointers, and got a failure on the test `vec::test_extend_from_within`. I minimized the test failure into this program: ```rust #![feature(vec_split_at_spare)] fn main() { Vec::<i32>::with_capacity(1).split_at_spare_mut(); } ``` The problem is that the existing implementation is actually getting a pointer range where both pointers are derived from the initialized region of the Vec's allocation, but we need the second one to be valid for the region between len and capacity. (thanks Ralf for clearing this up)
Fix double space in pretty printed TryBlock Follow-up to rust-lang#92238 fixing one of the FIXMEs. ```rust macro_rules! repro { ($expr:expr) => { stringify!($expr) }; } fn main() { println!("{}", repro!(try {})); } ``` Before: <code>try {}</code> After: <code>try {}</code> The `head` helper already appends a space: https://github.com/rust-lang/rust/blob/2b67c30bfece00357d5fc09d99b49f21066f04ba/compiler/rustc_ast_pretty/src/pprust/state.rs#L654-L664 so doing `head` followed by `space` resulted in a double space: https://github.com/rust-lang/rust/blob/2b67c30bfece00357d5fc09d99b49f21066f04ba/compiler/rustc_ast_pretty/src/pprust/state.rs#L2241-L2242
Fix whitespace in pretty printed PatKind::Range Follow-up to rust-lang#92238 fixing one of the FIXMEs. ```rust macro_rules! repro { ($pat:pat) => { stringify!($pat) }; } fn main() { println!("{}", repro!(0..=1)); } ``` Before: `0 ..=1` After: `0..=1` The canonical spacing applied by rustfmt has no space after the lower expr. Rustc's parser diagnostics also do not put a space there: https://github.com/rust-lang/rust/blob/df96fb166f59431e3de443835e50d5b8a7a4adb0/compiler/rustc_parse/src/parser/pat.rs#L754
…toyo Sync rustc_codegen_gcc r? `@ghost` cc `@antoyo` `@rustbot` label +A-codegen +A-gcc +T-compiler
[rustc_builtin_macros] add indices to format_foreign::printf::Substitution::Escape Fixes rust-lang#92267. The problem was that the escape string "%%" does not need to appear at the very beginning of the format string, but the iterator implementation assumed that it did. The solution follows the pattern used by `format_foregin::shell::Subtitution::Escape`: https://github.com/rust-lang/rust/blob/8ed935e92dfb09ae388344b12284bf5110cf9265/compiler/rustc_builtin_macros/src/format_foreign.rs#L629
…k-Simulacrum Make tidy check for magic numbers that spell things Remove existing problematic cases. r? `@Mark-Simulacrum`
…askrgr Rollup of 7 pull requests Successful merges: - rust-lang#88310 (Lock bootstrap (x.py) build directory) - rust-lang#92097 (Implement split_at_spare_mut without Deref to a slice so that the spare slice is valid) - rust-lang#92412 (Fix double space in pretty printed TryBlock) - rust-lang#92420 (Fix whitespace in pretty printed PatKind::Range) - rust-lang#92457 (Sync rustc_codegen_gcc) - rust-lang#92460 ([rustc_builtin_macros] add indices to format_foreign::printf::Substitution::Escape) - rust-lang#92469 (Make tidy check for magic numbers that spell things) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup
Mark drop calls in landing pads `cold` instead of `noinline` Now that deferred inlining has been disabled in LLVM (rust-lang#92110), this shouldn't cause catastrophic size blowup. I confirmed that the test cases from rust-lang#41696 (comment) still compile quickly (<1s) after this change. ~Although note that I wasn't able to reproduce the original issue using a recent rustc/llvm with deferred inlining enabled, so those tests may no longer be representative. I was also unable to create a modified test case that reproduced the original issue.~ (edit: I reproduced it on CI by accident--the first commit timed out on the LLVM 12 builder, because I forgot to make it conditional on LLVM version) r? `@nagisa` cc `@arielb1` (this effectively reverts rust-lang#42771 "mark calls in the unwind path as !noinline") cc `@RalfJung` (fixes rust-lang#46515) edit: also fixes rust-lang#87055
Rustbuild already depends on once_cell which in the future can be replaced with std::lazy::Lazy.
The task of the macro is simple enough that a decl macro is almost ten times shorter than the original proc macro. The proc macro is 159 lines while the decl macro is just 18 lines. This reduces the amount of dependencies of rustbuild from 45 to 37. It also slight reduces compilation time from 47s to 44s for debug builds.
This slightly improves compilation time by reducing linking time (saving about a 1/10 of the the total compilation time after changing rustbuild) and slightly reduces disk usage (from 16MB for the rustc wrapper to 4MB).
rustc_metadata: Use a query for collecting all traits in encoder Implement refactoring suggested in rust-lang#92244 (comment) r? `@cjgillot`
Fixes rust-lang#92074 This allows us to insert an `ExprKind::Err` when an invalid expression is used in a literal pattern, preventing later stages of compilation from seeing an unexpected literal pattern.
…Simulacrum Remove CommandEnv::apply It's not being used and uses unsound set_var and remove_var functions. This is an internal function that isn't exported (even with `process_internals` feature), so this shouldn't break anything. Also see rust-lang#92365. Note that this isn't the only use of those methods in standard library, so that particular pull request will need more changes than just this to work (in particular, `test_capture_env_at_spawn` is using `set_var` and `remove_var`).
Clarify the guarantees that ThreadId does and doesn't make. The existing documentation does not spell out whether `ThreadId`s are unique during the lifetime of a thread or of a process. I had to examine the source code to realise (pleasingly!) that they're unique for the lifetime of a process. That seems worth documenting clearly, as it's a strong guarantee. Examining the way `ThreadId`s are created also made me realise that the `as_u64` method on `ThreadId` could be a trap for the unwary on those platforms where the platform's notion of a thread identifier is also a 64 bit integer (particularly if they happen to use a similar identifier scheme to `ThreadId`). I therefore think it's worth being even clearer that there's no relationship between the two.
They were stabilized together with `Option::unwrap_unchecked` in rust-lang#81383. Signed-off-by: Miguel Ojeda <[email protected]>
Mak DefId to AccessLevel map in resolve for export hir_id to accesslevel in resolve and applied in privacy using local def id removing tracing probes making function not recursive and adding comments Move most of Exported/Public res to rustc_resolve moving public/export res to resolve fix missing stability attributes in core, std and alloc move code to access_levels.rs return for some kinds instead of going through them Export correctness, macro changes, comments add comment for import binding add comment for import binding renmae to access level visitor, remove comments, move fn as closure, remove new_key fmt fix rebase fix rebase fmt fmt fix: move macro def to rustc_resolve fix: reachable AccessLevel for enum variants fmt fix: missing stability attributes for other architectures allow unreachable pub in rustfmt fix: missing impl access level + renaming export to reexport Missing impl access level was found thanks to a test in clippy
Noted in rust-lang#87739 (review), lang_items::extract no longer needs to take a closure.
…michaelwoerister Ensure that `Fingerprint` caching respects hashing configuration Fixes rust-lang#92266 In some `HashStable` impls, we use a cache to avoid re-computing the same `Fingerprint` from the same structure (e.g. an `AdtDef`). However, the `StableHashingContext` used can be configured to perform hashing in different ways (e.g. skipping `Span`s). This configuration information is not included in the cache key, which will cause an incorrect `Fingerprint` to be used if we hash the same structure with different `StableHashingContext` settings. To fix this, the configuration settings of `StableHashingContext` are split out into a separate `HashingControls` struct. This struct is used as part of the cache key, ensuring that our caches always produce the correct result for the given settings. With this in place, we now turn off `Span` hashing during the entire process of computing the hash included in legacy symbols. This current has no effect, but will matter when a future PR starts hashing more `Span`s that we currently skip.
…, r=petrochenkov Fixes wrong unreachable_pub lints on nested and glob public reexport Linked issues: rust-lang#64762 & rust-lang#82064
…pointee, r=jackh726 Normalize struct tail type when checking Pointee trait Let's go ahead and implement the FIXMEs by properly normalizing the struct-tail type when satisfying a Pointee obligation. This should fix the ICE when we try to calculate a layout depending on `<Ty as Pointee>::Metadata` later. Fixes rust-lang#92128 Fixes rust-lang#92577 Additionally, mark the obligation as ambiguous if there are any infer types in that struct-tail type. This has the effect of causing `<_ as Pointee>::Metadata` to be properly replaced with an infer variable ([here](https://github.com/rust-lang/rust/blob/master/compiler/rustc_trait_selection/src/traits/project.rs#L813)) and registered as an obligation... this turns out to be very important in unifying function parameters with formals that are assoc types. Fixes rust-lang#91446
…line-removal, r=camelid Fix invalid removal of newlines from doc comments Fixes rust-lang#91201. Before:  After:  r? `@camelid`
Make source links look cleaner Change from syntaxy-looking [src] to the plain word "source". Change the syntaxy-looking `[-]` at the top of the page to say "collapse". Reduce opacity of rightside content. Part of rust-lang#59851 r? `@GuillaumeGomez` Demo: https://rustdoc.crud.net/jsha/source-link-2/std/string/struct.String.html [Discussed on Zulip](https://rust-lang.zulipchat.com/#narrow/stream/266220-rustdoc/topic/display.20of.20source.20link).
…-const-expr, r=oli-obk Normalize generator-local types with unevaluated constants Normalize generator-interior types in addition to (i.e. instead of just) erasing regions, since sometimes we collect types with unevaluated const exprs. Fixes rust-lang#84737 Fixes rust-lang#88171 Fixes rust-lang#92091 Fixes rust-lang#92634 Probably also fixes rust-lang#73114, but that one has no code I could test. It looks like it's the same issue, though.
Release notes: add `Result::unwrap_{,err_}unchecked`
They were stabilized together with `Option::unwrap_unchecked`
in rust-lang#81383.
Signed-off-by: Miguel Ojeda <[email protected]>
…etrochenkov Clean up lang_items::extract Noted in rust-lang#87739 (review), lang_items::extract no longer needs to take a closure.
update miri Fixes rust-lang#92691 r? `@ghost`
…askrgr Rollup of 7 pull requests Successful merges: - rust-lang#92248 (Normalize struct tail type when checking Pointee trait) - rust-lang#92357 (Fix invalid removal of newlines from doc comments) - rust-lang#92602 (Make source links look cleaner) - rust-lang#92636 (Normalize generator-local types with unevaluated constants) - rust-lang#92693 (Release notes: add `Result::unwrap_{,err_}unchecked`) - rust-lang#92702 (Clean up lang_items::extract) - rust-lang#92717 (update miri) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup
…ishearth rustdoc: Remove the intra-doc links side channel The side channel made the code much more complex and harder to understand. It was added as a temporary workaround in 0c99d80, but it's no longer necessary. The addition of `UrlFragment` in rust-lang#92088 was the key to getting rid of the side channel. The semantic information (rather than the strings that used to be used for fragments) that is now captured by `UrlFragment` is enough to obviate the side channel. An additional change had to be made to `UrlFragment` in this PR to make this possible: it now records `DefId`s rather than item names. This PR also consolidates the checks for anchor conflicts into one place. r? `@Manishearth`
Make `DefId` `repr(C)`, optimize big-endian field order r? `@michaelwoerister`
|
bors r+ |
|
Build failed: |
|
bors try |
tryBuild succeeded: |
|
Merge as-is? |
|
Yes please |
|
bors r+ |
|
Build succeeded: |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
No description provided.