On Tue, 12 Mar 2024 03:28:24 GMT, Shaojin Wen wrote:
>> The current BigDecimal(String) constructor calls String#toCharArray, which
>> has a memory allocation.
>>
>>
>> public BigDecimal(String val) {
>> this(val.toCharArray(), 0, val.length()); // allocate char[]
>> }
>>
>>
>> When the
> The current BigDecimal(String) constructor calls String#toCharArray, which
> has a memory allocation.
>
>
> public BigDecimal(String val) {
> this(val.toCharArray(), 0, val.length()); // allocate char[]
> }
>
>
> When the length is greater than 18, create a char[]
>
>
> boolean
On Mon, 11 Mar 2024 20:41:25 GMT, Shaojin Wen wrote:
>> The current BigDecimal(String) constructor calls String#toCharArray, which
>> has a memory allocation.
>>
>>
>> public BigDecimal(String val) {
>> this(val.toCharArray(), 0, val.length()); // allocate char[]
>> }
>>
>>
>> When the
On Tue, 12 Mar 2024 00:16:52 GMT, Mandy Chung wrote:
> I agree with the evaluation of
> [JDK-8327786](https://bugs.openjdk.org/browse/JDK-8327786) that
> `setAccessible(true)` isn't for most developers and this proposal is not
> worth doing.
I concur.
-
PR Comment:
On Mon, 11 Mar 2024 20:41:25 GMT, Shaojin Wen wrote:
>> The current BigDecimal(String) constructor calls String#toCharArray, which
>> has a memory allocation.
>>
>>
>> public BigDecimal(String val) {
>> this(val.toCharArray(), 0, val.length()); // allocate char[]
>> }
>>
>>
>> When the
On Thu, 7 Mar 2024 16:47:01 GMT, SendaoYan wrote:
> Date.toString() uses Locale.US explicitly for printing the time zone, so
> replace Locale.ROOT to Locale.US in this testcase for fix the test failure.
>
> This testcase fixed has been verified.
>
> Only change the testcase, risk is low.
On Thu, 25 Jan 2024 21:35:45 GMT, Sergey wrote:
> The feature allows to extract a private field value in a single expression,
> like so:
>
> object.getClass().getDeclaredField().setAccessible().get(object)
I agree with the evaluation of
On Wed, 20 Sep 2023 04:52:31 GMT, Chen Liang wrote:
> Please review this patch that:
> 1. Implemented `forEach` to optimize for 1 or 2 element collections.
> 2. Implemented `spliterator` to optimize for a single element.
>
> The default implementations for multiple-element immutable collections
Please review this patch that:
1. Implemented `forEach` to optimize for 1 or 2 element collections.
2. Implemented `spliterator` to optimize for a single element.
The default implementations for multiple-element immutable collections are fine
as-is, specializing implementation doesn't provide
On Thu, 25 Jan 2024 21:35:45 GMT, Sergey wrote:
> The feature allows to extract a private field value in a single expression,
> like so:
>
> object.getClass().getDeclaredField().setAccessible().get(object)
For your information, [the proposal has been
On Sat, 9 Mar 2024 03:29:26 GMT, Guoxiong Li wrote:
>> Alex Menkov has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> typo
>
> test/jdk/java/lang/instrument/RetransformRecordAnnotation.java line 27:
>
>> 25: * @test
>> 26: * @bug
On Mon, 11 Mar 2024 23:22:44 GMT, Brian Burkhalter wrote:
> > What is the "standard protocol" to find a reviewer?
>
> Reviewers will generally chime in of their own accord depending on their
> expertise, interest, availability, the perceived importance of the issue, and
> so on.
What can I
On Mon, 11 Mar 2024 23:06:53 GMT, Sergey wrote:
> What is the "standard protocol" to find a reviewer?
Reviewers will generally chime in of their own accord depending on their
expertise, interest, availability, the perceived importance of the issue, and
so on.
-
PR Comment:
On Thu, 25 Jan 2024 21:35:45 GMT, Sergey wrote:
> The feature allows to extract a private field value in a single expression,
> like so:
>
> object.getClass().getDeclaredField().setAccessible().get(object)
So the only thing left seems to be finding a reviewer. What is the "standard
protocol"
On Tue, 27 Feb 2024 06:09:03 GMT, Chen Liang wrote:
> First, usually to propose a patch to core libraries, we usually submit an
> issue or suggest an enhancement to https://bugs.java.com, or ask at
> `core-libs-dev@openjdk.org`.
>
> A field that has been "set accessible" is supposed to be
On Thu, 25 Jan 2024 21:35:45 GMT, Sergey wrote:
> The feature allows to extract a private field value in a single expression,
> like so:
>
> object.getClass().getDeclaredField().setAccessible().get(object)
https://openjdk.org/contribute/
u may firstly have a look at this.
-
PR
On Thu, 25 Jan 2024 21:35:45 GMT, Sergey wrote:
> The feature allows to extract a private field value in a single expression,
> like so:
>
> object.getClass().getDeclaredField().setAccessible().get(object)
First, usually to propose a patch to core libraries, we usually submit an issue
or
On Thu, 25 Jan 2024 21:35:45 GMT, Sergey wrote:
> The feature allows to extract a private field value in a single expression,
> like so:
>
> object.getClass().getDeclaredField().setAccessible().get(object)
How do I find an eligible reviewer and create an issue to link this PR to?
Are there
The feature allows to extract a private field value in a single expression,
like so:
object.getClass().getDeclaredField().setAccessible().get(object)
-
Commit messages:
- Add functional-style setAccessible()
Changes: https://git.openjdk.org/jdk/pull/17578/files
Webrev:
On Fri, 8 Mar 2024 19:54:31 GMT, Naoto Sato wrote:
> Removing left over "applet" mention in the package-info doc.
This pull request has now been integrated.
Changeset: 586396cb
Author:Naoto Sato
URL:
https://git.openjdk.org/jdk/commit/586396cbb55a318fd6a2b4f1d8738258c6f8deff
Stats:
On Mon, 11 Mar 2024 20:41:25 GMT, Shaojin Wen wrote:
>> The current BigDecimal(String) constructor calls String#toCharArray, which
>> has a memory allocation.
>>
>>
>> public BigDecimal(String val) {
>> this(val.toCharArray(), 0, val.length()); // allocate char[]
>> }
>>
>>
>> When the
On Wed, 21 Feb 2024 19:10:16 GMT, Calvin Cheung wrote:
> While generating holder classes (in `generateHolderClasses()`), don't add the
> `MethodType` to the `invokerTypes` if will fail the check in the `build()`
> method which would result in a `RuntimeException`.
>
> Also updated the
On Fri, 8 Mar 2024 15:58:27 GMT, Ioi Lam wrote:
>> Calvin Cheung has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> @iklam comments and copyright update
>
> Looks good. Just a small nit.
Thanks @iklam, @matias9927 for the reviews.
> The current BigDecimal(String) constructor calls String#toCharArray, which
> has a memory allocation.
>
>
> public BigDecimal(String val) {
> this(val.toCharArray(), 0, val.length()); // allocate char[]
> }
>
>
> When the length is greater than 18, create a char[]
>
>
> boolean
On Mon, 11 Mar 2024 16:32:31 GMT, Naoto Sato wrote:
>> Removing left over "applet" mention in the package-info doc.
>
> Naoto Sato has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Addressing review comments
Marked as reviewed by alanb
On Mon, 11 Mar 2024 19:12:33 GMT, Chad Rakoczy wrote:
>> Fix for [8325621](https://bugs.openjdk.org/browse/JDK-8325621)
>>
>> Updates jspawnhelper to check that JDK version and jspawnhelper version are
>> the same. Updates test to include check for version. Also tested manually by
>>
On Mon, 11 Mar 2024 18:36:57 GMT, Aleksey Shipilev wrote:
> > If you really want to require an exact match for jspawnhelper, then these 4
> > numbers aren't necessarily enough, but a rather arbitrarily chosen
> > approximation.
>
> I think for our purposes, a version number quadruplet is
On Sun, 10 Mar 2024 13:47:06 GMT, Eirik Bjørsnøs wrote:
>> Please review this PR which removes the 19 deprecated `xxObject*` alias
>> methods from `jdk.internal.misc.Unsafe`.
>>
>> These methods were added in JDK-8213043 (JDK 12), presumably to allow
>> `jsr166.jar` to be used across JDK
On Mon, 11 Mar 2024 19:29:59 GMT, Srinivas Vamsi Parasa
wrote:
>> Hello Vamsi (@vamsi-parasa),
>>
>> Could you please run benchmarking of 4 cases with **updated** test class
>> **ArraysSortNew2**?
>> https://github.com/iaroslavski/sorting/blob/master/radixsort/ArraysSortNew2.java
>>
>> Put
On Tue, 27 Feb 2024 20:54:03 GMT, Vladimir Yaroslavskiy
wrote:
>> Hello Vladimir (@iaroslavski),
>>
>> Please see the data below. Each DPQS class was copied to java.util and the
>> JDK was recompiled.
>>
>> Thanks,
>> Vamsi
>>
>> > xmlns:o="urn:schemas-microsoft-com:office:office"
>>
On Mon, 11 Mar 2024 19:12:33 GMT, Chad Rakoczy wrote:
>> Fix for [8325621](https://bugs.openjdk.org/browse/JDK-8325621)
>>
>> Updates jspawnhelper to check that JDK version and jspawnhelper version are
>> the same. Updates test to include check for version. Also tested manually by
>>
On Mon, 11 Mar 2024 18:56:21 GMT, Bernd wrote:
> with a protocol version you don’t have to care about micro versions and also
> it is more tolerant about the usual cpu updates which do not introduce
> incompatibilities most of the time.
I think we can only reasonably guarantee that
> Fix for [8325621](https://bugs.openjdk.org/browse/JDK-8325621)
>
> Updates jspawnhelper to check that JDK version and jspawnhelper version are
> the same. Updates test to include check for version. Also tested manually by
> replacing jspawnhelper with incorrect version to confirm that check
On Mon, 11 Mar 2024 17:46:14 GMT, Chad Rakoczy wrote:
> Fix for [8325621](https://bugs.openjdk.org/browse/JDK-8325621)
>
> Updates jspawnhelper to check that JDK version and jspawnhelper version are
> the same. Updates test to include check for version. Also tested manually by
> replacing
On Mon, 11 Mar 2024 17:46:14 GMT, Chad Rakoczy wrote:
> Fix for [8325621](https://bugs.openjdk.org/browse/JDK-8325621)
>
> Updates jspawnhelper to check that JDK version and jspawnhelper version are
> the same. Updates test to include check for version. Also tested manually by
> replacing
On Mon, 11 Mar 2024 18:16:53 GMT, Erik Joelsson wrote:
> If you really want to require an exact match for jspawnhelper, then these 4
> numbers aren't necessarily enough, but a rather arbitrarily chosen
> approximation.
I think for our purposes, a version number quadruplet is enough to provide
On Mon, 11 Mar 2024 16:32:31 GMT, Naoto Sato wrote:
>> Removing left over "applet" mention in the package-info doc.
>
> Naoto Sato has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Addressing review comments
Marked as reviewed by rriggs
> The atan2 and hypot cases added would fail for a particular test library that
> has errors in the millions of ulps for those inputs, rather than the small
> number of ulps specified for the error.
Joe Darcy has updated the pull request incrementally with one additional commit
since the last
> RecordComponent class has _attributes_count field.
> The only user of the field is JvmtiClassFileReconstituter. Incorrect value of
> the field causes producing incorrect data for Record attribute.
> Parsing Record attribute ClassFileParser skips unknown attributes and may
> skip
On Mon, 11 Mar 2024 18:03:06 GMT, Shaojin Wen wrote:
>> The current BigDecimal(String) constructor calls String#toCharArray, which
>> has a memory allocation.
>>
>>
>> public BigDecimal(String val) {
>> this(val.toCharArray(), 0, val.length()); // allocate char[]
>> }
>>
>>
>> When the
> To avoid the CDS dump error message, a fix is during dumping a classlist,
> check if an invoker can be archived.
> If not, don't write the invoker info into the classlist, i.e. don't call
> `logLambdaFormInvoker()`. While generating holder classes (in
> `generateHolderClasses()`), don't add
On Fri, 8 Mar 2024 15:58:16 GMT, Ioi Lam wrote:
>> Calvin Cheung has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> @iklam comments and copyright update
>
> src/java.base/share/classes/java/lang/invoke/GenerateJLIClassesHelper.java
> line
On Mon, 11 Mar 2024 16:32:31 GMT, Naoto Sato wrote:
>> Removing left over "applet" mention in the package-info doc.
>
> Naoto Sato has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Addressing review comments
Marked as reviewed by iris
> The current BigDecimal(String) constructor calls String#toCharArray, which
> has a memory allocation.
>
>
> public BigDecimal(String val) {
> this(val.toCharArray(), 0, val.length()); // allocate char[]
> }
>
>
> When the length is greater than 18, create a char[]
>
>
> boolean
Please review this enhancement to the container detection code which allows it
to figure out whether the JVM is actually running inside a container (`podman`,
`docker`, `crio`), or with some other means that enforces memory/cpu limits by
means of the cgroup filesystem. If neither of those
Fix for [8325621](https://bugs.openjdk.org/browse/JDK-8325621)
Updates jspawnhelper to check that JDK version and jspawnhelper version are the
same. Updates test to include check for version. Also tested manually by
replacing jspawnhelper with incorrect version to confirm that check works.
On Mon, 11 Mar 2024 16:32:31 GMT, Naoto Sato wrote:
>> Removing left over "applet" mention in the package-info doc.
>
> Naoto Sato has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Addressing review comments
Marked as reviewed by bpb
On Mon, 11 Mar 2024 13:54:06 GMT, Shaojin Wen wrote:
>> The current BigDecimal(String) constructor calls String#toCharArray, which
>> has a memory allocation.
>>
>>
>> public BigDecimal(String val) {
>> this(val.toCharArray(), 0, val.length()); // allocate char[]
>> }
>>
>>
>> When the
On Tue, 27 Feb 2024 15:10:37 GMT, Nizar Benalla wrote:
> # Issue
> - [JDK-8326836](https://bugs.openjdk.org/browse/JDK-8326836): changes were
> made to the method signatures but this modification isn't reflected in the @
> since tags. The @ since tags need to be updated.
>
> I changed the
# Issue
- [JDK-8326836](https://bugs.openjdk.org/browse/JDK-8326836): changes were made
to the method signatures but this modification isn't reflected in the @ since
tags. The @ since tags need to be updated.
I changed the @\since tags to better accurately show when the methods were
On Tue, 27 Feb 2024 15:10:37 GMT, Nizar Benalla wrote:
> # Issue
> - [JDK-8326836](https://bugs.openjdk.org/browse/JDK-8326836): changes were
> made to the method signatures but this modification isn't reflected in the @
> since tags. The @ since tags need to be updated.
>
> I changed the
On Tue, 27 Feb 2024 15:10:37 GMT, Nizar Benalla wrote:
> # Issue
> - [JDK-8326836](https://bugs.openjdk.org/browse/JDK-8326836): changes were
> made to the method signatures but this modification isn't reflected in the @
> since tags. The @ since tags need to be updated.
>
> I changed the
# Issue
- JDK-8326853 Incorrect @\since Tags for Charset Related Methods Added in JDK 10
I changed the @\since tags to better accurately show when the methods and
constructors were introduced.
-
Commit messages:
- fixed @ since tag for Formatter.java class Constructors
- fixed @
On Wed, 6 Mar 2024 20:49:55 GMT, Joe Darcy wrote:
>> The atan2 and hypot cases added would fail for a particular test library
>> that has errors in the millions of ulps for those inputs, rather than the
>> small number of ulps specified for the error.
>
> Joe Darcy has updated the pull request
On Sat, 9 Mar 2024 11:12:35 GMT, Alan Bateman wrote:
>> Naoto Sato has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Addressing review comments
>
> src/java.base/share/classes/java/text/package-info.java line 29:
>
>> 27: * Provides
> Removing left over "applet" mention in the package-info doc.
Naoto Sato has updated the pull request incrementally with one additional
commit since the last revision:
Addressing review comments
-
Changes:
- all: https://git.openjdk.org/jdk/pull/18173/files
- new:
On Sun, 10 Mar 2024 13:47:43 GMT, Eirik Bjørsnøs wrote:
> Yes, you'll need to run all tests to make sure that there aren't any others,
> e.g. test/hotspot/jtreg/compiler/stable/TestUnstableStable.java.
Alan,
With @jaikiran running Oracle CI tier1, tier2, tier3 and observing only the
On Sat, 9 Mar 2024 13:18:14 GMT, SendaoYan wrote:
>> Date.toString() uses Locale.US explicitly for printing the time zone, so
>> replace Locale.ROOT to Locale.US in this testcase for fix the test failure.
>>
>> This testcase fixed has been verified.
>>
>> Only change the testcase, risk is
On Mon, 11 Mar 2024 14:42:03 GMT, Claes Redestad wrote:
>> Looks great to me. Sorry for the pings, but we may need @rgiulietti to
>> verify the math correctness and @cl4es to comment on whether having these 2
>> separate code paths or trying to extract a common part is the better
>> approach.
On Mon, 11 Mar 2024 14:15:38 GMT, Chen Liang wrote:
> Looks great to me. Sorry for the pings, but we may need @rgiulietti to verify
> the math correctness and @cl4es to comment on whether having these 2 separate
> code paths or trying to extract a common part is the better approach.
I'd love
On Mon, 11 Mar 2024 13:54:06 GMT, Shaojin Wen wrote:
>> The current BigDecimal(String) constructor calls String#toCharArray, which
>> has a memory allocation.
>>
>>
>> public BigDecimal(String val) {
>> this(val.toCharArray(), 0, val.length()); // allocate char[]
>> }
>>
>>
>> When the
On Mon, 11 Mar 2024 13:24:54 GMT, Erik Joelsson wrote:
> Based on that I agree with the choice of using a configure argument.
Thanks. The intention is that without the extra configure argument you'd get
`jdk-image` as is today. Not modified. *With* `--enable-runtime-link-image` the
result of
> The current BigDecimal(String) constructor calls String#toCharArray, which
> has a memory allocation.
>
>
> public BigDecimal(String val) {
> this(val.toCharArray(), 0, val.length()); // allocate char[]
> }
>
>
> When the length is greater than 18, create a char[]
>
>
> boolean
On Fri, 8 Mar 2024 15:48:08 GMT, Magnus Ihse Bursie wrote:
>> As of [JDK-8325880](https://bugs.openjdk.org/browse/JDK-8325880), building
>> the JDK requires version 17 of IBM Open XL C/C++ (xlc). This is in effect
>> clang by another name, and it uses the clang toolchain in the JDK build.
>>
On Mon, 11 Mar 2024 08:59:03 GMT, Joachim Kern wrote:
>> make/autoconf/flags-cflags.m4 line 687:
>>
>>> 685: PICFLAG="-fPIC"
>>> 686: PIEFLAG="-fPIE"
>>> 687: elif test "x$TOOLCHAIN_TYPE" = xclang && test "x$OPENJDK_TARGET_OS"
>>> = xaix; then
>>
>> Just a remark: This code has
On Wed, 6 Mar 2024 20:49:55 GMT, Joe Darcy wrote:
>> The atan2 and hypot cases added would fail for a particular test library
>> that has errors in the millions of ulps for those inputs, rather than the
>> small number of ulps specified for the error.
>
> Joe Darcy has updated the pull request
On Tue, 27 Feb 2024 15:23:09 GMT, Severin Gehwolf wrote:
>> Please review this patch which adds a jlink mode to the JDK which doesn't
>> need the packaged modules being present. A.k.a run-time image based jlink.
>> Fundamentally this patch adds an option to use `jlink` even though your JDK
>>
On Sun, 10 Mar 2024 16:11:12 GMT, Shaojin Wen wrote:
> The current BigDecimal(String) constructor calls String#toCharArray, which
> has a memory allocation.
>
>
> public BigDecimal(String val) {
> this(val.toCharArray(), 0, val.length()); // allocate char[]
> }
>
>
> When the length is
On Fri, 8 Mar 2024 17:36:33 GMT, Severin Gehwolf wrote:
>> That was modelled similar to `jdk_jlink` target. It also does the removal.
>> When building with `--enable-runtime-link-image`, the flow is:
>>
>>
>> 1. Link the initial jdk image (current `images/jdk`). Output is
>>
On Fri, 8 Mar 2024 15:48:08 GMT, Magnus Ihse Bursie wrote:
>> As of [JDK-8325880](https://bugs.openjdk.org/browse/JDK-8325880), building
>> the JDK requires version 17 of IBM Open XL C/C++ (xlc). This is in effect
>> clang by another name, and it uses the clang toolchain in the JDK build.
>>
On Fri, 8 Mar 2024 15:48:08 GMT, Magnus Ihse Bursie wrote:
>> As of [JDK-8325880](https://bugs.openjdk.org/browse/JDK-8325880), building
>> the JDK requires version 17 of IBM Open XL C/C++ (xlc). This is in effect
>> clang by another name, and it uses the clang toolchain in the JDK build.
>>
On Tue, 27 Feb 2024 10:30:44 GMT, Viktor Klang wrote:
> As an intermediate fix to the test, switching to explicit usage of an
> ExecutorService seems to do the trick to make this test reliably pass.
>
> With that said, this test (CHM::ToArray.java) seems to trigger an issue in
> ForkJoinPool,
On Sun, 10 Mar 2024 20:27:56 GMT, Chen Liang wrote:
> Good idea! Since we are now maintaining two code paths, when we update one,
> we might forget about the other; is it possible to create another interal
> constructor that takes a `CharSequence`, so we can pass the string in
> directly, and
The current BigDecimal(String) constructor calls String#toCharArray, which has
a memory allocation.
public BigDecimal(String val) {
this(val.toCharArray(), 0, val.length()); // allocate char[]
}
When the length is greater than 18, create a char[]
boolean isCompact = (len <=
On Sun, 10 Mar 2024 16:11:12 GMT, Shaojin Wen wrote:
> The current BigDecimal(String) constructor calls String#toCharArray, which
> has a memory allocation.
>
>
> public BigDecimal(String val) {
> this(val.toCharArray(), 0, val.length()); // allocate char[]
> }
>
>
> When the length is
On Sun, 10 Mar 2024 16:11:12 GMT, Shaojin Wen wrote:
> The current BigDecimal(String) constructor calls String#toCharArray, which
> has a memory allocation.
>
>
> public BigDecimal(String val) {
> this(val.toCharArray(), 0, val.length()); // allocate char[]
> }
>
>
> When the length is
On Mon, 11 Mar 2024 08:38:53 GMT, Joachim Kern wrote:
>> Magnus Ihse Bursie has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Revert SEARCH_PATH changes
>
> doc/building.html line 679:
>
>> 677: IBM Open XL C/C++
>> 678: The minimum
On Fri, 8 Mar 2024 15:31:18 GMT, Magnus Ihse Bursie wrote:
>> Magnus Ihse Bursie has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Revert SEARCH_PATH changes
>
> make/autoconf/flags-cflags.m4 line 687:
>
>> 685: PICFLAG="-fPIC"
>>
On Fri, 8 Mar 2024 15:48:08 GMT, Magnus Ihse Bursie wrote:
>> As of [JDK-8325880](https://bugs.openjdk.org/browse/JDK-8325880), building
>> the JDK requires version 17 of IBM Open XL C/C++ (xlc). This is in effect
>> clang by another name, and it uses the clang toolchain in the JDK build.
>>
On Fri, 8 Mar 2024 15:48:08 GMT, Magnus Ihse Bursie wrote:
>> As of [JDK-8325880](https://bugs.openjdk.org/browse/JDK-8325880), building
>> the JDK requires version 17 of IBM Open XL C/C++ (xlc). This is in effect
>> clang by another name, and it uses the clang toolchain in the JDK build.
>>
On Wed, 6 Mar 2024 12:14:10 GMT, Magnus Ihse Bursie wrote:
> * `test/jdk/java/lang/Thread/jni/AttachCurrentThread/libImplicitAttach.c` was
> missing an export. This had not been discovered before since that file was
> not compiled on Windows.
It's a Linux/macOS specific test so it wasn't
On Wed, 6 Mar 2024 13:43:00 GMT, Magnus Ihse Bursie wrote:
>> Currently, our symbol visibility handling for tests are sloppy; we only
>> handle it properly on Windows. We need to bring it up to the same levels as
>> product code. This is a prerequisite for
>>
82 matches
Mail list logo
