If the gen/kill bits are set there, the effects of `start_block_effects`
will not be seen when using `FlowAtLocation` etc. to go over the MIR.
EverInitializedLvals is the only pass that got this wrong, but this
fixes the footgun for everyone.
We issue just one message for an erroneous glob private variant reëxport
(using the Session's one-time-diagnostics capability), but individual
(non-glob) such erroneous reëxports still get their own messages. The
suggestion to make the enum public is also one-time.
The enum variant reëxport error didn't have an associated error code
(and remedying this here is deemed out of the scope of this commit), so
we resort to the expediency of using 0 as the `DiagnosticMessageId`
value.
Adding Debug to NameResolution was helpful in development.
This resolves#46209.
304c8b1eda made the Session's one-time-diagnostics set take a
special-purpose `DiagnosticMessageId` enum rather than a LintID so that
it could support more than just lints, but the `diag_span_note_once` and
`diag_note_once` methods continued to take references to lints: for API
consistency, we now make these methods take a `DiagnosticMessageId`
while we add support for one-time span-suggestions.
Make CGU-local globals private so they don't show up in the local symbol table.
Should reduce binary sizes. Great find, @eddyb!
r? @alexcrichton
(I have not tested this locally. Better wait for travis to turn green before approving)
incr.comp.: Enable query result caching for many more queries
Newly cached queries are:
* const_is_rvalue_promotable_to_static
* trans_fulfill_obligation
* optimized_mir
* unsafety_check_result
* borrowck
* mir_borrowck
* mir_const_qualif
* contains_extern_indicator
* def_symbol_name
* symbol_name
This also includes the stricter `Span` hashing first mentioned in #46490, which will lead to more false positives in release builds but overall is more correct -- and necessary for caching MIR. Hopefully we will soon be able to reduce the rate of false positives again by factoring `Span` out of MIR.
r? @nikomatsakis
rustc: Further tweak linkage in ThinLTO
In #46382 the logic around linkage preservation with ThinLTO ws tweaked but the
loop that registered all otherwise exported GUID values as "don't internalize
me please" was erroneously too conservative and only asking "external" linkage
items to not be internalized. Instead we actually want the inversion of that
condition, everything *without* "local" linkage to be internalized.
This commit updates the condition there, adds a test, and...
Closes#46543
Do not automatically merge `Cargo.lock`
It essentially never does what it's supposed to and often leaves the `Cargo.lock` in a state where it needs manual adjustments or resetting to master/yourbranch. With this setting git will always choose your `Cargo.lock` over the one from master and report a merge error (if both master and your branch touched `Cargo.lock`). Now you can run `./x.py help` and it should normally update the `Cargo.lock` to be one that has everything needed by master and your branch.
