Compile-fail tests for syntax extensions belong in this suite which has correct
dependencies on all artifacts rather than just the target artifacts.
Closes#13818
This change makes internal compile errors in the compile-fail tests failures.
I believe this is the correct behaviour- those tests are intended to assert that the compiler doesn't proceed, not that it explodes.
So far, it fails on 4 tests in my environment, my testcase for #13943 which is what caused me to tackle this, and 3 others:
```
failures:
[compile-fail] compile-fail/incompatible-tuple.rs # This one is mine and not on master
[compile-fail] compile-fail/inherit-struct8.rs
[compile-fail] compile-fail/issue-9725.rs
[compile-fail] compile-fail/unsupported-cast.rs
```
for `~str`/`~[]`.
Note that `~self` still remains, since I forgot to add support for
`Box<self>` before the snapshot.
r? @brson or @alexcrichton or whoever
for `~str`/`~[]`.
Note that `~self` still remains, since I forgot to add support for
`Box<self>` before the snapshot.
How to update your code:
* Instead of `~EXPR`, you should write `box EXPR`.
* Instead of `~TYPE`, you should write `Box<Type>`.
* Instead of `~PATTERN`, you should write `box PATTERN`.
[breaking-change]
The underlying I/O objects implement a good deal of various options here and
there for tuning network sockets and how they perform. Most of this is a relic
of "whatever libuv provides", but these options are genuinely useful.
It is unclear at this time whether these options should be well supported or
not, or whether they have correct names or not. For now, I believe it's better
to expose the functionality than to not, but all new methods are added with
an #[experimental] annotation.
Previously, the parser would not allow you to simultaneously implement a
function with a different abi as well as being unsafe at the same time. This
extends the parser to allow functions of the form:
unsafe extern fn foo() {
// ...
}
The closure type grammar was also changed to reflect this reversal, types
previously written as "extern unsafe fn()" must now be written as
"unsafe extern fn()". The parser currently has a hack which allows the old
style, but this will go away once a snapshot has landed.
Closes#10025
[breaking-change]
Currently, rustc requires that a linkage be a product of 100% rlibs or 100%
dylibs. This is to satisfy the requirement that each object appear at most once
in the final output products. This is a bit limiting, and the upcoming libcore
library cannot exist as a dylib, so these rules must change.
The goal of this commit is to enable *some* use cases for mixing rlibs and
dylibs, primarily libcore's use case. It is not targeted at allowing an
exhaustive number of linkage flavors.
There is a new dependency_format module in rustc which calculates what format
each upstream library should be linked as in each output type of the current
unit of compilation. The module itself contains many gory details about what's
going on here.
cc #10729
Fix#13965.
There is a dance here between the `main` that actually runs versus the
`main` that is printed in the output documentation. We don't run the
latter `main`, but we do at least compile (and thus type-check) it.
It is still the responsibility of the documenter to ensure that the
signatures of `fn render` are kept in sync across the blocks.
Update the example to make the usage of `pub mod foo;` much more
apparent, as well as using an example where setting the visibility of
the module is actually necessary.
The `std::bitflags::bitflags!` macro did not provide support for
adding attributes to the generates structure, due to limitations in
the parser for macros. This patch works around the parser limitations
by requiring a `flags` keyword in the `bitflags!` invocations:
bitflags!(
#[deriving(Hash)]
#[doc="Three flags"]
flags Flags: u32 {
FlagA = 0x00000001,
FlagB = 0x00000010,
FlagC = 0x00000100
}
)
The intent of `std::bitflags` is to allow building type-safe wrappers
around C-style flags APIs. But in addition to construction these flags
from the Rust side, we need a way to convert them from the C
side. This patch adds a `from_bits` function, which is unsafe since
the bits in question may not represent a valid combination of flags.
Finally, this patch changes `std::io::FilePermissions` from an exposed
`u32` representation to a typesafe representation (that only allows valid
flag combinations) using the `std::bitflags`.
Closes#6085.
Update the example to make the usage of `pub mod foo;` much more
apparent, as well as using an example where setting the visibility of
the module is actually necessary.
While there are various references to the work compositionality on the web, I can't find any reference to it being an actual word. My understanding is that composability is what's actually meant here anyway.
If an unbalanced [ exists in a string or comment, this should not be
considered when calculating the indent at the top level.
Similarly, when testing for ({/}) to see if we're at the top level to
begin with, strings and comments should be skipped.
By carefully distinguishing falling back to the default arm from moving
on to the next pattern, this patch adjusts the codegen logic for range
and guarded arms of pattern matching expression. It is a more
appropriate way of fixing #12582 and #13027 without causing regressions
such as #13867.
Closes#13867
Turning a `&T` into an `&mut T` is undefined behaviour, and needs to be
done very very carefully. Providing a convenience function for exactly
this task is a bad idea, just tempting people into doing the wrong
thing.
(The right thing is to use types like `Cell`, `RefCell` or `Unsafe`.)
cc https://github.com/mozilla/rust/issues/13933
The logging macros now create a LogRecord, and pass that to the Logger. This will allow custom loggers to change the formatting, and possible filter on more properties of the log record.
DefaultLogger's formatting was taken from Python's default formatting:
`LEVEL:from: message`
Also included: fmt::Arguments now implement Show, so they can be used to
extend format strings.
@alexcrichton r?
This patch changes `std::io::FilePermissions` from an exposed `u32`
representation to a typesafe representation (that only allows valid
flag combinations) using the `std::bitflags`, thus ensuring a greater
degree of safety on the Rust side.
Despite the change to the type, most code should continue to work
as-is, sincde the new type provides bit operations in the style of C
flags. To get at the underlying integer representation, use the `bits`
method; to (unsafely) convert to `FilePermissions`, use
`FilePermissions::from_bits`.
Closes#6085.
[breaking-change]
The intent of `std::bitflags` is to allow building type-safe wrappers
around C-style flags APIs. But in addition to construction these flags
from the Rust side, we need a way to convert them from the C
side. This patch adds a `from_bits` function, which is unsafe since
the bits in question may not represent a valid combination of flags.
The `std::bitflags::bitflags!` macro did not provide support for
adding attributes to the generated structure or flags, due to
limitations in the parser for macros. This patch works around the
parser limitations by requiring a `flags` keyword in the overall
`bitflags!` invocation, and a `static` keyword for each flag:
bitflags!(
#[deriving(Hash)]
#[doc="Three flags"]
flags Flags: u32 {
#[doc="The first flag"]
static FlagA = 0x00000001,
static FlagB = 0x00000010,
static FlagC = 0x00000100
}
)
