See #11522, but the idea is for private structs to have private fields by default, whereas public structs will continue to have public fields by default.
This was the original intention of the privacy of structs, and it was
erroneously implemented before. A pub struct will now have default-pub fields,
and a non-pub struct will have default-priv fields. This essentially brings
struct fields in line with enum variants in terms of inheriting visibility.
As usual, extraneous modifiers to visibility are disallowed depend on the case
that you're dealing with.
Closes#11522
Before this patch, if you wanted to add a crate to the build system you had to
change about 100 lines across 8 separate makefiles. This is highly error prone
and opaque to all but a few. This refactoring is targeted at consolidating this
effort so adding a new crate adds one line in one file in a way that everyone
can understand it.
These are either returned from public functions, and really should
appear in the documentation, but don't since they're private, or are
implementation details that are currently public.
These are either returned from public functions, and really should
appear in the documentation, but don't since they're private, or are
implementation details that are currently public.
Now that procedural macros can be implemented outside of the compiler,
it's more important to have a reasonable API to work with. Here are the
basic changes:
* Rename SyntaxExpanderTTTrait to MacroExpander, SyntaxExpanderTT to
BasicMacroExpander, etc. I think "procedural macro" is the right
term for these now, right? The other option would be SynExtExpander
or something like that.
* Stop passing the SyntaxContext to extensions. This was only ever used
by macro_rules, which doesn't even use it anymore. I can't think of
a context in which an external extension would need it, and removal
allows the API to be significantly simpler - no more
SyntaxExpanderTTItemExpanderWithoutContext wrappers to worry about.
Now that procedural macros can be implemented outside of the compiler,
it's more important to have a reasonable API to work with. Here are the
basic changes:
* Rename SyntaxExpanderTTTrait to MacroExpander, SyntaxExpanderTT to
BasicMacroExpander, etc. I think "procedural macro" is the right
term for these now, right? The other option would be SynExtExpander
or something like that.
* Stop passing the SyntaxContext to extensions. This was only ever used
by macro_rules, which doesn't even use it anymore. I can't think of
a context in which an external extension would need it, and removal
allows the API to be significantly simpler - no more
SyntaxExpanderTTItemExpanderWithoutContext wrappers to worry about.
The following are renamed:
* `min_value` => `MIN`
* `max_value` => `MAX`
* `bits` => `BITS`
* `bytes` => `BYTES`
All tests pass, except for `run-pass/phase-syntax-link-does-resolve.rs`. I doubt that failure is related, though.
Fixes#10010.
The race here happened when a port had its deschedule in select() canceled, but
the other chan had already been dropped. This meant that the DISCONNECTED case
was hit in abort_selection, but the to_wake cell hadn't been emptied yet (this
was done after aborting), causing an assert in abort_selection to trip.
To fix this, the to_wake cell is just emptied before abort_selection is called
(we know that we're the owner of it already).
They all have to go into a single module at the moment unfortunately.
Ideally, the logging macros would live in std::logging, condition! would
live in std::condition, format! in std::fmt, etc. However, this
introduces cyclic dependencies between those modules and the macros they
use which the current expansion system can't deal with. We may be able
to get around this by changing the expansion phase to a two-pass system
but that's for a later PR.
Closes#2247
cc #11763
By default, the compiler and libraries are all still built with rpaths, but this
can be opted out of with --disable-rpath to ./configure or --no-rpath to rustc.
Closes#5219
The race here happened when a port had its deschedule in select() canceled, but
the other chan had already been dropped. This meant that the DISCONNECTED case
was hit in abort_selection, but the to_wake cell hadn't been emptied yet (this
was done after aborting), causing an assert in abort_selection to trip.
To fix this, the to_wake cell is just emptied before abort_selection is called
(we know that we're the owner of it already).
By default, the compiler and libraries are all still built with rpaths, but this
can be opted out of with --disable-rpath to ./configure or --no-rpath to rustc.
cc #5219
This change adds two improvements to docs searching functionality.
First, search results will immediately be displayed when a ?search=searchterm
query string parameter is provided to any docs url.
Second, search results are now inserted into the browser history, allowing for
easier navigation between search results and docs pages.
They all have to go into a single module at the moment unfortunately.
Ideally, the logging macros would live in std::logging, condition! would
live in std::condition, format! in std::fmt, etc. However, this
introduces cyclic dependencies between those modules and the macros they
use which the current expansion system can't deal with. We may be able
to get around this by changing the expansion phase to a two-pass system
but that's for a later PR.
Closes#2247
cc #11763
Before this commit, rustc looked in `dirname $0`/../lib for libraries
but that doesn't work when rustc is invoked through a symlink.
This commit makes rustc look in `dirname $(readlink $0)`/../lib, i.e.
it first canonicalizes the symlink before walking up the directory tree.
Fixes#3632.
On my Gentoo Linux machine, the c-dynamic-dylib test is failing, because libcfoo can't be found. bar has a correct rpath for finding libfoo.so, but libfoo.so's rpath doesn't contain the right entries for finding libcfoo.
Below is the test failure on my machine. This test pass with this commit:
```
maketest: c-dynamic-dylib
----- /storage/home/achin/devel/rust/src/test/run-make/c-dynamic-dylib/ --------------------
------ stdout ---------------------------------------------
make[1]: Entering directory `/storage/home/achin/devel/rust/src/test/run-make/c-dynamic-dylib'
gcc -Wall -Werror -g -fPIC -m64 -L /storage/home/achin/devel/rust/x86_64-unknown-linux-gnu/test/run-make/c-dynamic-dylib -c -o /storage/home/achin/devel/rust/x86_64-unknown-linux-gnu/test/run-make/c-dynamic-dylib/libcfoo.o cfoo.c
gcc -Wall -Werror -g -fPIC -m64 -L /storage/home/achin/devel/rust/x86_64-unknown-linux-gnu/test/run-make/c-dynamic-dylib -o /storage/home/achin/devel/rust/x86_64-unknown-linux-gnu/test/run-make/c-dynamic-dylib/libcfoo.so /storage/home/achin/devel/rust/x86_64-unknown-linux-gnu/test/run-make/c-dynamic-dylib/libcfoo.o -shared
/storage/home/achin/devel/rust/x86_64-unknown-linux-gnu/stage2/bin/rustc --out-dir /storage/home/achin/devel/rust/x86_64-unknown-linux-gnu/test/run-make/c-dynamic-dylib -L /storage/home/achin/devel/rust/x86_64-unknown-linux-gnu/test/run-make/c-dynamic-dylib foo.rs
/storage/home/achin/devel/rust/x86_64-unknown-linux-gnu/stage2/bin/rustc --out-dir /storage/home/achin/devel/rust/x86_64-unknown-linux-gnu/test/run-make/c-dynamic-dylib -L /storage/home/achin/devel/rust/x86_64-unknown-linux-gnu/test/run-make/c-dynamic-dylib bar.rs
/storage/home/achin/devel/rust/x86_64-unknown-linux-gnu/test/run-make/c-dynamic-dylib/bar
rm /storage/home/achin/devel/rust/x86_64-unknown-linux-gnu/test/run-make/c-dynamic-dylib/libcfoo.o
make[1]: Leaving directory `/storage/home/achin/devel/rust/src/test/run-make/c-dynamic-dylib'
------ stderr ---------------------------------------------
/storage/home/achin/devel/rust/x86_64-unknown-linux-gnu/test/run-make/c-dynamic-dylib/bar: error while loading shared libraries: libcfoo.so: cannot open shared object file: No such file or directory
make[1]: *** [all] Error 127
------ ---------------------------------------------
```
The old method of serializing the AST gives totally bogus spans if the
expansion of an imported macro causes compilation errors. The best
solution seems to be to serialize the actual textual macro definition
and load it the same way the std-macros are. I'm not totally confident
that getting the source from the CodeMap will always do the right thing,
but it seems to work in simple cases.
