This removes a bunch of token types. Tokens now store the original, unaltered
numeric literal (that is still checked for correctness), which is parsed into
an actual number later, as needed, when creating the AST.
This can change how syntax extensions work, but otherwise poses no visible
changes.
[breaking-change]
This patch adds hygiene for methods. This one was more difficult than the others, due principally to issues surrounding `self`. Specifically, there were a whole bunch of places in the code that assumed that a `self` identifier could be discarded and then made up again later, causing the discard of contexts and hygiene breakage.
formerly, the self identifier was being discarded during parsing, which
stymies hygiene. The best fix here seems to be to attach a self identifier
to ExplicitSelf_, a change that rippled through the rest of the compiler,
but without any obvious damage.
The let-syntax expander is different in that it doesn't apply
a mark to its token trees before expansion. This is used
for macro_rules, and it's because macro_rules is essentially
MTWT's let-syntax. You don't want to mark before expand sees
let-syntax, because there's no "after" syntax to mark again.
In some sense, the cleaner approach might be to introduce a new
AST node that macro_rules expands into; this would make it clearer
that the expansion of a macro is distinct from the addition of a
new macro binding.
This should work for now, though...
This commit disables rustc's emission of rpath attributes into dynamic libraries
and executables by default. The functionality is still preserved, but it must
now be manually enabled via a `-C rpath` flag.
This involved a few changes to the local build system:
* --disable-rpath is now the default configure option
* Makefiles now prefer our own LD_LIBRARY_PATH over the user's LD_LIBRARY_PATH
in order to support building rust with rust already installed.
* The compiletest program was taught to correctly pass through the aux dir as a
component of LD_LIBRARY_PATH in more situations.
The major impact of this change is that neither rustdoc nor rustc will work
out-of-the-box in all situations because they are dynamically linked. It must be
arranged to ensure that the libraries of a rust installation are part of the
LD_LIBRARY_PATH. The default installation paths for all platforms ensure this,
but if an installation is in a nonstandard location, then configuration may be
necessary.
Additionally, for all developers of rustc, it will no longer be possible to run
$target/stageN/bin/rustc out-of-the-box. The old behavior can be regained
through the `--enable-rpath` option to the configure script.
This change brings linux/mac installations in line with windows installations
where rpath is not possible.
Closes#11747
[breaking-change]
This updates https://github.com/rust-lang/rust/pull/15075.
Rename `ToStr::to_str` to `ToString::to_string`. The naive renaming ends up with two `to_string` functions defined on strings in the prelude (the other defined via `collections::str::StrAllocating`). To remedy this I removed `StrAllocating::to_string`, making all conversions from `&str` to `String` go through `Show`. This has a measurable impact on the speed of this conversion, but the sense I get from others is that it's best to go ahead and unify `to_string` and address performance for all `to_string` conversions in `core::fmt`. `String::from_str(...)` still works as a manual fast-path.
Note that the patch was done with a script, and ended up renaming a number of other `*_to_str` functions, particularly inside of rustc. All the ones I saw looked correct, and I didn't notice any additional API breakage.
Closes#15046.
closes#13367
[breaking-change] Use `Sized?` to indicate a dynamically sized type parameter or trait (used to be `type`). E.g.,
```
trait Tr for Sized? {}
fn foo<Sized? X: Share>(x: X) {}
```
closes#13367
[breaking-change] Use `Sized?` to indicate a dynamically sized type parameter or trait (used to be `type`). E.g.,
```
trait Tr for Sized? {}
fn foo<Sized? X: Share>(x: X) {}
```
This will break code that looks like:
struct Foo {
...
}
mod Foo {
...
}
Change this code to:
struct Foo {
...
}
impl Foo {
...
}
Or rename the module.
Closes#15205.
[breaking-change]
r? @nick29581
Extend the null ptr optimization to work with slices, closures, procs, & trait objects by using the internal pointers as the discriminant.
This decreases the size of `Option<&[int]>` (and similar) by one word.
This will break code that used the old `Index` trait. Change this code
to use the new `Index` traits. For reference, here are their signatures:
pub trait Index<Index,Result> {
fn index<'a>(&'a self, index: &Index) -> &'a Result;
}
pub trait IndexMut<Index,Result> {
fn index_mut<'a>(&'a mut self, index: &Index) -> &'a mut Result;
}
Closes#6515.
[breaking-change]
r? @nick29581
This will break code that used the old `Index` trait. Change this code
to use the new `Index` traits. For reference, here are their signatures:
pub trait Index<Index,Result> {
fn index<'a>(&'a self, index: &Index) -> &'a Result;
}
pub trait IndexMut<Index,Result> {
fn index_mut<'a>(&'a mut self, index: &Index) -> &'a mut Result;
}
Closes#6515.
[breaking-change]
This will break code that looks like:
struct Foo {
...
}
mod Foo {
...
}
Change this code to:
struct Foo {
...
}
impl Foo {
...
}
Or rename the module.
Closes#15205.
[breaking-change]
LLVM doesn't handle i1 value in allocas/memory very well and skips a number of optimizations if it hits it. So we have to do the same thing that Clang does, using i1 for SSA values, but storing i8 in memory.
Fixes#15203.
LLVM doesn't really like types with a bit-width that isn't a multiple of
8 and disable various optimizations if it encounters such types used
with loads/stores. OTOH, booleans must be represented as i1 when used as
SSA values. To get the best results, we must use i1 for SSA values, and
i8 when storing the value to memory.
By using range asserts on loads, LLVM can eliminate the required
zero-extend and truncate operations.
Fixes#15203
This is an implementation of [RFC 35](https://github.com/rust-lang/rfcs/blob/master/active/0035-remove-crate-id.md).
The summary for this PR is the same as that of the RFC, with one addendum:
* Removes the `#[crate_id]` attribute and knowledge of versions from rustc.
* Added a `#[crate_name]` attribute similar to the old `#[crate_id]` attribute
* Output filenames no longer have versions or hashes
* Symbols no longer have versions (they still have hashes)
* A new flag, `--extern`, is used to override searching for external crates
* A new flag, `-C metadata=foo`, used when hashing symbols
* [added] An old flag, `--crate-name`, was re purposed to specify the crate name from the command line.
I tried to maintain backwards compatibility wherever possible (with warnings being printed). If I missed anywhere, however, please let me know!
[breaking-change]
Closes#14468Closes#14469Closes#14470Closes#14471
In a cargo-driven world the primary location for the name of a crate will be in
its manifest, not in the source file itself. The purpose of this flag is to
reduce required duplication for new cargo projects.
This is a breaking change because the existing --crate-name flag actually
printed the crate name. This flag was renamed to --print-crate-name, and to
maintain consistence, the --crate-file-name flag was renamed to
--print-file-name.
To maintain backwards compatibility, the --crate-file-name flag is still
recognized, but it is deprecated.
[breaking-change]
This comit implements a new flag, --extern, which is used to specify where a
crate is located. The purpose of this flag is to bypass the normal crate
loading/matching of the compiler to point it directly at the right file.
This flag takes the form `--extern foo=bar` where `foo` is the name of a crate
and `bar` is the location at which to find the crate. Multiple `--extern`
directives are allowed with the same crate name to specify the rlib/dylib pair
for a crate. It is invalid to specify more than one rlib or more than one dylib,
and it's required that the crates are valid rust crates.
I have also added some extensive documentation to metadata::loader about how
crate loading should work.
RFC: 0035-remove-crate-id
The compiler will no longer insert a hash or version into a filename by default.
Instead, all output is simply based off the crate name being compiled. For
example, a crate name of `foo` would produce the following outputs:
* bin => foo
* rlib => libfoo.rlib
* dylib => libfoo.{so,dylib} or foo.dll
* staticlib => libfoo.a
The old behavior has been moved behind a new codegen flag,
`-C extra-filename=<hash>`. For example, with the "extra filename" of `bar` and
a crate name of `foo`, the following outputs would be generated:
* bin => foo (same old behavior)
* rlib => libfoobar.rlib
* dylib => libfoobar.{so,dylib} or foobar.dll
* staticlib => libfoobar.a
The makefiles have been altered to pass a hash by default to invocations of
`rustc` so all installed rust libraries will have a hash in their filename. This
is done because the standard libraries are intended to be installed into
privileged directories such as /usr/local. Additionally, it involves very few
build system changes!
RFC: 0035-remove-crate-id
[breaking-change]
This commit modifies crate loading to purely work off a `crate_name` and nothing
else. This commit also changes the patterns recognized from `lib<foo>-*` to
`lib<foo>*` to accomodate the future renamings of output files.
RFC: 0035-remove-crate-id
This commit removes all support in the compiler for the #[crate_id] attribute
and all of its derivative infrastructure. A list of the functionality removed is:
* The #[crate_id] attribute no longer exists
* There is no longer the concept of a version of a crate
* Version numbers are no longer appended to symbol names
* The --crate-id command line option has been removed
To migrate forward, rename #[crate_id] to #[crate_name] and only the name of the
crate itself should be mentioned. The version/path of the old crate id should be
removed.
For a transitionary state, the #[crate_id] attribute is still accepted if
the #[crate_name] is not present, but it is warned about if it is the only
identifier present.
RFC: 0035-remove-crate-id
[breaking-change]
In my informal measurements, this brings the peak memory usage when
building librustc from 1662M down to 1502M. Since 1662 - 1502 = 160,
this may not recover the entirety of the observed memory regression
(250M) from PR #14604. (However, according to my local measurements,
the regression when building librustc was more like 209M, so perhaps
this will still recover the lions share of the lost memory.)
In my informal measurements, this brings the peak memory usage when
building librustc from 1662M down to 1502M. Since 1662 - 1502 = 160,
this may not recover the entirety of the observed memory regression
(250M) from PR #14604. (However, according to my local measurements,
the regression when building librustc was more like 209M, so perhaps
this will still recover the lions share of the lost memory.)
This basically meant changing the interface so that no borrowed `&Vec`
is exposed, by hiding `fn get_vec` and `fn get_mut_vec` and revising
`fn all_vecs`.
Instead, clients should use one of the other methods; `get_slice`,
`pop`, `truncate`, `replace`, `push_all`, or `is_empty_in`, which
should work for any case currently used in rustc.
This pull request adds hygiene for 3 kinds of argument bindings:
- arguments to item fns,
- arguments to `ExprFnBlock`s, and
- arguments to `ExprProc`s
It also adds a bunch of unit tests, fixes a few macro uses to be non-capturing, and has a few cleanup items.
local `make check` succeeds.
