Auto merge of #24383 - avdi:patch-1, r=steveklabnik
"Dynamically typed" didn't seem like a relevant distinction; there are statically-compiled dynamically-typed languages. Another term that might work here (despite being notoriously vague) is "scripting languages".
Auto merge of #24560 - kwantam:apply_table_opt, r=alexcrichton
Apply optimization described in
https://github.com/rust-lang/regex/pull/73#issuecomment-93777126
to rust's copy of `unicode.py`.
This shrinks librustc_unicode's tables.rs from 479kB to 456kB,
and should improve performance slightly for related operations
(e.g., is_alphabetic(), is_xid_start(), etc).
In addition, pull in fix from @dscorbett's commit d25c39f86568a147f9b7080c25711fb1f98f056a in regex, which
makes `load_properties()` more tolerant of whitespace
in the Unicode tables. (This fix does not result in any
changes to tables.rs, but could if the Unicode tables
change in the future.)
Rollup merge of #24548 - graydon:reference-tidying, r=steveklabnik
This just deletes some egregious lies and obsolete terminology -- all of which I originally wrote -- from the reference. I expect the reference itself will be deleted soon enough, but I found myself gritting teeth over these bits too much to let them into a 1.0 release.
Rollup merge of #24542 - michaelsproul:rollup, r=alexcrichton
I did a manual merge of all the extended error PRs as we were getting merge conflicts yesterday. I think this is preferable to merging separately as I ended up having to manually merge @nham and @GuillaumeGomez's commits.
Rollup of #24458, #24482 and #24488.
#24482 and #24488 were already re-approved, and would need to be cancelled if this is merged instead.
Rollup merge of #24472 - dotdash:23431, r=nikomatsakis
Loading from and storing to small aggregates happens by casting the
aggregate pointer to an appropriately sized integer pointer to avoid
the usage of first class aggregates which would lead to less optimized
code.
But this means that, for example, a tuple of type (i16, i16) will be
loading through an i32 pointer and because we currently don't provide
alignment information LLVM assumes that the load should use the ABI
alignment for i32 which would usually be 4 byte alignment. But the
alignment requirement for the (i16, i16) tuple will usually be just 2
bytes, so we're overestimating alignment, which invokes undefined
behaviour.
Therefore we must emit appropriate alignment information for
stores/loads through such casted pointers.
Apply optimization described in
https://github.com/rust-lang/regex/pull/73#issuecomment-93777126
to rust's copy of `unicode.py`.
This shrinks librustc_unicode's tables.rs from 479kB to 456kB,
and should improve performance slightly for related operations
(e.g., is_alphabetic(), is_xid_start(), etc).
In addition, pull in fix from @dscorbett's commit d25c39f86568a147f9b7080c25711fb1f98f056a in regex, which
makes `load_properties()` more tolerant of whitespace
in the Unicode tables. (This fix does not result in any
changes to tables.rs, but could if the Unicode tables
change in the future.)
Björn Steinbrink [Wed, 15 Apr 2015 18:14:54 +0000 (20:14 +0200)]
Emit correct alignment information for loads/store of small aggregates
Loading from and storing to small aggregates happens by casting the
aggregate pointer to an appropriately sized integer pointer to avoid
the usage of first class aggregates which would lead to less optimized
code.
But this means that, for example, a tuple of type (i16, i16) will be
loading through an i32 pointer and because we currently don't provide
alignment information LLVM assumes that the load should use the ABI
alignment for i32 which would usually be 4 byte alignment. But the
alignment requirement for the (i16, i16) tuple will usually be just 2
bytes, so we're overestimating alignment, which invokes undefined
behaviour.
Therefore we must emit appropriate alignment information for
stores/loads through such casted pointers.
Auto merge of #24519 - rprichard:opt-write-args, r=alexcrichton
It's just as convenient, but it's much faster. Using write! requires an
extra call to fmt::write and a extra dynamically dispatched call to
Arguments' Display format function.
Auto merge of #24428 - kwantam:deprecate_unicode_fns, r=alexcrichton
This patch
1. renames libunicode to librustc_unicode,
2. deprecates several pieces of libunicode (see below), and
3. removes references to deprecated functions from
librustc_driver and libsyntax. This may change pretty-printed
output from these modules in cases involving wide or combining
characters used in filenames, identifiers, etc.
The following functions are marked deprecated:
1. char.width() and str.width():
--> use unicode-width crate
2. str.graphemes() and str.grapheme_indices():
--> use unicode-segmentation crate
Auto merge of #24209 - nikomatsakis:refactor-unification, r=nrc
I'm on a quest to slowly refactor a lot of the inference code. A first step for that is moving the "pure data structures" out so as to simplify what's left. This PR moves `snapshot_vec`, `graph`, and `unify` into their own crate (`librustc_data_structures`). They can then be unit-tested, benchmarked, etc more easily. As a benefit, I improved the performance of unification slightly on the benchmark I added vs the original code.
Auto merge of #24500 - pnkfelix:oflo-checked-neg, r=nikomatsakis
Add conditional overflow-checking to signed negate operator.
I argue this can land independently of #24420 , because one can write the implementation of `wrapped_neg()` inline if necessary (as illustrated in two cases on this PR).
Auto merge of #24461 - nikomatsakis:issue-22077-unused-lifetimes, r=aturon
This makes it illegal to have unconstrained lifetimes that appear in an associated type definition. Arguably, we should prohibit all unconstrained lifetimes -- but it would break various macros. It'd be good to evaluate how large a break change it would be. But this seems like the minimal change we need to do to establish soundness, so we should land it regardless. Another variant would be to prohibit all lifetimes that appear in any impl item, not just associated types. I don't think that's necessary for soundness -- associated types are different because they can be projected -- but it would feel a bit more consistent and "obviously" safe. I'll experiment with that in the meantime.
Niko Matsakis [Wed, 15 Apr 2015 10:11:18 +0000 (06:11 -0400)]
Augment the constrainted parameter check to ensure that all regions
which get mentioned in an associated type are constrained. Arguably we
should just require that all regions are constrained, but that is more
of a breaking change.
Rollup merge of #24510 - fhartwig:broken-links, r=nikomatsakis
Fix broken links in various parts of the docs.
I also found a dead link [here](http://doc.rust-lang.org/nightly/alloc/boxed/) (the first link on the page), but the chapter of the book that it used to point at seems to be gone, and I'm not sure what should happen to that link.
Rollup merge of #23782 - mvdnes:obsolete_note, r=alexcrichton
When emmitting a note, previously it was not known if the note was for an error or a
warning. If it was for a warning, then with `-Awarnings` it should not have been print.
The `emit_for` function allows someone to specify which level should determine its visibility.
An example:
```rust
extern crate \"std\" as std2;
fn main() {}
```
When compiling with `-Awarnings`, this would previously emit `note: use an identifier not in quotes instead` (and nothing else).
With this patch, it will be completely silent as expected.
projects / rust.git / log