Add Weak.ptr_eq
I hope the doc tests alone are good enough.
We also might want to discuss the dangling pointer case (from `Weak::new()`).
Updates #55981.
Document `From` implementations
This PR is solves part of https://github.com/rust-lang/rust/issues/51430. It's my first PR, so I might need some guidance from @skade (as already mentioned in the issue).
The purpose of the PR is to document the `impl From` inside `path.rs` and answering the questions:
- What does it convert?
- Does it allocate memory?
- How expensive are the allocations?
I gave it a first shot, though an experienced rust developer might want to look over it.
submodules: update clippy from b2601beb to 29bf75cd
Changes:
````
Fix ty::TyKind usage
Fix TyKind::<kind> usage in codebase
Extract single_match_else UI test
cargo fmt
Adds inequality cases to bool comparison lint
Remove unsafe_vector_initialization lint
Fix wildcard_dependencies false positive
Fix rustfmt format
Disable incremental build for windows
Travis: Add rustc sysroot bin to PATH for windows build
Fix some nursery links
Enforce LF lineendings for everything
Mention triage procedure in contributing.md
Keep testing large_digit_groups as ui test
Keep testing unsafe_vector_initialization as ui test
Downgrade large_digit_groups to pedantic
Downgrade unsafe_vector_initialization to restriction
remove macro_at_most_once_rep feature attribute since it's stable
Add missing word
Update docs in regards to the merged RFC
Document how to run rustfmt in CONTRIBUTING.md
Don't run integration tests in forks
Fix some formatting issues
Run rustfmt on clippy_lints
Run rustfmt on build.rs
Run rustfmt on clippy_dev
Run rustfmt on rustc_tools_util
Run rustfmt on src
Run rustfmt on the tests
Let travis run cargo fmt --all -- --check
Error on line overflow
````
No need to increase priority, please just rollup :)
Changes:
````
Fix ty::TyKind usage
Fix TyKind::<kind> usage in codebase
Extract single_match_else UI test
cargo fmt
Adds inequality cases to bool comparison lint
Remove unsafe_vector_initialization lint
Fix wildcard_dependencies false positive
Fix rustfmt format
Disable incremental build for windows
Travis: Add rustc sysroot bin to PATH for windows build
Fix some nursery links
Enforce LF lineendings for everything
Mention triage procedure in contributing.md
Keep testing large_digit_groups as ui test
Keep testing unsafe_vector_initialization as ui test
Downgrade large_digit_groups to pedantic
Downgrade unsafe_vector_initialization to restriction
remove macro_at_most_once_rep feature attribute since it's stable
Add missing word
Update docs in regards to the merged RFC
Document how to run rustfmt in CONTRIBUTING.md
Don't run integration tests in forks
Fix some formatting issues
Run rustfmt on clippy_lints
Run rustfmt on build.rs
Run rustfmt on clippy_dev
Run rustfmt on rustc_tools_util
Run rustfmt on src
Run rustfmt on the tests
Let travis run cargo fmt --all -- --check
Error on line overflow
````
syntax: Use iterator and pattern APIs instead of `char_at`
Iterating over chars with the `char_at(str, i)` `i += ch.len_utf8()` loop seems unidiomatic.
update edition guide
spiritual successor to https://github.com/rust-lang/rust/pull/56457
not to be backported, being in nightly is enough.
i'm testing this locally now but figure travis can test it in parallel
Propagate all closure requirements to the caller
Closes#56477
This should be backported to 1.32 if it doesn't make the cut.
r? @pnkfelix
cc @nikomatsakis
codegen_llvm_back: improve allocations
This commit was split out from https://github.com/rust-lang/rust/pull/54864. Last time it was causing an LLVM OOM, which was most probably caused by not collecting the globals.
- preallocate vectors of known length
- `extend` instead of `append` where the argument is consumable
- turn 2 `push` loops into `extend`s
- create a vector from a function producing one instead of using `extend_from_slice` on it
- consume `modules` when no longer needed
- ~~return an `impl Iterator` from `generate_lto_work`~~
- ~~don't `collect` `globals`, as they are iterated over and consumed right afterwards~~
While I'm hoping it won't cause an OOM anymore, I would still consider this a "high-risk" PR and not roll it up.
Rollup of 13 pull requests
Successful merges:
- #56141 ([std] Osstr len clarity)
- #56366 (Stabilize self_in_typedefs feature)
- #56395 (Stabilize dbg!(...))
- #56401 (Move VecDeque::resize_with out of the impl<T:Clone> block)
- #56402 (Improve the unstable book example for #[marker] trait)
- #56412 (Update tracking issue for `extern_crate_self`)
- #56416 (Remove unneeded body class selector)
- #56418 (Fix failing tidy (line endings on Windows))
- #56419 (Remove some uses of try!)
- #56432 (Update issue number of `shrink_to` methods to point the tracking issue)
- #56433 (Add description about `crate` for parse_visibility's comment)
- #56435 (make the C part of compiler-builtins opt-out)
- #56438 (Remove not used `DotEq` token)
Failed merges:
r? @ghost
Remove not used `DotEq` token
Currently libproc_macro does not use `DotEq` token.
https://github.com/rust-lang/rust/pull/49545 changed libproc_macro
to not generate `DotEq` token.
make the C part of compiler-builtins opt-out
I'd like to be able to use Xargo to build a libstd without having a full C toolchain for the target. This is a start (but the fact that libstd is a dylib is still a problem).
However, compiler_builtin already has somewhat similar logic to not require a C compiler for wasm:
fe74674f6e/build.rs (L36-L41)
(WTF GitHub, why doesn't this show an embedded code preview??)
I wonder if there is a way to not have two separate mechanisms? Like, move the above wasm logic to some place that controls the libstd feature, or so? Or is it okay to have these two mechanisms co-exist?
Cc @alexcrichton
Improve the unstable book example for #[marker] trait
The previous one didn't actually use the Display&Debug bounds in any way, so I think this one is a bit more meaningful.
Stabilize dbg!(...)
Per FCP in https://github.com/rust-lang/rust/issues/54306 (which is ~1 day from completion).
r? @SimonSapin
The PR is fairly isolated so a rollup should probably work.
