bors [Thu, 3 Jun 2021 05:12:31 +0000 (05:12 +0000)]
Auto merge of #84988 - alexcrichton:safe-target-feature-wasm, r=joshtriplett
rustc: Allow safe #[target_feature] on wasm
This commit updates the compiler's handling of the `#[target_feature]`
attribute when applied to functions on WebAssembly-based targets. The
compiler in general requires that any functions with `#[target_feature]`
are marked as `unsafe` as well, but this commit relaxes the restriction
for WebAssembly targets where the attribute can be applied to safe
functions as well.
The reason this is done is that the motivation for this feature of the
compiler is not applicable for WebAssembly targets. In general the
`#[target_feature]` attribute is used to enhance target CPU features
enabled beyond the basic level for the rest of the compilation. If done
improperly this means that your program could execute an instruction
that the CPU you happen to be running on does not understand. This is
considered undefined behavior where it is unknown what will happen (e.g.
it's not a deterministic `SIGILL`).
For WebAssembly, however, the target is different. It is not possible
for a running WebAssembly program to execute an instruction that the
engine does not understand. If this were the case then the program would
not have validated in the first place and would not run at all. Even if
this were allowed in some hypothetical future where engines have some
form of runtime feature detection (which they do not right now) any
implementation of such a feature would generate a trap if a module
attempts to execute an instruction the module does not understand. This
deterministic trap behavior would still not fall into the category of
undefined behavior because the trap is deterministic.
For these reasons the `#[target_feature]` attribute is now allowed on
safe functions, but only for WebAssembly targets. This notably enables
the wasm-SIMD intrinsics proposed for stabilization in #74372 to be
marked as safe generally instead of today where they're all `unsafe` due
to the historical implementation of `#[target_feature]` in the compiler.
bors [Thu, 3 Jun 2021 02:31:44 +0000 (02:31 +0000)]
Auto merge of #84834 - GuillaumeGomez:sidebar-unification, r=jsha
Sidebar unification
This PR does a few things:
* Put crates list at all levels (before, it was only on the "top" items)
* Fix bug in module sidebar: the list of items was from the parent module.
The other changes (on bootstrap mostly) were to allow to generate multiple crates in a same folder so that we can ensure that clicking on the crates in the sidebar works as expected.
I added a rustdoc-gui test to ensure everything is where it should be.
bors [Wed, 2 Jun 2021 23:11:41 +0000 (23:11 +0000)]
Auto merge of #84703 - GuillaumeGomez:cleanup-dom, r=jsha
Clean up dom
The commits come from #84480.
They were errors reported by the `tidy` script that we will use to ensure that the HTML generated by rustdoc is valid.
I checked carefully that there were no difference so in principle it should be exactly the same rendering but a double-check would be very appreciated in case I missed something.
Extra note: `<h4>` and some `<h3>` tags were replaced by `<div>` because they're not supposed to contain tags as they currently do.
bors [Wed, 2 Jun 2021 13:11:41 +0000 (13:11 +0000)]
Auto merge of #85337 - cjgillot:less-anon, r=michaelwoerister
Avoid creating anonymous nodes with zero or one dependency.
Anonymous nodes are only useful to encode dependencies, and cannot be replayed from one compilation session to another.
As such, anonymous nodes without dependency are always green.
Anonymous nodes with only one dependency are equivalent to this dependency.
Guillaume Gomez [Tue, 1 Jun 2021 09:29:44 +0000 (11:29 +0200)]
Rollup merge of #85826 - jsha:npo, r=joshtriplett
Mention "null pointer optimization" in option docs.
I had seen people discuss "null pointer optimization," but when I tried to find official documentation (using Google), the `std::option` page didn't show up, because it doesn't use that term. Hopefully adding the term will help others find it in the future.
Guillaume Gomez [Tue, 1 Jun 2021 09:29:43 +0000 (11:29 +0200)]
Rollup merge of #85622 - jsha:untoggle-undocumented, r=GuillaumeGomez
Remove toggle for "undocumented items."
Per discussion in #84326. For trait implementations, this was
misleading: the items actually do have documentation (but it comes from
the trait definition).
For both trait implementations and trait implementors, this was
redundant: in both of those cases, the items are default-hidden by
different toggle at the level above.
Update tests: Remove XPath selectors that over-specified on details tag,
in cases that weren't testing toggles. Add an explicit test for toggles
on methods. Rename item-hide-threshold to toggle-item-contents for
consistency.
bors [Tue, 1 Jun 2021 00:51:00 +0000 (00:51 +0000)]
Auto merge of #85153 - cjgillot:qresolve, r=Aaron1011
Reduce the amount of untracked state in TyCtxt
Access to untracked global state may generate instances of #84970.
The GlobalCtxt contains the lowered HIR, the resolver outputs and interners.
By wrapping the resolver inside a query, we make sure those accesses are properly tracked.
As a no_hash query, all dependent queries essentially become `eval_always`,
what they should have been from the beginning.
bors [Mon, 31 May 2021 20:03:18 +0000 (20:03 +0000)]
Auto merge of #85702 - Aaron1011:no-vec-sort, r=michaelwoerister
Don't sort a `Vec` before computing its `DepTrackingHash`
Previously, we sorted the vec prior to hashing, making the hash
independent of the original (command-line argument) order. However, the
original vec was still always kept in the original order, so we were
relying on the rest of the compiler always working with it in an
'order-independent' way.
This assumption was not being upheld by the `native_libraries` query -
the order of the entires in its result depends on the order of entries
in `Options.libs`. This lead to an 'unstable fingerprint' ICE when the
`-l` arguments were re-ordered.
This PR removes the sorting logic entirely. Re-ordering command-line
arguments (without adding/removing/changing any arguments) seems like a
really niche use case, and correctly optimizing for it would require
additional work. By always hashing arguments in their original order, we
can entirely avoid a cause of 'unstable fingerprint' errors.
bors [Mon, 31 May 2021 07:32:50 +0000 (07:32 +0000)]
Auto merge of #85395 - 12101111:build-crt, r=petrochenkov
Build crtbegin.o/crtend.o from source code
Build crtbengin.o/crtend.o from source code instead of copying from gcc.
The crtbegin and crtend implementation from llvm don't need `crtbeginS.o` for PIC. `crtbegin{,S,T}.o` is unified into one generic `crtbegin.o`. See the comments in https://reviews.llvm.org/D28791#1419436 and https://reviews.llvm.org/D28791#1420914
bors [Mon, 31 May 2021 05:03:26 +0000 (05:03 +0000)]
Auto merge of #85819 - CDirkx:is_unicast_link_local_strict, r=joshtriplett
Remove `Ipv6Addr::is_unicast_link_local_strict`
Removes the unstable method `Ipv6Addr::is_unicast_link_local_strict` and keeps the behaviour of `Ipv6Addr::is_unicast_link_local`, see also #85604 where I have tried to summarize related discussion so far.
My intent is for `is_unicast_link_local`, `is_unicast_site_local` and `is_unicast_global` to have the semantics of checking if an address has Link-Local, Site-Local or Global scope, see also #85696 which changes the behaviour of `is_unicast_global` and renames these methods to `has_unicast_XXX_scope` to reflect this.
For checking Link-Local scope we currently have two methods: `is_unicast_link_local` and `is_unicast_link_local_strict`. This is because of what appears to be conflicting definitions in [IETF RFC 4291](https://datatracker.ietf.org/doc/html/rfc4291).
With `is_unicast_link_local` checking `FE80::/10` and `is_unicast_link_local_strict` checking `FE80::/64`.
There is also [IETF RFC 5156 section 2.4](https://datatracker.ietf.org/doc/html/rfc5156#section-2.4) which defines "Link-Scoped Unicast" as `FE80::/10`.
It has been pointed out that implementations in other languages and the linux kernel all use `FE80::/10` (https://github.com/rust-lang/rust/pull/76098#issuecomment-706916840, https://github.com/rust-lang/rust/pull/76098#issuecomment-705928605).
Given all of this I believe the correct interpretation to be the following: All addresses in `FE80::/10` are defined as having Link-Local scope, however currently only the block `FE80::/64` has been allocated for "Link-Local IPv6 Unicast Addresses". This might change in the future however; more addresses in `FE80::/10` could be allocated and those will have Link-Local scope. I therefore believe the current behaviour of `is_unicast_link_local` to be correct (if interpreting it to have the semantics of `has_unicast_link_local_scope`) and `is_unicast_link_local_strict` to be unnecessary, confusing and even a potential source of future bugs:
Currently there is no real difference in checking `FE80::/10` or `FE80::/64`, since any address in practice will be `FE80::/64`. However if an application uses `is_unicast_link_local_strict` to implement link-local (so non-global) behaviour, it will be incorrect in the future if addresses outside of `FE80::/64` are allocated.
r? `@joshtriplett` as reviewer of all the related PRs
Per discussion in #84326. For trait implementations, this was
misleading: the items actually do have documentation (but it comes from
the trait definition).
For both trait implementations and trait implementors, this was
redundant: in both of those cases, the items are default-hidden by
different toggle at the level above.
Update tests: Remove XPath selectors that over-specified on details tag,
in cases that weren't testing toggles. Add an explicit test for toggles
on methods. Rename item-hide-threshold to toggle-item-contents for
consistency.
bors [Sun, 30 May 2021 20:20:44 +0000 (20:20 +0000)]
Auto merge of #85838 - GuillaumeGomez:rollup-rk2rh7m, r=GuillaumeGomez
Rollup of 8 pull requests
Successful merges:
- #85285 (Add eslint checks to CI)
- #85709 (Use correct edition when parsing `:pat` matchers)
- #85762 (Do not try to build LLVM with Zlib on Windows)
- #85770 (Remove `--print unversioned-files` from rustdoc )
- #85781 (Add documentation for aarch64-apple-ios-sim target)
- #85801 (Add `String::extend_from_within`)
- #85817 (Fix a typo)
- #85818 (Don't drop `PResult` without handling the error)
Guillaume Gomez [Sun, 30 May 2021 19:06:51 +0000 (21:06 +0200)]
Rollup merge of #85801 - WaffleLapkin:master, r=joshtriplett
Add `String::extend_from_within`
This PR adds `String::extend_from_within` function under the `string_extend_from_within` feature gate similar to the [`Vec::extend_from_within`] function.
We do not install Zlib on the CI but recent builds somehow started picking it's shared version.
To avoid relying on CI binaries so let's explicitly disable it.
Guillaume Gomez [Sun, 30 May 2021 19:06:44 +0000 (21:06 +0200)]
Rollup merge of #85709 - Aaron1011:fix-pat-crate-edition, r=petrochenkov
Use correct edition when parsing `:pat` matchers
As described in issue #85708, we currently do not properly decode
`SyntaxContext::root()` and `ExpnId::root()` from foreign crates. As a
result, when we decode a span from a foreign crate with
`SyntaxContext::root()`, we end up up considering it to have the edition
of the *current* crate, instead of the foreign crate where it was
originally created.
A full fix for this issue will be a fairly significant undertaking.
Fortunately, it's possible to implement a partial fix, which gives us
the correct edition-dependent behavior for `:pat` matchers when the
macro is loaded from another crate. Since we have the edition of the
macro's defining crate available, we can 'recover' from seeing a
`SyntaxContext::root()` and use the edition of the macro's defining
crate.
Any solution to issue #85708 must reproduce the behavior of this
targeted fix - properly preserving a foreign `SyntaxContext::root()`
means (among other things) preserving its edition, which by definition
is the edition of the foreign crate itself. Therefore, this fix moves us
closer to the correct overall solution, and does not expose any new
incorrect behavior to macros.
bors [Sun, 30 May 2021 17:39:45 +0000 (17:39 +0000)]
Auto merge of #85362 - jsgf:fix-emit-metadata, r=estebank
Use command line metadata path if provided
If the command-line has `--emit metadata=some/path/libfoo.rmeta` then
use that.
Closes #85356
I couldn't find any existing tests for the `--emit TYPE=PATH` command line syntax, so I wasn't sure how to test this aside from ad-hoc manual testing. Is there a ui test type for "generated output file with expected name"?
bors [Sun, 30 May 2021 07:25:38 +0000 (07:25 +0000)]
Auto merge of #85786 - GuillaumeGomez:error-code-checker-improvement, r=Mark-Simulacrum
Error code checker improvement
Just realized that some error codes shouldn't be ignored anymore. So I updated the script to ensure that if an error code is tested and ignored, it will trigger an error.
bors [Sun, 30 May 2021 01:21:39 +0000 (01:21 +0000)]
Auto merge of #83772 - jhpratt:revamp-step-trait, r=Mark-Simulacrum
Make `Step` trait safe to implement
This PR makes a few modifications to the `Step` trait that I believe better position it for stabilization in the short term. In particular,
1. `unsafe trait TrustedStep` is introduced, indicating that the implementation of `Step` for a given type upholds all stated invariants (which have remained unchanged). This is gated behind a new `trusted_step` feature, as stabilization is realistically blocked on min_specialization.
2. The `Step` trait is internally specialized on the `TrustedStep` trait, which avoids a serious performance regression.
3. `TrustedLen` is implemented for `T: TrustedStep` as the latter's invariants subsume the former's.
4. The `Step` trait is no longer `unsafe`, as the invariants must not be relied upon by unsafe code (unless the type implements `TrustedStep`).
5. `TrustedStep` is implemented for all types that implement `Step` in the standard library and compiler.
6. The `step_trait_ext` feature is merged into the `step_trait` feature. I was unable to find any reasoning for the features being split; the `_unchecked` methods need not necessarily be stabilized at the same time, but I think it is useful to have them under the same feature flag.
All existing implementations of `Step` will be broken, as it is not possible to `unsafe impl` a safe trait. Given this trait only exists on nightly, I feel this breakage is acceptable. The blanket `impl<T: Step> TrustedLen for T` will likely cause some minor breakage, but this should be covered by the equivalent impl for `TrustedStep`.
Hopefully these changes are sufficient to place `Step` in decent position for stabilization, which would allow user-defined types to be used with `a..b` syntax.