Reduce maximum repr(align(N)) to 2^29
The current maximum `repr(align(N))` alignment is larger than the maximum alignment accepted by LLVM, which can cause issues for huge values of `N`, as seen in #49492. Fixes#49492.
r? @rkruppe
Fix a warning in libcore on 16bit targets.
This code is assuming that usize >= 32bits, but it is not the case on
16bit targets. It is producing a warning that can fail the compilation
on MSP430 if deny(warnings) is enabled.
It is very unlikely that someone would actually use this code on
a microcontroller, but since unicode was merged into libcore we
have to compile it on 16bit targets.
I've tried to make sure that the code stays the same on x86,
here is an assembly comparison: https://godbolt.org/g/wFw7dZ
r? @SimonSapin
This avoids converting every char to \u{...} form, which bloats the
resulting strings unnecessarily. It also provides consistency with the
existing escape_default() calls in LitKind::token() used for raw
string literals, char literals, and raw byte char literals.
There are two benefits from this change.
- Compilation is faster. Most of the rustc-perf benchmarks see a
non-trivial speedup, particularly for incremental rebuilds, with the
best speedup over 13%, and multiple others over 10%.
- Generated rlibs are smaller. An extreme example is libfutures.rlib,
which shrinks from 2073306 bytes to 1765927 bytes, a 15% reduction.
Fix an unresolved import issue with enabled `use_extern_macros`
This is a kinda ugly special-purpose solution that will break if we suddenly add a fourth namespace, but I hope to come up with something more general if I get to import resolution refactoring this summer.
Fixes https://github.com/rust-lang/rust/issues/50187 thus removing a blocker for stabilization of `use_extern_macros`
Correct initial field alignment for repr(C)/repr(int)
Fixes#50098 following https://github.com/rust-lang/rust/issues/50098#issuecomment-385497333.
(I wasn't sure which kind of test was best suited here — I picked run-pass simply because that was convenient, but if codegen is more appropriate, let me know and I'll change it.)
r? @eddyb
This is sort of confusing "side step". All it does is to change the
representation of a skolemized region. but the source of that universe
index is not the inference context, which is what we eventually want,
but rather an internal counter in the region inference context.
We'll patch that up later. But doing this now ought to help with
confusing diffs later.
This gives each type inference variable a notion of universe but doesn't
do anything with it. We can always get the "current universe" from
infer_ctxt. This relies on the property of type variables that they can
never interact with siblings.
Treat generators as if they have an arbitrary destructor
Conservatively assume dropping a generator touches its upvars, via locals' destructors.
Fix#49918
rustc: return iterators from Terminator(Kind)::successors(_mut).
Minor cleanup (and potentially speedup) prompted by @nnethercote's `SmallVec` experiments.
This PR assumes `.count()` and `.nth(i)` on `iter::Chain<option::IntoIter, slice::Iter(Mut)>` are `O(1)`, but otherwise all of the uses appear to immediately iterate through the successors.
r? @nikomatsakis
This is meant to address rust-lang/rust#49918.
Review feedback: put back comment justifying skipping interior traversal.
Review feedback: dropck generators like trait objects: all their upvars must
outlive the generator itself, so just create a DtorckConstraint saying so.
