This breaks a fair amount of code. The typical patterns are:
* `for _ in range(0, 10)`: change to `for _ in range(0u, 10)`;
* `println!("{}", 3)`: change to `println!("{}", 3i)`;
* `[1, 2, 3].len()`: change to `[1i, 2, 3].len()`.
RFC #30. Closes#6023.
[breaking-change]
This adds an implementation of Add for String where the rhs is <S: Str>. The
other half of adding strings is where the lhs is <S: Str>, but coherence and
the libcore separation currently prevent that.
The f128 type has very little support in the compiler and the feature is
basically unusable today. Supporting half-baked features in the compiler can be
detrimental to the long-term development of the compiler, and hence this feature
is being removed.
This is a rebase of #14804 with two new commits on top to implement and test lint plugins.
r? @alexcrichton @huonw: Can you take a look at the new commits, and also weigh in about any issues from the old PR that you feel are still unresolved? I'm leaving the old branch alone to preserve discussion history.
Also change some code formatting.
lint::builtin becomes a sibling of lint::context in order to ensure that lints
implemented there use the same public API as lint plugins.
The immediate benefits are
* moving the state specific to a single lint out of Context, and
* replacing the soup of function calls in the Visitor impl with
more structured control flow
But this is also a step towards loadable lints.
We're going to have more modules under lint, and the paths get unwieldy. We
also plan to have lints run at multiple points in the compilation pipeline.
It was accidentally removed in #15006 and that somehow got past the
build bots, causing `src/test/run-make/c-dynamic-dylib` to fail on at
least my linux system.
This resolves#15103 (thanks to @alexcrichton!).
The aim of these changes is not working out a generic bi-endianness architectures support but to allow people develop for little endian MIPS machines (issue #7190).
Includes a bit more comments than usual for a regression test; I felt like documenting Niko's diagnosis of the original problem here.
Fix#15111
r? anyone.
If you define lang items in your crate, add `#[feature(lang_items)]`.
If you define intrinsics (`extern "rust-intrinsic"`), add
`#[feature(intrinsics)]`.
Closes#12858.
[breaking-change]
r? @brson
If you define lang items in your crate, add `#[feature(lang_items)]`.
If you define intrinsics (`extern "rust-intrinsic"`), add
`#[feature(intrinsics)]`.
Closes#12858.
[breaking-change]
This is just a cleanup of the code. Doesn't really change anything deep about the way we operate. This is a prelude to implementing a good solution for one-way matching for #5527.
r? @pnkfelix (we were just crawling about this code, after all)
It was accidentally removed in #15006 and that somehow got past the
build bots, causing `src/test/run-make/c-dynamic-dylib` to fail on at
least my linux system.
This resolves#15103 (thanks to @alexcrichton!).
