| Age | Commit message (Collapse) | Author | Lines |
|---|
|
So that lowering is reproducible
|
|
|
|
|
|
Currently the compiler supports the ability to emit multiple output types as
part of one compilation (e.g. asm, LLVM IR, bytecode, link, dep-info, etc). It
does not, however, support the ability to customize the output filename for each
of these output types. The `-o` flag is ignored if multiple emit types are
specified (and the compiler emits a warning about this).
Normally this doesn't matter too much, but in the case of `dep-info` it can lead
to a number of problems (e.g. see #28716). By allowing customization of the
output filename for each emit type we're able to solve the problems in that
issue.
This commit adds support for the `--emit` option to the compiler to look like:
rustc foo.rs --emit dep-info=.deps/foo.d,link
This indicates that the `dep-info` output type will be placed at `.deps/foo.d`
and the `link` output type will otherwise be determined via the `--out-dir` and
`-o` flags.
Closes #28716
|
|
This commit updates the `MatchIndices` and `RMatchIndices` iterators to follow
the same pattern as the `chars` and `char_indices` iterators. The `matches`
iterator currently yield `&str` elements, so the `MatchIndices` iterator now
yields the index of the match as well as the `&str` that matched (instead of
start/end indexes).
cc #27743
|
|
This commit updates the `MatchIndices` and `RMatchIndices` iterators to follow
the same pattern as the `chars` and `char_indices` iterators. The `matches`
iterator currently yield `&str` elements, so the `MatchIndices` iterator now
yields the index of the match as well as the `&str` that matched (instead of
start/end indexes).
cc #27743
|
|
This adds a new target property, `target_vendor` which can be used as a
matcher for conditional compilation. The vendor is part of the autoconf
target triple: <arch><sub>-<vendor>-<os>-<env>
The default value for `target_vendor` is "unknown".
Matching against the `target_vendor` with `#[cfg]` is currently feature
gated as `cfg_target_vendor`.
|
|
This is so that the resolution results can be used after analysis, potentially for tool support
|
|
This could be a [breaking-change] if your lint or syntax extension (is that even possible?) uses HIR attributes or literals.
|
|
|
|
|
|
Currently, `early_error` and `early_warn` in `librustc::session` always
use `ColorConfig::Auto`. Modify them to follow the color configuration
set by the `--color` option.
As colored output is also printed during the early stage, parsing the
`--color` option should be done as early as possible. However, there are
still some cases when the output needs to be colored before knowing the
exact color settings. In these cases, it will be defaulted to
`ColorConfig::Auto`, which is the same as before.
Fixes #27879.
|
|
This commit is an implementation of [RFC 1183][rfc] which allows swapping out
the default allocator on nightly Rust. No new stable surface area should be
added as a part of this commit.
[rfc]: https://github.com/rust-lang/rfcs/pull/1183
Two new attributes have been added to the compiler:
* `#![needs_allocator]` - this is used by liballoc (and likely only liballoc) to
indicate that it requires an allocator crate to be in scope.
* `#![allocator]` - this is a indicator that the crate is an allocator which can
satisfy the `needs_allocator` attribute above.
The ABI of the allocator crate is defined to be a set of symbols that implement
the standard Rust allocation/deallocation functions. The symbols are not
currently checked for exhaustiveness or typechecked. There are also a number of
restrictions on these crates:
* An allocator crate cannot transitively depend on a crate that is flagged as
needing an allocator (e.g. allocator crates can't depend on liballoc).
* There can only be one explicitly linked allocator in a final image.
* If no allocator is explicitly requested one will be injected on behalf of the
compiler. Binaries and Rust dylibs will use jemalloc by default where
available and staticlibs/other dylibs will use the system allocator by
default.
Two allocators are provided by the distribution by default, `alloc_system` and
`alloc_jemalloc` which operate as advertised.
Closes #27389
|
|
by RFC 1214,
and issue a warning (and explanatory note) when we encounter such a
thing.
|
|
This is a temporary workaround for the bugs that have been found in
the implementation of PR #26173.
* pnkfelix is unavailable in the short-term (i.e. for the next week) to fix them.
* When the bugs are fixed, we will turn this back on by default.
(If you want to play with the known-to-be-buggy optimization in the
meantime, you can opt-back in via the debugging option that this
commit is toggling.)
|
|
(Inspired by discussion with Gankro.)
|
|
This commit is an implementation of [RFC 1193][rfc] which adds the ability to
the compiler to cap the lint level for the entire compilation session. This flag
will ensure that no lints will go above this level, and Cargo will primarily use
this flag passing `--cap-lints allow` to all upstream dependencies.
[rfc]: https://github.com/rust-lang/rfcs/pull/1193
Closes #27259
|
|
This commit is an implementation of [RFC 1193][rfc] which adds the ability to
the compiler to cap the lint level for the entire compilation session. This flag
will ensure that no lints will go above this level, and Cargo will primarily use
this flag passing `--cap-lints allow` to all upstream dependencies.
[rfc]: https://github.com/rust-lang/rfcs/pull/1193
Closes #27259
|
|
(already thumbs-upped pre-rebase by nikomatsakis)
|
|
closes #21332
|
|
It now says '#[feature] may not be used on the stable release channel'.
I had to convert this error from a lint to a normal compiler error.
I left the lint previously-used for this in place since removing it is
a breaking change. It will just go unused until the end of time.
Fixes #24125
|
|
This lets plugin authors opt attributes out of the `custom_attribute`
and `unused_attribute` checks.
cc @thepowersgang
|
|
|
|
|
|
|
|
This lets plugin authors opt attributes out of the `custom_attribute`
and `unused_attribute` checks.
|
|
Turns out that a verbatim path was leaking through to gcc via the PATH
environment variable (pointing to the bundled gcc provided by the main
distribution) which was wreaking havoc when gcc itself was run. The fix here is
to just stop passing verbatim paths down by adding more liberal uses of
`fix_windows_verbatim_for_gcc`.
Closes #25072
|
|
|
|
This adds a new `#[cfg]` matcher against the `target_env` property of the
destination target triple. For example all windows triples today end with `-gnu`
but we will also hopefully support non-`gnu` targets for Windows, at which point
we'll need to differentiate between the two. This new `target_env` matches is
provided and filled in with the target's environment name.
Currently the only non-empty value of this name is `gnu`, but `musl` will be
shortly added for the linux triples.
|
|
An actual typeck error is the cause of many failed compilations but an
unrelated bug is being reported instead. It is triggered because a typeck
error is presumably not yet identified during compiler execution, which
would normally bypass an invariant in the presence of other errors. In
this particular situation, we delay the reporting of the bug until
abort_if_errors().
Closes #23827, closes #24356, closes #23041, closes #22897, closes #23966,
closes #24013, and closes #23729
**There is at least one situation where this bug may still be genuinely
triggered (#23437).**
|
|
Changes the style guidelines regarding unit tests to recommend using a
sub-module named "tests" instead of "test" for unit tests as "test"
might clash with imports of libtest.
|
|
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
|
|
This is the second attempt at turning the trace_macros macro into a compiler flag.
See #22619
|
|
`s/(?<!\{ self)(?<=\.)len\(\) == 0/is_empty()/g`
|
|
Fixes #22619
|
|
An actual typeck error is the cause of many failed compilations but an
unrelated bug is being reported instead. It is triggered because a typeck
error is presumably not yet identified during compiler execution, which
would normally bypass an invariant in the presence of other errors. In
this particular situation, we delay the reporting of the bug until
abort_if_errors().
Closes #23827, closes #24356, closes #23041, closes #22897, closes #23966,
closes #24013, and closes #23729
|
|
Also fixed bug calling .note() instead of .help()
See #24036
|
|
of text (perhaps obtained by span_snippet) and then splice that edited
form back into the original file in the form of a suggestion.
|
|
|
|
- Functions in parser.rs return PResult<> rather than panicing
- Other functions in libsyntax call panic! explicitly for now if they rely on panicing behaviour.
- 'panictry!' macro added as scaffolding while converting panicing functions.
(This does the same as 'unwrap()' but is easier to grep for and turn into try!())
- Leaves panicing wrappers for the following functions so that the
quote_* macros behave the same:
- parse_expr, parse_item, parse_pat, parse_arm, parse_ty, parse_stmt
|
|
different closures fail typechecking.
See #24036
|
|
Conflicts:
src/test/compile-fail/coherence-impls-copy.rs
|
|
This commit is an implementation of [RFC 979][rfc] which changes the meaning of
the count parameter to the `splitn` function on strings and slices. The
parameter now means the number of items that are returned from the iterator, not
the number of splits that are made.
[rfc]: https://github.com/rust-lang/rfcs/pull/979
Closes #23911
[breaking-change]
|
|
|
|
Conflicts:
src/librustc/middle/ty.rs
src/librustc_trans/trans/adt.rs
src/librustc_typeck/check/mod.rs
src/libserialize/json.rs
src/test/run-pass/spawn-fn.rs
|
|
This syntax has been renamed to `-l static=foo` some time ago.
|
|
Replace zeroing-on-drop with filling-on-drop.
This is meant to set the stage for removing *all* zeroing and filling (on drop) in the future.
Note that the code is meant to be entirely abstract with respect to the particular values used for the drop flags: the final commit demonstrates how to go from zeroing-on-drop to filling-on-drop by changing the value of three constants (in two files).
See further discussion on the internals thread:
http://internals.rust-lang.org/t/attention-hackers-filling-drop/1715/11
[breaking-change] especially for structs / enums using `#[unsafe_no_drop_flag]`.
|
|
|
|
|
|
This syntax has been renamed to `-l static=foo` some time ago.
|
