| Age | Commit message (Collapse) | Author | Lines |
|---|
|
The current help message is too much about "normal" macros to be used
as general message. Keep it for normal macros, and add custom help and
error messages for macro definitions.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
fixes part of #30197
|
|
|
|
Currently a compiler can be built with the `--disable-elf-tls` option for compatibility with OSX 10.6 which doesn't have ELF TLS. This is unfortunate, however, as a whole new compiler must be generated which can take some time. These commits add a new (feature gated) `cfg(target_thread_local)` annotation set by the compiler which indicates whether `#[thread_local]` is available for use. The compiler now interprets `MACOSX_DEPLOYMENT_TARGET` (a standard environment variable) to set this flag on OSX. With this we may want to start compiling our OSX nightlies with `MACOSX_DEPLOYMENT_TARGET` set to 10.6 which would allow the compiler out-of-the-box to generate 10.6-compatible binaries.
For now the compiler still by default targets OSX 10.7 by allowing ELF TLS by default (e.g. if `MACOSX_DEPLOYMENT_TARGET` isn't set).
|
|
This transitions the standard library's `thread_local!` macro to use the
freshly-added and gated `#[cfg(target_thread_local)]` attribute. This greatly
simplifies the `#[cfg]` logic in play here, but requires that the standard
library expose both the OS and ELF TLS implementation modules as unstable
implementation details.
The implementation details were shuffled around a bit but end up generally
compiling to the same thing.
Closes #26581 (this supersedes the need for the option)
Closes #27057 (this also starts ignoring the option)
|
|
This change modifies the feature gating of special `#[cfg]` attributes to not
require a `#![feature]` directive in the crate-of-use if the source of the macro
was declared with `#[allow_internal_unstable]`. This enables the standard
library's macro for `thread_local!` to make use of the
`#[cfg(target_thread_local)]` attribute despite it being feature gated (e.g.
it's a hidden implementation detail).
|
|
Currently the standard library has some pretty complicated logic to detect
whether #[thread_local] should be used or whether it's supported. This is also
unfortunately not quite true for OSX where not all versions support
the #[thread_local] attribute (only 10.7+ does). Compiling code for OSX 10.6 is
typically requested via the MACOSX_DEPLOYMENT_TARGET environment variable (e.g.
the linker recognizes this), but the standard library unfortunately does not
respect this.
This commit updates the compiler to add a `target_thread_local` cfg annotation
if the platform being targeted supports the `#[thread_local]` attribute. This is
feature gated for now, and it is only true on non-aarch64 Linux and 10.7+ OSX
(e.g. what the module already does today). Logic has also been added to parse
the deployment target environment variable.
|
|
Lots of cruft to remove!
|
|
|
|
Lots of cruft to remove!
|
|
cc https://github.com/rust-lang/rust/pull/30095
r? @nrc
|
|
|
|
This PR is a rebase of the original PR by @eddyb https://github.com/rust-lang/rust/pull/21836 with some unrebasable parts manually reapplied, feature gate added + type equality restriction added as described below.
This implementation is partial because the type equality restriction is applied to all type ascription expressions and not only those in lvalue contexts. Thus, all difficulties with detection of these contexts and translation of coercions having effect in runtime are avoided.
So, you can't write things with coercions like `let slice = &[1, 2, 3]: &[u8];`. It obviously makes type ascription less useful than it should be, but it's still much more useful than not having type ascription at all.
In particular, things like `let v = something.iter().collect(): Vec<_>;` and `let u = t.into(): U;` work as expected and I'm pretty happy with these improvements alone.
Part of https://github.com/rust-lang/rust/issues/23416
|
|
|
|
Some notes:
This patch enforces the rules from [RFC 136](https://github.com/rust-lang/rfcs/blob/master/text/0136-no-privates-in-public.md) and makes "private in public" a module-level concept and not crate-level. Only `pub` annotations are used by the new algorithm, crate-level exported node set produced by `EmbargoVisitor` is not used. The error messages are tweaked accordingly and don't use the word "exported" to avoid confusing people (https://github.com/rust-lang/rust/issues/29668).
The old algorithm tried to be extra smart with impls, but it mostly led to unpredictable behavior and bugs like https://github.com/rust-lang/rust/issues/28325.
The new algorithm tries to be as simple as possible - an impl is considered public iff its type is public and its trait is public (if presents).
A type or trait is considered public if all its components are public, [complications](https://internals.rust-lang.org/t/limits-of-type-inference-smartness/2919) with private types leaking to other crates/modules through trait impls and type inference are deliberately ignored so far.
The new algorithm is not recursive and uses the nice new facility `Crate::visit_all_items`!
Obsolete pre-1.0 feature `visible_private_types` is removed.
This is a [breaking-change].
The two main vectors of breakage are type aliases (https://github.com/rust-lang/rust/issues/28450) and impls (https://github.com/rust-lang/rust/issues/28325).
I need some statistics from a crater run (cc @alexcrichton) to decide on the breakage mitigation strategy.
UPDATE: All the new errors are reported as warnings controlled by a lint `private_in_public` and lint group `future_incompatible`, but the intent is to make them hard errors eventually.
Closes https://github.com/rust-lang/rust/issues/28325
Closes https://github.com/rust-lang/rust/issues/28450
Closes https://github.com/rust-lang/rust/issues/29524
Closes https://github.com/rust-lang/rust/issues/29627
Closes https://github.com/rust-lang/rust/issues/29668
Closes https://github.com/rust-lang/rust/issues/30055
r? @nikomatsakis
|
|
+ Rebase fixes
|
|
Part of https://github.com/rust-lang/rust/pull/30095 not causing mysterious segfaults.
r? @nrc
|
|
Should make it possible to add JSON or HTML errors. Also tidies up a lot.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
d'oh
|
|
The intention here is that Session is a very thin wrapper over the error handling infra.
|
|
Also split out emitters into their own module.
|
|
+ Apply parser changes manually
+ Add feature gate
|
|
|
|
r? @nrc
|
|
|
|
Changed bit manipulation to use supported - (set difference) instead
of explicit '& !'.
|
|
This reduces iteration time (`make rustc-stage1`) for moved syntax extensions from 11 minutes to 3 minutes on my machine.
Because of the signature change, this is a [breaking-change] for people directly calling `expand_crate`. I think it is rare: from GitHub search, only case I found is [glassful](https://github.com/kmcallister/glassful).
|
|
Closes https://github.com/rust-lang/rust/issues/29935
The attributes `deprecated` and `rustc_deprecated` are completely independent in this implementation and it leads to some noticeable code duplication. Representing `deprecated` as
```
Stability {
level: Stable { since: "" },
feature: "",
depr: Some(Deprecation),
}
```
or, contrariwise, splitting rustc_deprecation from stability makes most of the duplication go away.
I can do this refactoring, but before doing it I must be sure, that further divergence of `deprecated` and `rustc_deprecated` is certainly not a goal.
cc @llogiq
|
|
|
|
|
|
|
|
|
|
RESTRICTION_STMT_EXPR restriction to allow subsequent expressions to
contain braces.
https://github.com/rust-lang/rust/issues/28777
|
|
This PR reverts #29543 and instead implements proper support for "=*m" and "+*m" indirect output operands. This provides a framework on top of which support for plain memory operands ("m", "=m" and "+m") can be implemented.
This also fixes the liveness analysis pass not handling read/write operands correctly.
|
|
|
|
|
