| Age | Commit message (Collapse) | Author | Lines |
|---|
|
This "bubble up an error" macro was originally named if_ok! in order to get it
landed, but after the fact it was discovered that this name is not exactly
desirable.
The name `if_ok!` isn't immediately clear that is has much to do with error
handling, and it doesn't look fantastic in all contexts (if if_ok!(...) {}). In
general, the agreed opinion about `if_ok!` is that is came in as subpar.
The name `try!` is more invocative of error handling, it's shorter by 2 letters,
and it looks fitting in almost all circumstances. One concern about the word
`try!` is that it's too invocative of exceptions, but the belief is that this
will be overcome with documentation and examples.
Close #12037
|
|
|
|
Preparatory work for removing unique vectors from the language, which is
itself preparatory work for dynamically sized types.
|
|
|
|
Currently, the format_args! macro and its downstream macros in turn
expand to series of let statements, one for each of its arguments, and
then the invocation of the macro function. If one or more of the
arguments are RefCell's, the enclosing statement for the temporary of
the let is the let itself, which leads to scope problem. This patch
changes let's to a match expression.
Closes #12239.
|
|
Currently, the format_args! macro and its downstream macros in turn
expand to series of let statements, one for each of its arguments, and
then the invocation of the macro function. If one or more of the
arguments are RefCell's, the enclosing statement for the temporary of
the let is the let itself, which leads to scope problem. This patch
changes let's to a match expression.
Closes #12239.
|
|
bytepos_to_charpos.
|
|
Closes #11692. Instead of returning the original expression, a dummy expression
(with identical span) is returned. This prevents infinite loops of failed
expansions as well as odd double error messages in certain situations.
|
|
It's too easy to forget the `rust` tag to test something.
Closes #11698
|
|
|
|
This was previously implemented, and it just needed a snapshot to go through
|
|
This enables the parser error for `extern mod` => `extern crate` transitions.
|
|
|
|
Now that fold_item can return multiple items, this is pretty trivial. It
also recursively expands generated items so ItemDecorators can generate
items that are tagged with ItemDecorators!
Closes #4913
|
|
|
|
The old method of building up a list of items and threading it through
all of the decorators was unwieldy and not really scalable as
non-deriving ItemDecorators become possible. The API is now that the
decorator gets an immutable reference to the item it's attached to, and
a callback that it can pass new items to. If we want to add syntax
extensions that can modify the item they're attached to, we can add that
later, but I think it'll have to be separate from ItemDecorator to avoid
strange ordering issues.
@huonw
|
|
|
|
The old method of building up a list of items and threading it through
all of the decorators was unwieldy and not really scalable as
non-deriving ItemDecorators become possible. The API is now that the
decorator gets an immutable reference to the item it's attached to, and
a callback that it can pass new items to. If we want to add syntax
extensions that can modify the item they're attached to, we can add that
later, but I think it'll have to be separate from ItemDecorator to avoid
strange ordering issues.
|
|
#12057
|
|
|
|
The first setp for #9880 is to add a new `crate` keyword. This PR does exactly that. I took a chance to refactor `parse_item_foreign_mod` and I broke it down into 2 separate methods to isolate each feature.
The next step will be to push a new stage0 snapshot and then get rid of all `extern mod` around the code.
|
|
Externally loaded libraries are able to do things that cause references
to them to survive past the expansion phase (e.g. creating @-box cycles,
launching a task or storing something in task local data). As such, the
library has to stay loaded for the lifetime of the process.
|
|
This patch gets rid of ObsoleteExternModAttributesInParens and
ObsoleteNamedExternModule since the replacement of `extern mod` with
`extern crate` avoids those cases and raises different errors. Both have
been around for at least a version which makes this a good moment to get
rid of them.
|
|
This patch adds a new keyword `crate` which is intended to replace mod
in the context of `extern mod` as part of the issue #9880. The patch
doesn't replace all `extern mod` cases since it is necessary to first
push a new snapshot 0.
The implementation could've been less invasive than this. However I
preferred to take this chance to split the `parse_item_foreign_mod`
method and pull the `extern crate` part out of there, hence the new
method `parse_item_foreign_crate`.
|
|
This patch replaces all `crate` usage with `krate` before introducing the
new keyword. This ensures that after introducing the keyword, there
won't be any compilation errors.
krate might not be the most expressive substitution for crate but it's a
very close abbreviation for it. `module` was already used in several
places already.
|
|
|
|
mutably shared between them both
|
|
|
|
|
|
|
|
|
|
It could throw an error but I think it's best to not since `#[phase(..)]` syntax in other places would be silently ignored.
Closes #11806
|
|
This resolves issue #12157. Does that do it already or is there something else that needs taking care of?
As a side note, there seems to be some documentation, in which the old existence of the do keyword is explained. The list of keywords is not up-to-date either. But these are certainly separate issues.
|
|
Closes #11806
|
|
Resolves issue #12157. `do` is hereby reinstated as a keyword; no syntax is
associated with it though. Along the way, a unit test had to be adapted, since
it was using `do` as a method identifier.
Breaking changes:
- Any code using `do` as an identifier will no longer work.
|
|
Also move Void to std::any, move drop to std::mem and reexport in
prelude.
|
|
nikomatsakis/rust/issue-11913-borrow-in-aliasable-loc, r=pcwalton
Repair a rather embarassingly obvious hole that I created as part of #9629. In particular, prevent `&mut` borrows of data in an aliasable location. This used to be prevented through the restrictions mechanism, but in #9629 I modified those rules incorrectly.
r? @pcwalton
Fixes #11913
|
|
|
|
fourcc!() allows you to embed FourCC (or OSType) values that are
evaluated as u32 literals. It takes a 4-byte ASCII string and produces
the u32 resulting in interpreting those 4 bytes as a u32, using either
the platform-native endianness, or explicitly as big or little endian.
|
|
|
|
Error messages cleaned in librustc/middle
Error messages cleaned in libsyntax
Error messages cleaned in libsyntax more agressively
Error messages cleaned in librustc more aggressively
Fixed affected tests
Fixed other failing tests
Last failing tests fixed
|
|
Most of them are to reduce warnings in testing builds.
|
|
MaybeOwned allows from_utf8_lossy to avoid allocation if there are no
invalid bytes in the input.
Before:
```
test str::bench::from_utf8_lossy_100_ascii ... bench: 183 ns/iter (+/- 5)
test str::bench::from_utf8_lossy_100_invalid ... bench: 341 ns/iter (+/- 15)
test str::bench::from_utf8_lossy_100_multibyte ... bench: 227 ns/iter (+/- 13)
test str::bench::from_utf8_lossy_invalid ... bench: 102 ns/iter (+/- 4)
test str::bench::is_utf8_100_ascii ... bench: 2 ns/iter (+/- 0)
test str::bench::is_utf8_100_multibyte ... bench: 2 ns/iter (+/- 0)
```
Now:
```
test str::bench::from_utf8_lossy_100_ascii ... bench: 96 ns/iter (+/- 4)
test str::bench::from_utf8_lossy_100_invalid ... bench: 318 ns/iter (+/- 10)
test str::bench::from_utf8_lossy_100_multibyte ... bench: 105 ns/iter (+/- 2)
test str::bench::from_utf8_lossy_invalid ... bench: 105 ns/iter (+/- 2)
test str::bench::is_utf8_100_ascii ... bench: 2 ns/iter (+/- 0)
test str::bench::is_utf8_100_multibyte ... bench: 2 ns/iter (+/- 0)
```
|
|
The lexer and json were using `transmute(-1): char` as a sentinel value for EOF, which is invalid since `char` is strictly a unicode codepoint.
Fixing this allows for range asserts on chars since they always lie between 0 and 0x10FFFF.
|
|
|
|
Signed-off-by: OGINO Masanori <masanori.ogino@gmail.com>
|
|
Signed-off-by: OGINO Masanori <masanori.ogino@gmail.com>
|
|
|
|
|
|
|
