| Age | Commit message (Collapse) | Author | Lines |
|---|
|
r? @alexcrichton
|
|
For now, words() is left in (but deprecated), and Words is a type alias for
struct SplitWhitespace.
Also cleaned up references to str.words() throughout codebase.
Closes #15628
|
|
When linking an archive statically to an rlib, the compiler will extract all
contents of the archive and add them all to the rlib being generated. The
current method of extraction is to run `ar x`, dumping all files into a
temporary directory. Object archives, however, are allowed to have multiple
entries with the same file name, so there is no method for them to extract their
contents into a directory in a lossless fashion.
This commit adds iterator support to the `ArchiveRO` structure which hooks into
LLVM's support for reading object archives. This iterator is then used to
inspect each object in turn and extract it to a unique location for later
assembly.
|
|
Check for duplicate loop labels in function bodies.
See also: http://internals.rust-lang.org/t/psa-rejecting-duplicate-loop-labels/1833
The change, which we are putting in as future-proofing in preparation for future potential additions to the language (namely labeling arbitrary blocks and using those labels in borrow expressions), means that code like this will start emitting warnings:
```rust
fn main() {
{ 'a: loop { break; } }
{ 'a: loop { break; } }
}
```
To make the above code compile without warnings, write this instead:
```rust
fn main() {
{ 'a: loop { break; } }
{ 'b: loop { break; } }
}
```
Since this change is only introducing a new warnings, this change is non-breaking.
Fix #21633
|
|
For now, words() is left in (but deprecated), and Words is a type alias for
struct SplitWhitespace.
Also cleaned up references to s.words() throughout codebase.
Closes #15628
|
|
When linking an archive statically to an rlib, the compiler will extract all
contents of the archive and add them all to the rlib being generated. The
current method of extraction is to run `ar x`, dumping all files into a
temporary directory. Object archives, however, are allowed to have multiple
entries with the same file name, so there is no method for them to extract their
contents into a directory in a lossless fashion.
This commit adds iterator support to the `ArchiveRO` structure which hooks into
LLVM's support for reading object archives. This iterator is then used to
inspect each object in turn and extract it to a unique location for later
assembly.
|
|
|
|
|
|
|
|
Fixes #15679
Fixes #15878
Fixes #15882
Closes #15883
|
|
|
|
|
|
At the moment, when compilation is stopped at a stop point (like `-Z parse-only`), `rustc` does not return an nonzero exit code even if there are errors (expect fatal ones, that cause it to panic immediately). As an example, compiling `src/test/compile-fail/doc-before-semi.rs` with `-Z parse-only` raises an error, but exists with 0.
Note that I could not use `sess.abort_if_errors()` in the macro, because `sess` is passed by value and move at some point.
|
|
closes #16745
|
|
Passing a non-snake-case name to #![crate_name] or --crate-name will now yield a
warning from the `non_snake_case` lint.
|
|
|
|
|
|
|
|
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
3. str.nfd_chars(), str.nfkd_chars(), str.nfc_chars(), str.nfkc_chars(),
char.compose(), char.decompose_canonical(), char.decompose_compatible(),
char.canonical_combining_class():
--> use unicode-normalization crate
|
|
This extracts some of the minor cleanup patches from #23905.
|
|
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).
This needs to go into beta channel.
|
|
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.
r? @aturon
Fixes #22077.
|
|
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.
|
|
|
|
Fix #24363
|
|
This is the second attempt at turning the trace_macros macro into a compiler flag.
See #22619
|
|
typeck: Do high-level structural/signature checks before function body checks.
This avoids various ICEs, e.g. premature calls to cat_expr that yield the dreaded "cat_expr Errd" ICE.
However, it also means that some early error feedback is now not provided. This may be for the best, because the error feedback were were providing in some of those cases were false positives -- it was spurious feedback and a distraction from the real problem.
So it is not 100% clear whether we actually want to put this change in or not. I think its a net win, but others might disagree.
(Kudos to @arielb1 for suggesting this modification.)
|
|
Fill in missing parts of Integer overflow API
See todo list at #22020
|
|
(The cast from the 64-bit value to isize was using the lower 32-bits,
which led to it being treated as a large positive value rather than a
smallish negative one. The fix was to use the same bits for the upper-
and lower- 32 bits.)
|
|
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
3. str.nfd_chars(), str.nfkd_chars(), str.nfc_chars(), str.nfkc_chars(),
char.compose(), char.decompose_canonical(), char.decompose_compatible(),
char.canonical_combining_class():
--> use unicode-normalization crate
|
|
Whenever a type implements Deref, rustdoc will now add a section to the "methods
available" sections for "Methods from Deref<Target=Foo>", listing all the
inherent methods of the type `Foo`.
Closes #19190
|
|
One of the parameters to the magical "register a thread-local destructor"
function is called `__dso_handle` and largely just passed along (this seems to
be what other implementations do). Currently we pass the *value* of this symbol,
but apparently the correct piece of information to pass is the *address* of the
symbol.
In a PIE binary the symbol actually contains an address to itself which is why
we've gotten away with what we're doing as long as we have. In a non-PIE binary
the symbol contains the address `NULL`, causing a segfault in the runtime
library if it keeps going.
Closes #24445
|
|
This seems to fix the test
|
|
closes #24434
This PR changes executes `syntax::config::strip_unconfigured_items` before `syntax::feature_gate::check_crate_macros(sess.codemap()`. As far as I know, `strip_unconfigured_items` should be independent of `check_crate_macros`.
|
|
This is a little bit tricky, since with include_str!, we know that we
are including utf-8 content, so it's safe to store the source as a
String in a FileMap. We don't know that for include_bytes!, but I don't
think we actually need to track the contents anyways, so I'm passing "".
new_filemap does check for the zero length content, and it should be
reasonable, howeven I'm not sure if it would be better to pass None
instead of Some(Rc::new("")) as the src component of a FileMap.
Fixes bug #24348
|
|
r? @alexcrichton
|
|
This allows #[derive(...)]` to create more than one impl
|
|
It was an oversight that this was not done in the great int upheaval.
[breaking-change]
|
|
It was an oversight that this was not done in the great int upheaval.
[breaking-change]
|
|
- Successful merges: #24425, #24435, #24438, #24440, #24449, #24457, #24460, #24465, #24467, #24468, #24471, #24476, #24480
- Failed merges:
|
|
Closes #24197
Closes #24375
These ICEs are fixed on nightly.
|
|
Extend rustc::middle::dataflow to allow filtering kills from flow-exits.
Fix borrowck analysis so that it will not treat a break that pops through an assignment
```rust
x = { ... break; ... }
```
as a kill of the "moved-out" bit for `x`.
Fix #24267.
[breaking-change], but really, its only breaking code that was already buggy.
|
|
|
|
|
|
|
|
One of the parameters to the magical "register a thread-local destructor"
function is called `__dso_handle` and largely just passed along (this seems to
be what other implementations do). Currently we pass the *value* of this symbol,
but apparently the correct piece of information to pass is the *address* of the
symbol.
In a PIE binary the symbol actually contains an address to itself which is why
we've gotten away with what we're doing as long as we have. In a non-PIE binary
the symbol contains the address `NULL`, causing a segfault in the runtime
library if it keeps going.
Closes #24445
|
|
This tests that both include_str! and include_bytes! mark their input
file as a dependancy, and it's correctly outputted when you run
`rustc --emit dep-info`.
|
|
|
|
|
|
`s/([^\(\s]+\.)len\(\) [(?:!=)>] 0/!$1is_empty()/g`
|
