Dylan DPC [Wed, 17 Mar 2021 23:28:04 +0000 (00:28 +0100)]
Rollup merge of #82191 - Soveu:dedup, r=nagisa
Vec::dedup_by optimization
Now `Vec::dedup_by` drops items in-place as it goes through them.
From my benchmarks, it is around 10% faster when T is small, with no major regression when otherwise.
I used `ptr::copy` instead of conditional `ptr::copy_nonoverlapping`, because the latter had some weird performance issues on my ryzen laptop (it was 50% slower on it than on intel/sandybridge laptop)
It would be good if someone was able to reproduce these results.
bors [Wed, 17 Mar 2021 19:39:03 +0000 (19:39 +0000)]
Auto merge of #82122 - bstrie:dep4real, r=dtolnay
Deprecate `intrinsics::drop_in_place` and `collections::Bound`, which accidentally weren't deprecated
Fixes #82080.
I've taken the liberty of updating the `since` values to 1.52, since an unobservable deprecation isn't much of a deprecation (even the detailed release notes never bothered to mention these deprecations).
As mentioned in the issue I'm *pretty* sure that using a type alias for `Bound` is semantically equivalent to the re-export; [the reference implies](https://doc.rust-lang.org/reference/items/type-aliases.html) that type aliases only observably differ from types when used on unit structs or tuple structs, whereas `Bound` is an enum.
bors [Wed, 17 Mar 2021 16:49:46 +0000 (16:49 +0000)]
Auto merge of #83188 - petrochenkov:field, r=lcnr
ast/hir: Rename field-related structures
I always forget what `ast::Field` and `ast::StructField` mean despite working with AST for long time, so this PR changes the naming to less confusing and more consistent.
Various visiting and other methods working with the fields are renamed correspondingly too.
The second commit reduces the size of `ExprKind` by boxing fields of `ExprKind::Struct` in preparation for https://github.com/rust-lang/rust/pull/80080.
bors [Wed, 17 Mar 2021 08:27:16 +0000 (08:27 +0000)]
Auto merge of #83225 - JohnTitor:rollup-4hnuhb8, r=JohnTitor
Rollup of 8 pull requests
Successful merges:
- #82774 (Fix bad diagnostics for anon params with ref and/or qualified paths)
- #82826 ((std::net::parser): Fix capitalization of IP version names)
- #83092 (More precise spans for HIR paths)
- #83124 (Do not insert impl_trait_in_bindings opaque definitions twice.)
- #83202 (Show details in cfg version unstable book)
- #83203 (Don't warn about old rustdoc lint names (temporarily))
- #83206 (Update books)
- #83219 (Update cargo)
3 commits in 3b6fe80c205d2a2b5dc8a276192bbce9eeb9e9cf..e32a2f928f8b78d534bca2b9e7736413314dc556
2021-02-22 22:09:17 -0800 to 2021-03-08 23:24:30 -0800
- Clarify that ::foo paths are not necessarily based off of the "crate root" (rust-lang-nursery/reference#974)
- Comment typo (rust-lang-nursery/reference#977)
- Fix misspelled word discrimnant (rust-lang-nursery/reference#976)
15 commits in c431f8c29a41413dddcb3bfa0d71c9cabe366317..67ebd4b55dba44edfc351621cef6e5e758169c55
2021-02-28 16:35:20 -0500 to 2021-03-11 13:36:25 -0800
- Remove extra the (rust-lang/rustc-dev-guide#1088)
- Fix double-word typos (rust-lang/rustc-dev-guide#1084)
- I-nominated are nominated for discussion (rust-lang/rustc-dev-guide#1080)
- Complete unfinished statement
- Check `BASE_SHA` only if it's a PR (rust-lang/rustc-dev-guide#1083)
- Update lins
- Apply suggestions from code review
- Add stub about the THIR
- Switch from Travis to GHA (rust-lang/rustc-dev-guide#1073)
- Adjust a bit better P- label text
- Fix typos (rust-lang/rustc-dev-guide#1079)
- Update cmake version in prerequisites.md (rust-lang/rustc-dev-guide#1077)
- Fix typo: suceed -> succeed
- Add article on using WPA to profile rustc memory usage on Windows (rust-lang/rustc-dev-guide#1074)
- Use more accurate estimate of generated LLVM IR with llvm-lines
Yuki Okushi [Wed, 17 Mar 2021 06:20:58 +0000 (15:20 +0900)]
Rollup merge of #83203 - jyn514:rustdoc-warnings, r=Manishearth
Don't warn about old rustdoc lint names (temporarily)
Since https://github.com/rust-lang/rust/pull/80527, rustdoc users have an unpleasant situation: they can either use the new tool lint names (`rustdoc::non_autolinks`) or they can use the old names (`non_autolinks`). If they use the tool lints, they get a hard error on stable compilers, because rustc rejects all tool names it doesn't recognize (https://github.com/rust-lang/rust/issues/66079#issuecomment-788589193). If they use the old name, they get a warning to rename the lint to the new name. The only way to compile without warnings is to add `#[allow(renamed_removed_lints)]`, which defeats the whole point of the change: we *want* people to switch to the new name.
To avoid people silencing the lint and never migrating to the tool lint, this avoids warning about the old name, while still allowing you to use the new name. Once the new `rustdoc` tool name makes it to the stable channel, we can change these lints to warn again.
This adds the new lint functions `register_alias` and `register_ignored` - I didn't see an existing way to do this.
Yuki Okushi [Wed, 17 Mar 2021 06:20:54 +0000 (15:20 +0900)]
Rollup merge of #83092 - petrochenkov:qspan, r=estebank
More precise spans for HIR paths
`Ty::assoc_item` is lowered to `<Ty>::assoc_item` in HIR, but `Ty` got span from the whole path.
This PR fixes that, and adjusts some diagnostic code that relied on `Ty` having the whole path span.
This is a pre-requisite for https://github.com/rust-lang/rust/pull/82868 (we cannot report suggestions like `Tr::assoc` -> `<dyn Tr>::assoc` with the current imprecise spans).
r? ````@estebank````
bors [Wed, 17 Mar 2021 05:46:08 +0000 (05:46 +0000)]
Auto merge of #83084 - nagisa:nagisa/features-native, r=petrochenkov
Adjust `-Ctarget-cpu=native` handling in cg_llvm
When cg_llvm encounters the `-Ctarget-cpu=native` it computes an
explciit set of features that applies to the target in order to
correctly compile code for the host CPU (because e.g. `skylake` alone is
not sufficient to tell if some of the instructions are available or
not).
However there were a couple of issues with how we did this. Firstly, the
order in which features were overriden wasn't quite right – conceptually
you'd expect `-Ctarget-cpu=native` option to override the features that
are implicitly set by the target definition. However due to how other
`-Ctarget-cpu` values are handled we must adopt the following order
of priority:
* Features from -Ctarget-cpu=*; are overriden by
* Features implied by --target; are overriden by
* Features from -Ctarget-feature; are overriden by
* function specific features.
Another problem was in that the function level `target-features`
attribute would overwrite the entire set of the globally enabled
features, rather than just the features the
`#[target_feature(enable/disable)]` specified. With something like
`-Ctarget-cpu=native` we'd end up in a situation wherein a function
without `#[target_feature(enable)]` annotation would have a broader
set of features compared to a function with one such attribute. This
turned out to be a cause of heavy run-time regressions in some code
using these function-level attributes in conjunction with
`-Ctarget-cpu=native`, for example.
With this PR rustc is more careful about specifying the entire set of
features for functions that use `#[target_feature(enable/disable)]` or
`#[instruction_set]` attributes.
Sadly testing the original reproducer for this behaviour is quite
impossible – we cannot rely on `-Ctarget-cpu=native` to be anything in
particular on developer or CI machines.
cc https://github.com/rust-lang/rust/issues/83027 `@BurntSushi`
bors [Tue, 16 Mar 2021 22:42:56 +0000 (22:42 +0000)]
Auto merge of #82936 - oli-obk:valtree, r=RalfJung,lcnr,matthewjasper
Implement (but don't use) valtree and refactor in preparation of use
This PR does not cause any functional change. It refactors various things that are needed to make valtrees possible. This refactoring got big enough that I decided I'd want it reviewed as a PR instead of trying to make one huge PR with all the changes.
cc `@rust-lang/wg-const-eval` on the following commits:
cc `@rust-lang/wg-mir-opt` for cf1700c (`mir::Constant` can now represent either a `ConstValue` or a `ty::Const`, and it is totally possible to have two different representations for the same value)
When cg_llvm encounters the `-Ctarget-cpu=native` it computes an
explciit set of features that applies to the target in order to
correctly compile code for the host CPU (because e.g. `skylake` alone is
not sufficient to tell if some of the instructions are available or
not).
However there were a couple of issues with how we did this. Firstly, the
order in which features were overriden wasn't quite right – conceptually
you'd expect `-Ctarget-cpu=native` option to override the features that
are implicitly set by the target definition. However due to how other
`-Ctarget-cpu` values are handled we must adopt the following order
of priority:
* Features from -Ctarget-cpu=*; are overriden by
* Features implied by --target; are overriden by
* Features from -Ctarget-feature; are overriden by
* function specific features.
Another problem was in that the function level `target-features`
attribute would overwrite the entire set of the globally enabled
features, rather than just the features the
`#[target_feature(enable/disable)]` specified. With something like
`-Ctarget-cpu=native` we'd end up in a situation wherein a function
without `#[target_feature(enable)]` annotation would have a broader
set of features compared to a function with one such attribute. This
turned out to be a cause of heavy run-time regressions in some code
using these function-level attributes in conjunction with
`-Ctarget-cpu=native`, for example.
With this PR rustc is more careful about specifying the entire set of
features for functions that use `#[target_feature(enable/disable)]` or
`#[instruction_set]` attributes.
Sadly testing the original reproducer for this behaviour is quite
impossible – we cannot rely on `-Ctarget-cpu=native` to be anything in
particular on developer or CI machines.
bors [Tue, 16 Mar 2021 19:19:06 +0000 (19:19 +0000)]
Auto merge of #82536 - sexxi-goose:handle-patterns-take-2, r=nikomatsakis
2229: Handle patterns within closures correctly when `capture_disjoint_fields` is enabled
This PR fixes several issues related to handling patterns within closures when `capture_disjoint_fields` is enabled.
1. Matching is always considered a use of the place, even with `_` patterns
2. Compiler ICE when capturing fields in closures through `let` assignments
To do so, we
- Introduced new Fake Reads
- Delayed use of `Place` in favor of `PlaceBuilder`
- Ensured that `PlaceBuilder` can be resolved before attempting to extract `Place` in any of the pattern matching code
Joshua Nelson [Tue, 16 Mar 2021 15:59:05 +0000 (11:59 -0400)]
Don't warn about old rustdoc lint names (temporarily)
Right now, rustdoc users have an unpleasant situation: they can either
use the new tool lint names (`rustdoc::non_autolinks`) or they can use
the old names (`non_autolinks`). If they use the tool lints, they get a
hard error on stable compilers, because rustc rejects all tool names it
doesn't recognize. If they use the old name, they get a warning to
rename the lint to the new name. The only way to compile without
warnings is to add `#[allow(renamed_removed_lints)]`, which defeats the
whole point of the change: we *want* people to switch to the new name.
To avoid people silencing the lint and never migrating to the tool lint,
this avoids warning about the old name, while still allowing you to use
the new name. Once the new `rustdoc` tool name makes it to the stable
channel, we can change these lints to warn again.
This adds the new lint functions `register_alias` and `register_ignored`
- I didn't see an existing way to do this.
bors [Tue, 16 Mar 2021 16:37:43 +0000 (16:37 +0000)]
Auto merge of #83199 - JohnTitor:rollup-zrfk94a, r=JohnTitor
Rollup of 10 pull requests
Successful merges:
- #81822 (Added `try_exists()` method to `std::path::Path`)
- #83072 (Update `Vec` docs)
- #83077 (rustdoc: reduce GC work during search)
- #83091 (Constify `copy` related functions)
- #83156 (Fall-back to sans-serif if Arial is not available)
- #83157 (No background for code in portability snippets)
- #83160 (Deprecate RustcEncodable and RustcDecodable.)
- #83162 (Specify *.woff2 files as binary)
- #83172 (More informative diagnotic from `x.py test` attempt atop beta checkout)
- #83196 (Use delay_span_bug instead of panic in layout_scalar_valid_range)
Yuki Okushi [Tue, 16 Mar 2021 14:54:03 +0000 (23:54 +0900)]
Rollup merge of #83196 - tmiasko:valid-range-delay-span-bug, r=oli-obk
Use delay_span_bug instead of panic in layout_scalar_valid_range
#83054 introduced validation of scalar range attributes, but panicking
code that uses the attribute remained reachable. Use `delay_span_bug`
instead to avoid the ICE.
Yuki Okushi [Tue, 16 Mar 2021 14:54:02 +0000 (23:54 +0900)]
Rollup merge of #83172 - pnkfelix:bootstrap-tell-me-what-to-do-about-tidy-on-beta, r=Mark-Simulacrum
More informative diagnotic from `x.py test` attempt atop beta checkout
Make bootstrap be more informative when one does `x.py test` on a beta checkout without other mods.
To be clear, by default running `x.py test` on a checkout of the beta branch
currently fails, and with this change will continue to fail, because `x.py
tests` runs `x.py test src/tools/tidy` which tries to run `rustfmt` and that
will fail because the `rustfmt` binary is pinned to the current nighlty and we
do not attempt to distribute one for the beta builds.
This change gives a better error message than the current message, which is just
"./x.py fmt is not supported on this channel" without providing any hint about
what one might do about that problem.
Yuki Okushi [Tue, 16 Mar 2021 14:53:59 +0000 (23:53 +0900)]
Rollup merge of #83157 - nagisa:nagisa/portability-background, r=GuillaumeGomez
No background for code in portability snippets
This better matches the appearance of this kind of snippet in the full
item view and is less jarring to read due to repeated
foreground-background changes.
There should be no observable changes to the ayu theme.
Yuki Okushi [Tue, 16 Mar 2021 14:53:58 +0000 (23:53 +0900)]
Rollup merge of #83156 - nagisa:nagisa/sans-serif-please, r=GuillaumeGomez
Fall-back to sans-serif if Arial is not available
Otherwise on systems where Arial is not available the UA will
fallback to a serif font, rather than a sans-serif one.
This is especially relevant on acessibility-conscious setups (such as is
mine) that have web-fonts disabled and a limited set of fonts available
on the system.
Yuki Okushi [Tue, 16 Mar 2021 14:53:52 +0000 (23:53 +0900)]
Rollup merge of #81822 - Kixunil:path_try_exists, r=kennytm
Added `try_exists()` method to `std::path::Path`
This method is similar to the existing `exists()` method, except it
doesn't silently ignore the errors, leading to less error-prone code.
This change intentionally does NOT touch the documentation of `exists()`
nor recommend people to use this method while it's unstable.
Such changes are reserved for stabilization to prevent confusing people.
Apart from that it avoids conflicts with #80979.
`@joshtriplett` requested this PR in [internals discussion](https://internals.rust-lang.org/t/the-api-of-path-exists-encourages-broken-code/13817/25?u=kixunil)
bors [Tue, 16 Mar 2021 10:05:46 +0000 (10:05 +0000)]
Auto merge of #82838 - Amanieu:rustdoc_asm, r=nagisa
Allow rustdoc to handle asm! of foreign architectures
This allows rustdoc to process code containing `asm!` for architectures other than the current one. Since this never reaches codegen, we just replace target-specific registers and register classes with a dummy one.
bors [Tue, 16 Mar 2021 04:24:48 +0000 (04:24 +0000)]
Auto merge of #82898 - oli-obk:tait_🧊, r=nikomatsakis
Add a `min_type_alias_impl_trait` feature gate
This new feature gate only permits type alias impl trait to be constrained by function and trait method return types. All other possible constraining sites like const/static types, closure return types and binding types are now forbidden and gated under the `type_alias_impl_trait` and `impl_trait_in_bindings` feature gates (which are both marked as incomplete, as they have various ways to ICE the compiler or cause query cycles where they shouldn't).
Make bootstrap be more informative when one does `x.py test` on a beta checkout without other mods.
To be clear, by default running `x.py test` on a checkout of the beta branch
currently fails, and with this change will continue to fail, because `x.py
tests` runs `x.py test src/tools/tidy` which tries to run `rustfmt` and that
will fail because the `rustfmt` binary is pinned to the current nighlty and we
do not attempt to distribute one for the beta builds.
This change gives a better error message than the current message, which is just
"./x.py fmt is not supported on this channel" without providing any hint about
what one might do about that problem.
Tomasz Miąsko [Tue, 16 Mar 2021 00:00:00 +0000 (00:00 +0000)]
Use delay_span_bug instead of panic in layout_scalar_valid_range
83054 introduced validation of scalar range attributes, but panicking
code that uses the attribute remained reachable. Use `delay_span_bug`
instead to avoid the ICE.
bors [Mon, 15 Mar 2021 18:32:10 +0000 (18:32 +0000)]
Auto merge of #83121 - the8472:env-rwlock-2, r=joshtriplett
use RWlock when accessing os::env (take 2)
This reverts commit acdca316c3d42299d31c1b47eb792006ffdfc29c (#82877) i.e. redoes #81850 since the invalid unlock attempts in the child process have been fixed in #82949
This better matches the appearance of this kind of snippet in the full
item view and is less jarring to read due to repeated
foreground-background changes.
Otherwise on systems where Arial is not available the system will
fallback to a serif font, rather than a sans-serif one.
This is especially relevant on acessibility-conscious setups (such as is
mine) that have web-fonts disabled and a limited set of fonts available
on the system.
Dylan DPC [Mon, 15 Mar 2021 15:22:58 +0000 (16:22 +0100)]
Rollup merge of #83132 - Aaron1011:fix/incr-cache-dummy, r=estebank
Don't encode file information for span with a dummy location
Fixes #83112
The location information for a dummy span isn't real, so don't encode
it. This brings the incr comp cache code into line with the Span
`StableHash` impl, which doesn't hash the location information for dummy
spans.
Previously, we would attempt to load the 'original' file from a dummy
span - if the file id changed (e.g. due to being moved on disk), we would get an
ICE, since the Span was still valid due to its hash being unchanged.
Dylan DPC [Mon, 15 Mar 2021 15:22:57 +0000 (16:22 +0100)]
Rollup merge of #83127 - Aaron1011:time-macros-impl-warn, r=petrochenkov
Introduce `proc_macro_back_compat` lint, and emit for `time-macros-impl`
Now that future-incompat-report support has landed in nightly Cargo, we
can start to make progress towards removing the various proc-macro
back-compat hacks that have accumulated in the compiler.
This PR introduces a new lint `proc_macro_back_compat`, which results in
a future-incompat-report entry being generated. All proc-macro
back-compat warnings will be grouped under this lint. Note that this
lint will never actually become a hard error - instead, we will remove
the special cases for various macros, which will cause older versions of
those crates to emit some other error.
I've added code to fire this lint for the `time-macros-impl` case. This
is the easiest case out of all of our current back-compat hacks - the
crate was renamed to `time-macros`, so seeing a filename with
`time-macros-impl` guarantees that an older version of the parent `time`
crate is in use.
When Cargo's future-incompat-report feature gets stabilized, affected
users will start to see future-incompat warnings when they build their
crates.
Dylan DPC [Mon, 15 Mar 2021 15:22:52 +0000 (16:22 +0100)]
Rollup merge of #83098 - camelid:more-doc-attr-check, r=davidtwco
Find more invalid doc attributes
- Lint on `#[doc(123)]`, `#[doc("hello")]`, etc.
- Lint every attribute; e.g., will now report two warnings for `#[doc(foo, bar)]`
- Add hyphen to "crate level"
- Display paths like `#[doc(foo::bar)]` correctly instead of as an empty string
projects / rust.git / log