When a library (L1) is passed to the linker multiple times, this is
sometimes purposeful: there might be several other libraries in the
linker command (L2 and L3) that all depend on L1. You'd end up with a
(simplified) linker command that looks like:
-l2 -l1 -l3 -l1
With the previous behavior, when rustc encountered a redundant library,
it would keep the first instance, and remove the later ones, resulting
in:
-l2 -l1 -l3
This can cause a linker error, because on some platforms (e.g. Linux),
the linker will only include symbols from L1 that are needed *at the
point it's referenced in the command line*. So if L3 depends on
additional symbols from L1, which aren't needed by L2, the linker won't
know to include them, and you'll end up with "undefined symbols" errors.
A better behavior is to keep the *last* instance of the library:
-l2 -l3 -l1
This ensures that all "downstream" libraries have been included in the
linker command before the "upstream" library is referenced.
Fixes rust-lang#47989
trigger unsized coercions keyed on Sized bounds
This PR causes unsized coercions to not be disabled by `$0: Unsize<dyn
Object>` coercion obligations when we have an `$0: Sized` obligation somewhere.
This should be mostly backwards-compatible, because in these cases not doing the unsize coercion should have caused the `$0: Sized` obligation to fail.
Note that `X: Unsize<dyn Object>` obligations can't fail *as obligations* if `X: Sized` holds, so this still maintains some version of monotonicity (I think that an unsized coercion can't be converted to no coercion by unifying type variables).
Fixes#49593 (unblocking never_type).
r? @eddyb
cc @nikomatsakis
Rollup of 15 pull requests
Successful merges:
- #56363 (Defactored Bytes::read)
- #56663 (Remove lifetime from Resolver)
- #56689 (add a lint group for lints emitted by rustdoc)
- #56772 (fix issue 54153 by not testing issue-18804 on Windows nor OS X.)
- #56820 (format-related tweaks)
- #56881 (Implement Eq, PartialEq and Hash for atomic::Ordering)
- #56907 (Fix grammar in compiler error for array iterators)
- #56908 (rustc: Don't ICE on usage of two new target features)
- #56910 (Do not point at delim spans for complete correct blocks)
- #56913 (Enable stack probes for UEFI images)
- #56918 (Profiler: simplify total_duration, improve readability)
- #56931 (Update release notes for Rust 1.31.1)
- #56947 (Add targets thumbv7neon-linux-androideabi and thumbv7neon-unknown-linux-gnueabihf)
- #56948 (Update LLVM submodule)
- #56959 (Fix mobile menu rendering collision with tooltip.)
Failed merges:
- #56914 (Ignore ui/target-feature-gate on sparc, sparc64, powerpc, powerpc64 and powerpc64le)
r? @ghost
Add targets thumbv7neon-linux-androideabi and thumbv7neon-unknown-linux-gnueabihf
These two targets enable both thumb-mode and NEON for ARMv7 CPUs.
This another attempt at #49902, which cannot be reopened. Between that PR and this one, some subrepos with C code whose build systems were failing went away.
Enable stack probes for UEFI images
When building UEFI images, we don't link to any CRT libraries so we need to provide a stack probe. Without `__rust_probestack`, the linker looks for `__chkstk` and fails to link if there is a function with large local variables.
r? @alexcrichton
Fix grammar in compiler error for array iterators
This fixes a small grammatical mistake in the message the compiler gives when attempting to iterate directly over an array `arr` without calling `arr.iter()` or borrowing `&arr`.
add a lint group for lints emitted by rustdoc
As rustdoc adds more lints that it specifically manages, it would be nice to be able to lump them all together. This gives us a new group just for that.
I deliberately didn't include `missing_docs` because this is kind of a stepping stone for moving our lints into tool lints (i.e. `#![warn(rustdoc::private_doc_tests)]`), since all of these are specifically emitted by rustdoc. If we want to move `missing_docs` out of the compiler, that's also an option, but it would create a surprising change of behavior.
I also took the chance to rewrite the lint descriptions of these lints to better match the style of the other lints. `>_>`
Defactored Bytes::read
Removed unneeded refactoring of read_one_byte, which removed the unneeded dynamic dispatch (`dyn Read`) used by that function.
This function is only used in one place in the entire Rust codebase; there doesn't seem to be a reason for it to exist (and there especially doesn't seem to be a reason for it to use dynamic dispatch)
Short-circuit Rc/Arc equality checking on equal pointers where T: Eq
based on #42965
Is the use of the private trait ok this way? Is there anything else needed for this to get pulled?
Search other library paths when loking for link objects
Support the case when link objects are not located in Rust sysroot
but in other locations which could be specify through library paths.
fix trait objects with a Self-containing projection values
Fixes#56288.
This follows ALT2 in the issue.
beta-nominating since this is a regression.
r? @nikomatsakis
Fix various aspects around `let` bindings inside const functions
* forbid `let` bindings in const contexts that use short circuiting operators
* harden analysis code against derefs of mutable references
Initially this PR was about stabilizing `let` bindings, but too many flaws were exposed that need some more testing on nightly
add coherence future-compat warnings for marker-only trait objects
The future-compat warnings break code that assumes that `dyn Send + Sync !=
dyn Sync + Send`, and are the first step in making them equal. cc #33140.
Note: this lint should be made to default-warn before we merge. It is deny only for the crater run.
r? @nikomatsakis / @scalexm . cc @Centril & @alexreg.
This avoids all sorts of confusing issues with using both `dest_place`
and `self` in the `propagate_call_return` function in the
`BitDenotation` implementation for `Borrows`.
This commit extends previous work to kill borrows from a local after
assignment into that local to kill borrows from a projection after
assignment into a prefix of that place.
