Implement (HashMap) Entry::insert as per #60142
Implementation of `Entry::insert` as per @SimonSapin's comment on #60142. This requires a patch to hashbrown:
```diff
diff --git a/src/rustc_entry.rs b/src/rustc_entry.rs
index fefa5c3..7de8300 100644
--- a/src/rustc_entry.rs
+++ b/src/rustc_entry.rs
@@ -546,6 +546,32 @@ impl<'a, K, V> RustcVacantEntry<'a, K, V> {
let bucket = self.table.insert_no_grow(self.hash, (self.key, value));
unsafe { &mut bucket.as_mut().1 }
}
+
+ /// Sets the value of the entry with the RustcVacantEntry's key,
+ /// and returns a RustcOccupiedEntry.
+ ///
+ /// # Examples
+ ///
+ /// ```
+ /// use hashbrown::HashMap;
+ /// use hashbrown::hash_map::RustcEntry;
+ ///
+ /// let mut map: HashMap<&str, u32> = HashMap::new();
+ ///
+ /// if let RustcEntry::Vacant(v) = map.rustc_entry("poneyland") {
+ /// let o = v.insert_and_return(37);
+ /// assert_eq!(o.get(), &37);
+ /// }
+ /// ```
+ #[inline]
+ pub fn insert_and_return(self, value: V) -> RustcOccupiedEntry<'a, K, V> {
+ let bucket = self.table.insert_no_grow(self.hash, (self.key, value));
+ RustcOccupiedEntry {
+ key: None,
+ elem: bucket,
+ table: self.table
+ }
+ }
}
impl<K, V> IterMut<'_, K, V> {
```
This is also only an implementation for HashMap. I tried implementing for BTreeMap, but I don't really understand BTreeMap's internals and require more guidance on implementing the equivalent `VacantEntry::insert_and_return` such that it returns an `OccupiedEntry`. Notably, following the original PR's modifications I end up needing a `Handle<NodeRef<marker::Mut<'_>, _, _, marker::LeafOrInternal>, _>` while I only have a `Handle<NodeRef<marker::Mut<'_>, _, _, marker::Internal>, _>` and don't know how to proceed.
(To be clear, I'm not asking for guidance right now; I'd be happy getting only the HashMap implementation — the subject of this PR — reviewed and ready, and leave the BTreeMap implementation for a latter PR.)
update Miri
Fixes https://github.com/rust-lang/rust/issues/64363
r? @alexcrichton for the Cargo.toml changes: with byteorder 1.3, the `i128` feature is a NOP, so we can remove it everywhere and then get rid of this crate in the workspace-hack.
Rollup of 10 pull requests
Successful merges:
- #63955 (Make sure interned constants are immutable)
- #64028 (Stabilize `Vec::new` and `String::new` as `const fn`s)
- #64119 (ci: ensure all tool maintainers are assignable on issues)
- #64444 (fix building libstd without backtrace feature)
- #64446 (Fix build script sanitizer check.)
- #64451 (when Miri tests are not passing, do not add Miri component)
- #64467 (Hide diagnostics emitted during --cfg parsing)
- #64497 (Don't print the "total" `-Ztime-passes` output if `--prints=...` is also given)
- #64499 (Use `Symbol` in two more functions.)
- #64504 (use println!() instead of println!(""))
Failed merges:
r? @ghost
when Miri tests are not passing, do not add Miri component
This makes build-manifest query the toolstate repo at https://github.com/rust-lang-nursery/rust-toolstate to figure out if the tests of the Miri component are passing. If they are not, we remove the component from the manifest, to avoid shipping a broken Miri.
I tested this locally by running build-manifest and making sure that it correctly detects the toolstate of 02785dabad as broken.
r? @pietroalbini
Cc @kennytm @alexcrichton
Fixes https://github.com/rust-lang/rust/issues/60301
Use `panic::set_hook` to print the ICE message
This allows custom frontends and backends to override the hook with their own, for example to point people to a different issue tracker.
ICE messages are printed in a slightly different order now. Nightly prints:
```
thread 'rustc' panicked at 'called `Option::unwrap()` on a `None` value', src/libcore/option.rs:347:21
note: Run with `RUST_BACKTRACE=1` environment variable to display a backtrace.
error: aborting due to 2 previous errors
Some errors have detailed explanations: E0277, E0658.
For more information about an error, try `rustc --explain E0277`.
error: internal compiler error: unexpected panic
note: the compiler unexpectedly panicked. this is a bug.
note: we would appreciate a bug report: https://github.com/rust-lang/rust/blob/master/CONTRIBUTING.md#bug-reports
note: rustc 1.36.0-nightly (08bfe1612 2019-05-02) running on x86_64-unknown-linux-gnu
```
After this PR, rustc prints:
```
thread 'rustc' panicked at 'called `Option::unwrap()` on a `None` value', src/libcore/option.rs:347:21
note: Run with `RUST_BACKTRACE=1` environment variable to display a backtrace.
error: internal compiler error: unexpected panic
note: the compiler unexpectedly panicked. this is a bug.
note: we would appreciate a bug report: https://github.com/rust-lang/rust/blob/master/CONTRIBUTING.md#bug-reports
note: rustc 1.36.0-dev running on x86_64-unknown-linux-gnu
error: aborting due to 2 previous errors
Some errors have detailed explanations: E0277, E0658.
For more information about an error, try `rustc --explain E0277`.
```
Trim rustc-workspace-hack
Those dependencies seem no longer necessary.
`./x.py test` and `x86_64-gnu-tools` container passed locally so I think this won't hurt.
This ensures that the failure cases for finding the codegen backend and
for finding the rustc binary are essentially the same, and since we
almost always will load the codegen backend, this is essentially meaning
that the rustc change is not a regression.
Update version of `rustc-std-workspace-*` crates
This commit updates the version of the `rustc-std-workspace-*` crates
in-tree which are used in `[patch]`. This will guarantee that Cargo will
select these versions even if minor updates are published to crates.io
because otherwise a newer version on crates.io would be preferred which
misses the point of `[patch]`!
This commit updates the version of the `rustc-std-workspace-*` crates
in-tree which are used in `[patch]`. This will guarantee that Cargo will
select these versions even if minor updates are published to crates.io
because otherwise a newer version on crates.io would be preferred which
misses the point of `[patch]`!
Not doing this leads to building two copies of e.g. num_cpus in the
sysroot and _llvm deps, leading to conflicts between the two when
compiling librustc_codegen_llvm. It's not entirely clear why this is the
case after the changes in this PR but likely has something to do with a
subtle difference in ordering or similar.
Rollup of 11 pull requests
Successful merges:
- #62848 (Use unicode-xid crate instead of libcore)
- #63774 (Fix `window.hashchange is not a function`)
- #63930 (Account for doc comments coming from proc macros without spans)
- #64003 (place: Passing `align` = `layout.align.abi`, when also passing `layout`)
- #64030 (Fix unlock ordering in SGX synchronization primitives)
- #64041 (use TokenStream rather than &[TokenTree] for built-in macros)
- #64051 (Add x86_64-linux-kernel target)
- #64063 (Fix const_err with `-(-0.0)`)
- #64083 (Point at appropriate arm on type error on if/else/match with one non-! arm)
- #64100 (Fix const eval bug breaking run-pass tests in Miri)
- #64157 (Opaque type locations in error message for clarity.)
Failed merges:
r? @ghost
They are only used by rustc_lexer, and are not needed elsewhere.
So we move the relevant definitions into rustc_lexer (while the actual
unicode data comes from the unicode-xid crate) and make the rest of
the compiler use it.
Since its inception rustbuild has always worked in three stages: one for
libstd, one for libtest, and one for rustc. These three stages were
architected around crates.io dependencies, where rustc wants to depend
on crates.io crates but said crates don't explicitly depend on libstd,
requiring a sysroot assembly step in the middle. This same logic was
applied for libtest where libtest wants to depend on crates.io crates
(`getopts`) but `getopts` didn't say that it depended on std, so it
needed `std` built ahead of time.
Lots of time has passed since the inception of rustbuild, however,
and we've since gotten to the point where even `std` itself is depending
on crates.io crates (albeit with some wonky configuration). This
commit applies the same logic to the two dependencies that the `test`
crate pulls in from crates.io, `getopts` and `unicode-width`. Over the
many years since rustbuild's inception `unicode-width` was the only
dependency picked up by the `test` crate, so the extra configuration
necessary to get crates building in this crate graph is unlikely to be
too much of a burden on developers.
After this patch it means that there are now only two build phasese of
rustbuild, one for libstd and one for rustc. The libtest/libproc_macro
build phase is all lumped into one now with `std`.
This was originally motivated by rust-lang/cargo#7216 where Cargo was
having to deal with synthesizing dependency edges but this commit makes
them explicit in this repository.
Update rustfmt to 1.4.5
This update includes a bug fix that fixes generating invalid code when formatting an impl block with const generics inside a where clause.
**Changes**
0462008de8...1de58ce46d
Do not emit JSON dumps of diagnostic codes
This decouples the error index generator from libsyntax for the most part (though it still depends on librustdoc for the markdown parsing and generation).
Fixes#34588
This commit changes the lock file format of this repository to an
experimental format that isn't rolled out by default in Cargo but is
intended to eventually become the default. The new format moves
information around and compresses the lock file a bit. The intention of
the new format is to reduce the amount of git merge conflicts that
happen in a repository, with rust-lang/rust being a prime candidate for
testing this.
The new format wille ventually become the default but for now it is
off-by-default in Cargo, but Cargo will preserve the format if it sees
it. Since we always build with a beta version of Cargo for the
rust-lang/rust repository it should be safe to go ahead and change the
lock file format here and everyone building this repository will
automatically pick it up.
It's intended that we'll evaluate this lock file format in the
rust-lang/rust repository to see if it reduces the number of perceived
merge conflicts for changes that touch the lock file. This will in turn
help inform the development of the feature in Cargo and whether we
choose to stabilize this and turn it on by default.
Note that this commit does not actually change the contents of the lock
file in terms of a resolution graph, it simply reencodes the lock file
with a new format.
This commit updates the `backtrace` crate from 0.3.34 to 0.3.35. The
[included set of changes][changes] for this update mostly includes some
gimli-related improvements (not relevant for the standard library) but
critically includes a fix for rust-lang/backtrace-rs#230. The standard
library will not aqcuire a session-local lock whenever a backtrace is
generated on Windows to allow external synchronization with the
`backtrace` crate itself, allowing `backtrace` to be safely used while
other threads may be panicking.
[changes]: https://github.com/rust-lang/backtrace-rs/compare/0.3.34...0.3.35
This drops the parking_lot dependency; the ReentrantMutex type appeared
to be unused (at least, no compilation failures occurred).
This is technically a possible change in behavior of its users, as
lock() would wait on other threads releasing their guards, but since we
didn't actually remove any threading or such in this code, it appears
that we never used that behavior (the behavior change is only noticeable
if the type previously was used in two threads, in a single thread
ReentrantMutex is useless).
bump rand in libcore/liballoc test suites
This pulls in the fix for https://github.com/rust-random/rand/issues/779, which trips Miri when running these test suites.
`SmallRng` (formerly used by libcore) is no longer built by default, it needs a feature gate. I opted to switch to `StdRng` instead. Or should I enable the feature gate?
Deduplicate rustc_demangle in librustc_codegen_llvm
This commit removes the crates.io dependency of `rustc-demangle` from
`rustc_codegen_llvm`. This crate is actually already pulled in to part
of the `librustc_driver` build and with the upcoming pipelining
implementation in Cargo it causes build issues if `rustc-demangle` is
left to its own devices.
This is not currently required, but once pipelining is enabled for
rustc's own build it will be required to build correctly.
This commit removes the crates.io dependency of `rustc-demangle` from
`rustc_codegen_llvm`. This crate is actually already pulled in to part
of the `librustc_driver` build and with the upcoming pipelining
implementation in Cargo it causes build issues if `rustc-demangle` is
left to its own devices.
This is not currently required, but once pipelining is enabled for
rustc's own build it will be required to build correctly.
Some fixes for i686-msvc and Windows have landed on the `backtrace`
crate but hadn't made their way here yet. Let's update that and see if
it passes CI.
Last two commits bumped rustc-ap-* crates which also transitively
updated rustc_data_structures. That crate enables the "nightly"
whereas Cargo's dep does not hence why we need to unify the features
to deduplicate the artifacts.
bump crossbeam-epoch dependency
The new crossbeam-epoch release depends on a memoffset with a whole bunch of soundness holes fixed.
The old memoffset is still indirectly depended on (at least) by rustc-rayon, though -- a crate that looks rather unmaintained (no change in more than a year).
The idea here is to make a reusable library out of the existing
rust-lexer, by separating out pure lexing and rustc-specific concerns,
like spans, error reporting an interning.
So, rustc_lexer operates directly on `&str`, produces simple tokens
which are a pair of type-tag and a bit of original text, and does not
report errors, instead storing them as flags on the token.
This commit updates some of our assorted Azure/CI configuration to
prepare for some 4-core machines coming online. We're still in the
process of performance testing them to get final numbers, but some
changes are worth landing ahead of this. The updates here are:
* Use `C:/` instead of `D:/` for submodule checkout since it should have
plenty of space and the 4-core machines won't have `D:/`
* Update `lzma-sys` to 0.1.14 which has support for VS2019, where 0.1.10
doesn't.
* Update `src/ci/docker/run.sh` to work when it itself is running inside
of a docker container (see the comment in the file for more info)
* Print step timings on the `try` branch in addition to the `auto`
branch in. The logs there should be seen by similarly many humans (not
many) and can be useful for performance analysis after a `try` build
runs.
* Install the WIX and InnoSetup tools manually on Windows instead of
relying on pre-installed copies on the VM. This gives us more control
over what's being used on the Azure cloud right now (we control the
version) and in the 4-core machines these won't be pre-installed. Note
that on AppVeyor we actually already were installing InnoSetup, we
just didn't carry that over on Azure!
Update linked OpenSSL version
This bumps our linked OpenSSL version from 1.1.1a to 1.1.1c, picking up
some various bug fixes and minor security issue fixes.
This pulls in a commit which uses parallel xz encoding which should
hopefully help shave some time off the dist builders which spend an
inordinate amount of time compressing this data.
std: Remove internal definitions of `cfg_if!` macro
This is duplicated in a few locations throughout the sysroot to work
around issues with not exporting a macro in libstd but still wanting it
available to sysroot crates to define blocks. Nowadays though we can
simply depend on the `cfg-if` crate on crates.io, allowing us to use it
from there!
Use Symbol, Span in libfmt_macros
I'm not super happy with this, personally, but I think it might be a decent start -- happy to take suggestions as to how to expand this or change things further.
r? @estebank
Fixes#60795
This is duplicated in a few locations throughout the sysroot to work
around issues with not exporting a macro in libstd but still wanting it
available to sysroot crates to define blocks. Nowadays though we can
simply depend on the `cfg-if` crate on crates.io, allowing us to use it
from there!
Discovered in #61416 an accidental regression in libstd's backtrace
behavior is that it previously attempted to consult libbacktrace and
would then fall back to `dladdr` if libbacktrace didn't report anything.
The `backtrace` crate, however, did not do this, so that's now been
fixed!
Changes: https://github.com/rust-lang/backtrace-rs/compare/0.3.25...0.3.27Closes#61416
This adds a new diagnostic writer `AnnotateRsEmitterWriter` that uses
the [`annotate-snippet`][as] library to print out the human readable
diagnostics.
The goal is to eventually switch over to using the library instead of
maintaining our own diagnostics output.
This commit does *not* add all the required features to the new
diagnostics writer. It is only meant as a starting point so that other
people can contribute as well.
[as]: https://github.com/rust-lang/annotate-snippets-rs
strip synstructure consts from compiler docs
Fixes#60150.
Unfortunately this PR depends on the use of the deprecated `--passes` flag in bootstrap to keep the `--strip-hidden` pass while still documenting private items. I've opened #60884 to track stabilization of a new flag that encapsulates this behavior.
r? @QuietMisdreavus
This commit removes all in-tree support for generating backtraces in
favor of depending on the `backtrace` crate on crates.io. This resolves
a very longstanding piece of duplication where the standard library has
long contained the ability to generate a backtrace on panics, but the
code was later extracted and duplicated on crates.io with the
`backtrace` crate. Since that fork each implementation has seen various
improvements one way or another, but typically `backtrace`-the-crate has
lagged behind libstd in one way or another.
The goal here is to remove this duplication of a fairly critical piece
of code and ensure that there's only one source of truth for generating
backtraces between the standard library and the crate on crates.io.
Recently I've been working to bring the `backtrace` crate on crates.io
up to speed with the support in the standard library which includes:
* Support for `StackWalkEx` on MSVC to recover inline frames with
debuginfo.
* Using `libbacktrace` by default on MinGW targets.
* Supporting `libbacktrace` on OSX as an option.
* Ensuring all the requisite support in `backtrace`-the-crate compiles
with `#![no_std]`.
* Updating the `libbacktrace` implementation in `backtrace`-the-crate to
initialize the global state with the correct filename where necessary.
After reviewing the code in libstd the `backtrace` crate should be at
exact feature parity with libstd today. The backtraces generated should
have the same symbols and same number of frames in general, and there's
not known divergence from libstd currently.
Note that one major difference between libstd's backtrace support and
the `backtrace` crate is that on OSX the crates.io crate enables the
`coresymbolication` feature by default. This feature, however, uses
private internal APIs that aren't published for OSX. While they provide
more accurate backtraces this isn't appropriate for libstd distributed
as a binary, so libstd's dependency on the `backtrace` crate explicitly
disables this feature and forces OSX to use `libbacktrace` as a
symbolication strategy.
The long-term goal of this refactoring is to eventually move us towards
a world where we can drop `libbacktrace` entirely and simply use Gimli
and the surrounding crates for backtrace support. That's still aways off
but hopefully will much more easily enabled by having the source of
truth for backtraces live in crates.io!
Procedurally if we go forward with this I'd like to transfer the
`backtrace-rs` crate to the rust-lang GitHub organization as well, but I
figured I'd hold off on that until we get closer to merging.
This commit bumps the `compiler-builtins` dependency to 0.1.15 which
expects to have the source for `compiler-rt` provided externally if the
`c` feature is enabled. This then plumbs through the necessary support
in the build system to ensure that if the `llvm-project` directory is
checked out and present that we enable the `c` feature of
`compiler-builtins` and compile in all the C intrinsics.
This updates to 0.1.13 for `compiler_builtins`, published to fix a few
issues. The feature changes here are updated because `compiler_builtins`
no longer enables the `c` feature by default but we want to do so
through our build still.
Closes#60747Closes#60782
`find_attr_val(&line, "since")` returns `Some(", issue = ")` when
`line` is set to the following line:
```
[unstable(feature = "checked_duration_since", issue = "58402")]
```
Make `find_attr_val` use regex that is a little bit more
precise (requires `=` after key name).
It still does not handle all cases (e.g., extra leading chars in key
name, or escaped quotes in value), but is good enough for now.
The commit moves metadata writing from `link_binary` to
`encode_metadata` (and renames the latter as
`encode_and_write_metadata`). This is at the very start of code
generation.
Fix index-page generation
Fixes#60096.
The minifier was minifying crates name in `searchIndex` key position, which was a bit problematic for multiple reasons.
r? @rust-lang/rustdoc
Changes:
````
Rustup for https://github.com/rust-lang/rust/pull/59042
Update pulldown_cmark to 0.5
Only run AppVeyor on r+, try and the master branch
Remove approx_constant known problems
Suppress let_and_return if let has attributes
Add test for or_fun_call macro suggestion
UI test cleanup: Extract needless_range_loop tests
Change "if types change" to "if you later change the type"
````
This also bumps RLS version to 1.36.
The updated rls-* packages use serde but *not* serde_derive thanks to
manual proc macro expansion. This is a hack, since rustc cannot handle
crates.io proc macros (duplicated in tools) when cross-compiling, so
that's the best we can do in order to support serde_json in save-analysis.
Changes:
````
Update compiletest_rs
Typo
Fix dogfood error
Add lint PathBufPushOverwrite
Update *.stderr file
Remove code duplication
Format code
Add test for debug_assert!(false)
Don't lint debug_assert!(false)
Add run-rustfix for option_map_or_none lint
Move two cast_lossless tests to their correct files
Change naive_bytecount applicability MaybeIncorrect
Add tests for declare_lint_pass and impl_lint_pass
Use lint pass macros
Document `declare_lint_pass!`
Fix lint_without_lint_pass internal lint
Use {get,match}_def_path from LateContext
Remove uplifted functions {get,match}_def_path from Clippy
Add run-rustfix for len_zero lint
Add run-rustfix for bool_comparison lint
Add run-rustfix for deref_addrof lint
while_let_loop uses placeholders in suggestions
Remove rust-toolchain file from clippy_dev
Update adding_lints.md
Update PULL_REQUEST_TEMPLATE
Add new lint checklist
Create PULL_REQUEST_TEMPLATE
Only suggest .copied() for Option right now
Also suggest .copied() when .clone() is called on a Copy type
Suggest .copied() instead of .cloned() in map_clone when dealing with references
Deny rustc internal lints
Remove clippy::default_hash_types internal lint
Enable -Zunstable-options in .cargo/config
````
update polonius-engine
This updates polonius-engine to [version 0.7.0](https://github.com/rust-lang/polonius/blob/master/RELEASES.md#v070), which adds a hybrid algorithm that starts off with performing a cheaper, location-insensitive analysis before proceeding with the full analysis.
r? @nikomatsakis
Turns out we needed to exclude a number of math functions on the
`wasm32-unknown-wasi` target, and this was fixed in 0.1.9 of
compiler-builtins and this is pulling in the fix to libstd's own build.
