Restored underlying num_def_ids_method
Update compiler/rustc_metadata/src/rmeta/decoder/cstore_impl.rs
Changed name to fit with naming convention
Co-authored-by: bjorn3 <bjorn3@users.noreply.github.com>
Update compiler/rustc_metadata/src/rmeta/decoder/cstore_impl.rs
Replace regular doc with Rustdoc comment
Co-authored-by: Joshua Nelson <jyn514@gmail.com>
Clarifies third-party use of num_def_ids_untracked
Update cargo
10 commits in e931e4796b61de593aa1097649445e535c9c7ee0..0cecbd67323ca14a7eb6505900d0d7307b00355b
2021-05-24 16:17:27 +0000 to 2021-06-01 20:09:13 +0000
- Configure hosts separately from targets when --target is specified. (rust-lang/cargo#9322)
- Add some validation to rustc-link-arg (rust-lang/cargo#9523)
- Implement suggestions for unknown features in workspace (rust-lang/cargo#9420)
- Extract common `make_dep_path` to cargo_util (rust-lang/cargo#9529)
- Add a note about rustflags compatibility. (rust-lang/cargo#9524)
- Consolidate doc collision detection. (rust-lang/cargo#9526)
- Add `--depth` option for `cargo-tree` (rust-lang/cargo#9499)
- `cargo tree -e no-proc-macro` to hide procedural macro dependencies (rust-lang/cargo#9488)
- Update to semver 1.0.0 (rust-lang/cargo#9508)
- Update tar dependency to 0.4.35 (rust-lang/cargo#9517)
Use pattern matching instead of checking lengths explicitly
This piece of code checks that there are exaclty two variants, one having
exactly one field, the other having exactly zero fields. If any of these
conditions is violated, it returns `None`. Otherwise it assigns that one
field's ty to `field_ty`.
Instead of fiddling with indices and length checks explicitly, use pattern
matching to simplify this.
`@rustbot` modify labels +C-cleanup +T-compiler
Turn off frame pointer elimination on all Apple platforms.
This ends up disabling frame pointer elimination on aarch64_apple_darwin
which matches what clang does by default along with the
aarch64_apple_ios and x86_64_apple_darwin targets.
Further, the Apple docs "Writing ARM64 Code for Apple Platforms" has a section
called "Respect the Purpose of Specific CPU Registers" which
specifically calls out the frame pointer register (x29):
The frame pointer register (x29) must always address a valid frame
record. Some functions — such as leaf functions or tail calls — may
opt not to create an entry in this list As a result, stack traces
are always meaningful, even without debug information.
Other platforms are updated to not override the default.
Stabilize `vecdeque_binary_search`
This PR stabilizes the feature `vecdeque_binary_search` as tracked in #78021.
The tracking issue has not received any comments for the past 5 months, and concerns have been raised neither in the RFC rust-lang/rfcs#2997 nor in the tracking issue #78021.
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.
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.
r? `@jyn514`
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.
r? `@jsha`
This ends up disabling frame pointer elimination on aarch64_apple_darwin
which matches what clang does by default along with the
aarch64_apple_ios and x86_64_apple_darwin targets.
Further, the Apple docs "Writing ARM64 Code for Apple Platforms" has a section
called "Respect the Purpose of Specific CPU Registers" which
specifically calls out the frame pointer register (x29):
The frame pointer register (x29) must always address a valid frame
record. Some functions — such as leaf functions or tail calls — may
opt not to create an entry in this list As a result, stack traces
are always meaningful, even without debug information.
Other platforms are updated to not override the default.
